self-hosted

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. That's also why at the moment I use either OpenProject (which is a bit on the slow side but has an okay feature set) or Kanboard (which is really fast, but slim on features) for my self-hosted project management stuff. Neither solution is perfect, but at least I can run them.

> 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. Where's the OpenTelemetry equivalent of launching an (opinionated) Docker Compose stack that has everything you need on the server side, running against SQLite, MariaDB, PostgreSQL, ClickHouse, ElasticSearch or another data st

Oof, sorry to hear it. File a ticket if you have specific things come up: https://github.com/getsentry/self-hosted/issues/new

1) Do you have two separate codebases for free and paid? No. Sentry has one codebase between free and paid. We have a Django monolith plus some services where all our features are implemented: https://github.com/getsentry/sentry https://github.com/getsentry/relay https://github.com/getsentry/snuba https://github.com/getsentry/vroom 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 (pr

This is something we're (Sentry) not happy about. Always hard to maintain the simplicity with growing product functionality. There's efforts underway (e.g. https://github.com/getsentry/self-hosted/issues/1763) to reduce the footprint if you only need portions of the functionality.

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 reac