GlitchTip

Last reviewed Sep 13, 2026 · 830 words

Self-hosted Sentry asks for 16 GB of RAM and a couple of dozen containers before it will start. GlitchTip accepts the same SDKs, the same DSN format and the same sentry_sdk.init() call in your code, and runs happily on a 1 GB box with 4 containers. For a homelab or a small team that wants to know when their side project throws an exception, that ratio is the entire decision. The cases where full Sentry is worth the extra 15 GB exist and I list them below, but they are narrower than most people assume.

Drop-in means changing one line

Every Sentry SDK, whether Python, JavaScript, Go, PHP, Rust, or a mobile platform, points at a DSN. GlitchTip issues DSNs of the same shape, so switching an application from Sentry's cloud to your own instance is a change to one environment variable and a redeploy. Stack traces, breadcrumbs, release tagging, user context and environment tags all arrive and are displayed. Source maps for minified JavaScript upload with the same sentry-cli tooling. This compatibility is not an approximation; the Sentry alternatives that promise it and then need a custom client are a different category of tool.

The four containers and the settings that matter

GlitchTip is a Django application and ships as one image, glitchtip/glitchtip, run in two roles: web for the API and UI, and worker for background processing. Add PostgreSQL and Redis (or Valkey, which the project now defaults to) and you have the whole stack. The reference compose file in the documentation also runs a one-shot migrate container before web starts.

The environment variables that decide whether the install works are few. DATABASE_URL for PostgreSQL, SECRET_KEY set to a long random string and never changed afterwards, GLITCHTIP_DOMAIN set to your full public URL including scheme, EMAIL_URL for outbound mail if you want alert emails and password resets, and PORT (8000 by default) if you need to change what the container listens on. Put a reverse proxy with TLS in front, set GLITCHTIP_DOMAIN to match exactly, and create the first user through the web UI; that user becomes an organisation owner. Set ENABLE_USER_REGISTRATION to false afterwards unless you want the sign-up page open.

Memory in practice: the web and worker containers idle around 300 MB combined, PostgreSQL adds a little, and the 1,024 MB in the listing is a comfortable floor for a few projects sending a few thousand events a day. It is MIT licensed, so there is no feature gate to worry about.

What you give up versus Sentry

Sentry's performance monitoring, session replay, profiling, distributed tracing views, and the issue-grouping machine learning are the reasons its self-hosted footprint is so large, and GlitchTip does not have them at that depth. It has basic transaction and performance data, and it groups errors sensibly by fingerprint, but you will not get flame graphs or watch a user's session. Alerting is simpler: email and webhook rules per project, with integrations for Slack, Discord and generic webhooks, rather than Sentry's rule builder.

For a self-hoster, none of this is usually missed. For a company with a mobile app and a customer-facing web frontend where you debug by replaying sessions, it is the reason to pay for Sentry's cloud rather than host either product.

Uptime checks are a bonus, not a monitoring stack

GlitchTip includes uptime monitoring: give it URLs, it pings them on an interval and raises an issue when they fail. It is handy because it lands in the same inbox as your errors. It is not a replacement for Uptime Kuma or Gatus, which have status pages, more check types and richer notification routing. Run GlitchTip for exceptions and a dedicated tool for availability; the homelab monitoring guide covers that side.

Bugsink is the even-smaller option

If four containers still feels like too many, Bugsink is a newer Sentry-compatible tracker that runs as a single container with SQLite. It is narrower still, error tracking only, and its community is smaller than GlitchTip's, but for one person with three projects it is the least you can run and still get stack traces in a browser. GlitchTip is the middle of the range: multi-user organisations, teams, uptime, and PostgreSQL-backed scaling to a team's worth of applications.

What I'd do

Run GlitchTip on any 1 to 2 GB box with the reference compose file, PostgreSQL on its own volume, GLITCHTIP_DOMAIN set correctly on day one, and registration closed after your team has accounts. Point every application's DSN at it, add a webhook alert into whatever notification channel you already use, and back up PostgreSQL nightly. If you are one person with tiny projects, Bugsink instead. If you find yourself wishing for session replay, that is a reason to pay Sentry, not to self-host it.