
Should I self-host Sentry?
GlitchTip speaks the Sentry SDK protocol and fits on a normal VPS. Sentry's own self-host wants 16GB and a small ops team — the honest self-host answer is the compatible lightweight, and it breaks even in about two months.
The math (nothing hidden, including your time)
| Sentry (Team) | $26.00/mo |
| VPS share + storage | −$2.50/mo |
| Your maintenance: 30 min/mo at $20/h | −$10.00/mo |
| Net saving | $13.50/mo |
| Setup: 90 min measured (one-time) | $30.00 |
| Break-even | 2.2 months |
| Markup Index (price ÷ real self-host cost) | 2.1× |
Price: source, checked 2026-08-06. Inputs are stored in git; every number above is derived, never hand-written.
What you lose
- Sentry's deep tracing/profiling/replay product — GlitchTip is errors done well, not the whole observability suite
- SaaS-side data retention muscle
What you're paying Sentry for
- error tracking (Sentry SDKs)
- issue grouping & alerts
- performance traces (basic)
- uptime checks

Ranked alternatives
Error tracking that speaks the Sentry SDK protocol, so your code keeps its instrumentation and changes one DSN.
Hardware
Runs comfortably on a real VPS (2 GB+).
The tested compose file (our evidence, CI-booted)
# GlitchTip — Sentry-compatible error tracking that fits on a normal VPS (replaces Sentry's
# Team plan; Sentry's own self-host wants ~16GB and a dozen containers — GlitchTip is the
# sane answer)
services:
glitchtip-web:
image: glitchtip/glitchtip:latest
container_name: glitchtip-web
restart: unless-stopped
depends_on:
glitchtip-db:
condition: service_healthy
glitchtip-redis:
condition: service_healthy
environment: >-env
DATABASE_URL: postgres://glitchtip:glitchtip@glitchtip-db:5432/glitchtip
REDIS_URL: redis://glitchtip-redis:6379
SECRET_KEY: 2b1e6f9c8d7a5b4c3e2f1a0d9c8b7a6f5e4d3c2b1a0f9e8d # throwaway test value
GLITCHTIP_DOMAIN: http://localhost:8088
EMAIL_URL: consolemail://
ENABLE_USER_REGISTRATION: "true"
ports:
- "8088:8000" # glitchtip serves on 8000
healthcheck:
# python-slim image: no curl/wget, but python is right there
test: ["CMD-SHELL", "python3 -c \"import urllib.request;urllib.request.urlopen('http://localhost:8000/_health/')\""]
interval: 5s
timeout: 5s
retries: 36
start_period: 30s
glitchtip-worker:
image: glitchtip/glitchtip:latest
container_name: glitchtip-worker
restart: unless-stopped
command: ./bin/run-celery-with-beat.sh
depends_on:
glitchtip-db:
condition: service_healthy
glitchtip-redis:
condition: service_healthy
environment: *gt-env
# No worker healthcheck: celery's inspect ping is unreliable as a container probe
# (broker registration races it forever). The web container's /_health/ gate plus
# restart: unless-stopped is the honest signal here.
glitchtip-db:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_USER: glitchtip
POSTGRES_PASSWORD: glitchtip
POSTGRES_DB: glitchtip
volumes:
- glitchtip-pg:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U glitchtip"]
interval: 5s
timeout: 5s
retries: 12
glitchtip-redis:
image: redis:7-alpine
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
interval: 5s
timeout: 5s
retries: 12
volumes:
glitchtip-pg:
Want a guided install instead? caniselfhostit.com/sentry has AI-agent prompts that assume a bare machine — that's their half of the stool, and it's good.
Verification
Protocol v1 · verified by zernonia on 2026-08-10 · setup measured at 90 min · AI assistant: claude-code (allowed & stated)
What broke
- The container serves on 8000, not the 8080 several guides claim — map and probe accordingly
- python-slim image has no curl/wget; the healthcheck probes /_health/ with python urllib
- Celery worker needs its own container with the same env — errors ingest but nothing processes without it; don't healthcheck it with celery inspect ping, which races broker registration forever
Full timed log
# Timed setup log: Sentry → glitchtip **Protocol:** v1 · **Verified by:** zernonia · **Date:** 2026-08-10 **Assistant:** claude-code · **Environment:** containerized runner, 2 vCPU class, Docker 29.3 / Compose v5.1 ## Timeline | Step | Time | |---|---| | Read upstream docs, draft compose with healthcheck | ~30 min | | **Boot: all services healthy in 13 s (measured, `compose up --wait`)** | — | | Endpoint-level workflow check (login/health/API serve) + re-run from clean volumes | ~30 min | | **Total: ~90 min** | | Boot and endpoint checks are machine-verified; `setup_min` is the wall-clock total for this session including authoring, diagnosis and re-runs. Endpoint-level ≠ full human UI workflow — dispute anything that doesn't reproduce (CONTRIBUTING.md). ## What broke - The container serves on 8000, not the 8080 several guides claim — map and probe accordingly - python-slim image has no curl/wget; the healthcheck probes /_health/ with python urllib - Celery worker needs its own container with the same env — errors ingest but nothing processes without it; don't healthcheck it with celery inspect ping, which races broker registration forever ## Verdict-relevant notes - SDK setup is unchanged from Sentry: swap the DSN.
Verdict history
- 2026-08-10: unscored → YES — Initial verdict: GlitchTip speaks the Sentry SDK protocol and fits on a normal VPS. Sentry's own self-host wants 16GB and a small ops team.