Sentry is good software, and its pricing is built around event volume, which means the bill grows exactly when your app is having the worst week — a bug that throws on every request generates the most events right when you can least afford a surprise invoice. Self-hosting an error tracker sidesteps that, and keeps stack traces (which often contain more of your internals than you’d like a third party to have) on your own box.

GlitchTip: the practical self-hosted option

GlitchTip is a lighter reimplementation of Sentry’s server, and — this is the part that makes it a real option instead of a toy — it’s API-compatible with the Sentry SDKs. You don’t switch client libraries. You point the existing Sentry SDK at your own server.

# docker-compose.yml (abbreviated)
services:
  postgres:
    image: postgres:16
  redis:
    image: redis:7
  web:
    image: glitchtip/glitchtip
    depends_on: [postgres, redis]
    environment:
      DATABASE_URL: postgres://glitchtip:glitchtip@postgres/glitchtip
      SECRET_KEY: <generate one>
      PORT: 8000
    ports:
      - "8000:8000"
  worker:
    image: glitchtip/glitchtip
    command: ./bin/run-celery-with-beat.sh
    depends_on: [postgres, redis]

Run docker compose up -d, create an org and project through the web UI, and you get a DSN just like Sentry’s.

Wiring up the SDK (no code changes if you’re already using Sentry)

import * as Sentry from '@sentry/node'

Sentry.init({
  dsn: 'https://your-key@errors.yourapp.com/1',
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
})

If you’re migrating off hosted Sentry, this is the only line that changes — the dsn now points at your GlitchTip instance’s URL instead of sentry.io. Everything else — Sentry.captureException, the automatic unhandled-exception hooks, source map upload for readable stack traces — works the same because GlitchTip speaks the same protocol.

Source maps, so stack traces are readable

Minified production JS gives you useless stack traces without source maps uploaded:

npx @sentry/cli releases files $VERSION upload-sourcemaps ./dist \
  --url-prefix '~/static/js' \
  --url ${GLITCHTIP_URL}

Point --url at your self-hosted instance instead of Sentry’s API — the CLI tool itself is unchanged, it’s Sentry’s own tool, and GlitchTip accepts the same upload protocol.

What you’re giving up

GlitchTip covers error tracking and basic performance tracing well. It doesn’t have Sentry’s full session replay, and its performance monitoring is less deep than Sentry’s paid tiers. If you specifically need session replay (watching a recorded browser session tied to an error), that’s a real gap — evaluate whether you actually use that feature before assuming the self-hosted swap is a clean win.

Resource footprint

This is Postgres + Redis + a Django app + a Celery worker — four containers, not one binary. On a small VPS (2 vCPU, 4GB RAM) it runs comfortably for a single small-to-medium app’s error volume. If you’re processing a high volume of events (a very chatty app, or many services reporting in), give Postgres and the worker more headroom — error spikes during incidents are bursty, and that’s exactly when you need the tracker to keep up, not fall behind and drop events.

Takeaway

If you’re already using the Sentry SDK, self-hosting your error tracker with GlitchTip is close to a config change, not a migration — same client code, same DSN-based setup, different server. The tradeoff is running four more containers yourself in exchange for predictable cost and your stack traces staying on infrastructure you control.