zammad-docker-compose VS self-hosted

The word "can" is doing a lot of work in your comment, based on the now horrific number of moving parts[1] and I think David has even said the self-hosting story isn't a priority for them. Also, don't overlook the license, if your shop is sensitive to non-FOSS licensing terms

1: https://github.com/getsentry/self-hosted/blob/25.5.1/docker-...

I didn't downvote you but as one metric their docker-compose is 500 lines long https://github.com/getsentry/self-hosted/blob/25.4.0/docker-... as compared to back in the good-old days when it was basically python, redis, and postgres https://github.com/getsentry/self-hosted/blob/9.1.2/docker-c...

The most complex system that I've seen that you could self host is the Sentry APM solution, have a look at how many services there are: https://github.com/getsentry/self-hosted/blob/master/docker-...

That's the main reason why I've gone why Apache Skywalking instead, even if it's a bit jank and has fewer features.

It's kind of unfortunate, either you just have an RDBMS and use it for everything (key-value/document storage, caches, queues, search etc.), or you fan out and have Valkey, RabbitMQ and so on, increasing the complexity.

> I maintain that any platform that isn’t using some sort of tracing system is practically negligent in their engineering duty.

For some, it's difficult because many of the self-hostable out there are rather complex and have high requirements, like https://github.com/getsentry/self-hosted/blob/master/docker-...

Personally I found Apache Skywalking to be something that you can setup without too many issues https://skywalking.apache.org/ but it's not exactly ideal either.

I wonder what other good options are out there, something that you can have up and running on a 5$ VPS within an hour or two, to not cause friction.

Of course, when SaaS is an option, many will just go for that.

Oof, sorry to hear it. File a ticket if you have specific things come up:

https://github.com/getsentry/self-hosted/issues/new

etc.

We have a Docker Compose wrapper in a separate repo:

https://github.com/getsentry/self-hosted

We have a private repo called getsentry/getsentry that is another Django app that imports the public one and uses Django signals (iirc) to meter usage for billing. That is what we deploy to SaaS. All product features are implemented in the public repos.

3) How about employee access?

Employee access is managed through UI, I honestly don't know whether it lives in getsentry/sentry (public) or getsentry/getsentry (private). Probably the latter?

2) How do you handle updates to your product?

Employees work in public on GitHub. We ship more or less continuously to SaaS. It's possible to deploy approximately continuously on self-hosted as well, though we also bless monthly snapshots for a more relaxed cadence. Does that answer this question?

I was responding to the One of the Sentry inconvenience is self-hosting: it relies on so many services it can be very complicated to maintain part, and also reminding readers that if they, too, hate companies that rug-pull their open source licenses, there is a band-aid for both parts

Compare https://github.com/getsentry/self-hosted/blob/9.1.2/docker-c... with https://github.com/getsentry/self-hosted/blob/24.4.2/docker-... for what life used to be like for running Sentry on-prem. It was awesome

It would take a ton of work to dig up the actual memory and CPU requirements of each one, but rest assured they're not zero, so every one of those services eats ram and requires TLC when, not if, they shit themselves. So, more parts == more headaches with all other things being equal

Then, I deeply appreciate that there are a whole spectrum of reactions to the various licensing schemes in use nowadays, and a bunch of folks don't care. I care, though, because I have gotten immense value from open source projects, and have contributed changes back to quite a few. It has been my life experience that any of those "source available" licenses usually are very hostile toward making local builds and if I can't build it to match how prod goes, then I can't test my fixes in my environment and then I can't contribute the PR with any faith

This is the point where I will point out that you can self-host Sentry free of charge :) https://develop.sentry.dev/self-hosted/

Sentry can be self hosted: https://develop.sentry.dev/self-hosted/

The people we're concerned about are not the hundreds of thousands of Sentry users, including those that self-host.

We're concerned about people who have taken the software for the purposes of competing directly against us, that hinders our ability to monetize the work. Monetizing the work helps us continue improving the software and distribute it for free use, benefitting those aforementioned real users (e.g. https://github.com/getsentry/self-hosted).