If you've priced out self-hosting Sentry, you've probably bounced off the same wall I did: the official self-hosted stack is Kafka + ClickHouse + Snuba + Relay + a consumer fleet — something like 12 services, and the docs themselves ask for 16GB of RAM. That's a lot of infrastructure just to catch stack traces for a side project or a small team's app.
GlitchTip is the answer most people land on eventually: it speaks the same Sentry SDK protocol (drop-in, same dsn, same client libraries) but runs as three services — app, Postgres, Redis — on hardware a Sentry deploy wouldn't even boot on.
The part nobody mentions: it's easy to lose your data anyway
I maintain a Railway template for GlitchTip, and packaging it turned up three things that aren't obvious from the docs, all reproducible on the stock image:
1. Source maps disappear on redeploy, and re-uploading doesn't fix it.
MEDIA_ROOT defaults to an ephemeral path, but FileBlob dedupes uploads by checksum in a Postgres row. So after a redeploy: the file on disk is gone, but the checksum row survives. Re-upload the same file and it finds the existing row, decides there's nothing to do, and writes nothing. sentry-cli reports success both times. You find out your source maps are gone the next time a minified stack trace shows up ungrouped.
2. A mounted volume doesn't mean writable.
Railway (and most platforms) mount volumes as uid 0. GlitchTip's container runs as uid 5000. Add a volume without fixing ownership and you get PermissionError on every upload — or worse, depending on the app, a silent failure that never surfaces.
3. Signup stays open by default.
Fine for a local dev instance, less fine for a public URL. Upstream still lets the first account in even if you close registration after deploy, so you can lock it down without stranding yourself.
None of these are GlitchTip being badly built — they're the standard gap between "runs on my machine" and "runs on a platform that treats your filesystem as disposable between deploys."
What I actually did about it
Wrapper image that: fixes the volume ownership before dropping privileges, keeps MEDIA_ROOT pointed at the persistent volume so the checksum-dedup issue above never gets a chance to bite, disables signup after the first account, pins the version instead of tracking latest, and sets CSRF_TRUSTED_ORIGINS correctly for HTTPS behind Railway's proxy.
Full writeup with the reproduction commands and before/after output is in the repo if you want to see the actual failure states: https://github.com/bon5co/glitchtip-railway
If you'd rather not deal with any of this yourself, one-click deploy (disclosure: I maintain this template and get a referral kickback if you deploy through it): https://railway.com/deploy/sentry-compatible-error-tracking-or-glit?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory
And if you're not on Railway — the Dockerfile is public, so the fixes apply just as well to a plain docker run on your own box.
Using it
Once it's up, point any Sentry SDK at it like you would the real thing:
import sentry_sdk
sentry_sdk.init(dsn="https://<key>@<your-glitchtip-host>/<project-id>")
Same client libraries, same sentry-cli for source map uploads — GlitchTip's whole pitch is protocol compatibility, so nothing on the app side changes.
Tradeoffs, honestly
GlitchTip isn't Sentry — it's a lighter reimplementation. You don't get session replay, some of the fancier performance-monitoring views, or the AI-assisted triage stuff Sentry's been shipping. If your team lives inside Sentry's dashboard for reasons beyond "catch the exception," this isn't a swap you make blind. But if what you actually want is "get an alert with a stack trace when something breaks," GlitchTip does that for a fraction of the resource footprint, and self-hosting it means your error data — which often includes user info, request bodies, sometimes secrets you forgot to scrub — never leaves your own infrastructure.
Top comments (0)