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.
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:
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 the software. A 16GB RAM requirement just screams “this is a big, complex piece of software that will break in mysterious ways”. Not very scientific, I know, but based on experience.
Second, there’s the simple matter of cost. The cheapest VM at the super-cheap hosting company Hetzner costs €3.29 per month, but if you need 16GB, you’ll pay 15.90 per month – almost a factor 5 more. And that’s assuming you can run things at el-cheapo hosting. If you pay-per-compute, or if you work at some big corp, the cost of machines may be much higher.
Also relevant in corporate environments: there may very well be some threshold where it is easy to spin up “small” machines (for some value of small), but above which you’ll need to beg for permission with a bean counter, sysadmin or manager.
Finally, as Linus Torvalds said
if you can do something really fast, really well, people start using it differently.
The same applies for “if it’s small”. One such different use-case is to just run it locally, as an aid in local development. If you need 16GB of RAM to run Sentry, you’ll run the risk of slowing down your laptop to a crawl, or at least having to think about it. If it’s in the 100MB range, you can just run it and forget about it.
Oh and if you were thinking of running it on a Raspberry Pi, forget about it, but not (just) because of the RAM. The Pi has an ARM processor, and Sentry only supports amd64.
The next chapter in the documentation is about the actual installation.
The first thing you’ll notice is that the installation is done with a shell script. That is not a problem in itself, but I’m also not the type of person who would just run a shell script from the internet without reading it first, so I did.
The actual script is some 30 lines, but each of those is an include of another script. Counting those, you get:
me@mymachine~/../self-hosted/install$ wc -l *.sh
[...]
837 total
That’s not a time-investment I’m willing to make. Especially since this is, as per the documentation, only a first step towards a reliable installation:
packaged up for low-volume deployments and proofs-of-concept
And remember that the whole reason for setting up Sentry was to help a colleague. I’m not going to leave them with a proof-of-concept, and I also don’t want to become the guy who maintains the Sentry installation. And I’m not going to tell them to read 837 lines of shell script either.
Finally, I did some random internet searching, to see what the actual experience was of people who had self-hosted Sentry. Here are some quotes:
It’s a ton of docker containers. Things will fail randomly or maybe with a lot of traffic, don’t remember well. Hard to upgrade or it would upgrade automatically and break?.
if you can dedicate like 1/4 to 1/2 an engineer on it then i think its worth it. keeping in mind that it is an absolutely bear with an ungodly amount of stateful dependencies nowadays.
I can’t say it’s been pleasant, probably my least favorite service to do maintenance on or interact with
Now let’s just assume these aren’t astro-turfed by Sentry’s own marketing department, i.e that these are real. None of this looks very promising. And since I don’t have a 1/4 to 1/2 an engineer to dedicate to this, I would be looking at a significant share of my own time.
I gave up on self-hosted Sentry before even getting started.
I’m not going to run a piece of software that requires 16GB of RAM, has a complex installation script, and is known to be a pain to maintain. I’m not going to recommend it to anyone else either.
So did some good come out of this? I’d like to think so… this small journey got me mad enough to just write a drop-in replacement for Sentry that can run on any cheap hardware you can find. I hope that it is a useful alternative for people with the same taste in software as me.