Should I self-host Sentry?

# 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: &gt-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.

# 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.