I gave up on self-hosted Sentry

Summary

Why I gave up on self-hosted Sentry Klaas van Schelven; September 6, 2024 - 6 min read In the early 2010s, I was a big fan of Sentry. It was a great tool for tracking errors in web applications. At the time, I was making software for law firms, so sending error reports to a third-party service was out of the question, I needed to host it myself. So I did. After leaving the law firm world, I worked as a contractor for a few years. So when I overheard one of my colleagues asking whether it would be possible to host Sentry on-premise, I figured I could help. I had already done it, after all. Big mistake. Scare-mongering The first thing I noticed was that the Sentry documentation was full of warnings about how self-hosting was a bad idea. Here’s the kind of quote that you couldn’t make up if you were their direct competitor: we don’t necessarily recommend self-hosting to everyone. In addition to existing hidden costs, as Sentry evolves, our self-hosted version will become more complex, demanding additional types of infrastructure. Our internal system that powers our newest features will also advance and require more containers, including one for a new database. And they even have pretty pictures and a whole pdf to go with it: Credit: sentry.io Hardware requirements Despite the warnings, I hadn’t given up yet. I had already done it once, after all. So I opened the documentation and started reading. More warnings, in this case about the lack of support for the self-hosted version. Given that they have to make money too, I could understand those (more than the scary pictures). But then come the hardware requirements: they recommend at least 16GB of RAM and 4 cores. Coming from the time when I ran Sentry on a 512MB VPS, this was a bit of a shock. So is that a real problem, or should I just get with the times, and accept that 16GB is the new normal? I’d argue that it is a problem, for a few reasons. First, there’s a signal being given about the complexity and fragility of th...