Deploy GlitchTip

Deploy and Host GlitchTip on Railway

GlitchTip is open-source error tracking and uptime monitoring that speaks the same protocol as Sentry. It collects unhandled exceptions, stack traces, log records and performance spans, groups them into issues, and alerts you when something new breaks. Because it implements the Sentry ingest API, every official Sentry SDK (Python, JavaScript, Ruby, PHP, Go, Java, .NET and the rest) works against it unchanged: swap the DSN and keep your instrumentation. Teams self-host GlitchTip to keep crash reports on infrastructure they control, to escape per-seat pricing, or to satisfy data-residency rules.

Deploy GlitchTip on Railway and this template wires up the shape upstream documents for production, not the single-container demo. A web service runs the Granian ASGI server that serves the dashboard and accepts ingest. A separate worker service runs the task queue and scheduler, so grouping events, symbolicating traces, evaluating alerts and dispatching uptime checks never compete with HTTP requests. PostgreSQL stores projects, issues and events; Redis is the Valkey-compatible broker, cache and session store; a Railway object storage bucket holds source maps, debug files and archives, which is why no service here needs a volume.

Getting Started with GlitchTip on Railway

Open the deployed URL and you land on the login screen. There are no default credentials. Click Sign Up and register the first account with your own email and password; the template ships ENABLE_USER_REGISTRATION set to true so this can happen. Once your account exists, set that variable to false, or anyone who finds your URL can register on your instance.

You are then asked to create an organization; the first one on a fresh server is always allowed. Next create a team, because a project cannot be created without one and the form quietly does nothing until a team exists. Then create a project and pick your platform. GlitchTip shows a DSN like https://@your-app.up.railway.app/1. Put that in your Sentry SDK configuration and deliberately raise an exception. Within seconds it appears under Issues with a full stack trace, tags and release, which is the real proof the deployment works. Add an uptime monitor to confirm the worker runs scheduled jobs too.

About Hosting GlitchTip

GlitchTip exists because self-hosting Sentry became heavy, a sprawl of services wanting 8 GB or more of RAM. GlitchTip re-implements the parts most teams actually use in one Django application that runs in a fraction of that. Self-host it when you would rather not send production stack traces, which routinely contain customer data, to a third party.

Key features:

• Sentry-SDK-compatible ingest, so instrumentation migrates by changing one DSN
• Issue grouping, search, assignment, resolution and regression detection
• Source map and debug-file uploads for readable JavaScript and native traces
• Uptime monitoring with GET, POST, ping, heartbeat and TCP port checks
• Structured log ingestion, including a native OTLP/HTTP endpoint at /v1/logs
• Alerts to email, Discord, Slack-compatible webhooks, Teams, ntfy and Zulip
• Per-organization SSO via OpenID Connect, plus TOTP, WebAuthn and passkey MFA

The service split matters. The web tier answers dashboard traffic and enqueues events; the worker drains that queue and runs the scheduler behind alert evaluation, retention sweeps and uptime checks. PostgreSQL is the system of record, partitioned by time and organization. Redis carries the queue, cache and sessions, which is why signing in survives a redeploy.

Why Deploy GlitchTip on Railway

Railway removes the operational work that makes self-hosted error tracking unattractive:

• Managed PostgreSQL and Redis with volumes and backups
• Object storage provisioned alongside the app, so no MinIO to babysit
• Web and worker scale independently as event volume grows
• Automatic TLS on a public domain, with private networking between services
• Migrations run automatically before every release

Common Use Cases

• Replacing a paid Sentry subscription while keeping every existing SDK integration
• Keeping crash reports and their embedded customer data on your own infrastructure
• Pairing error tracking with uptime monitoring, so a failing endpoint and the exception behind it appear in one tool

Dependencies for GlitchTip

• GlitchTip — glitchtip/glitchtip:latest, web tier serving the dashboard and ingest API
• GlitchTip Worker — same image with SERVER_ROLE=worker, running queue and scheduler
• PostgreSQL 18 — projects, issues, events, logs and uptime history
• Redis — Valkey-compatible task broker, cache and session store
• Object storage bucket — source maps, debug files, attachments and archives

The PostgreSQL service raises max_locks_per_transaction to 512. This is not optional tuning: GlitchTip range-partitions its event tables and sub-partitions them by organization, so a query it cannot narrow to one partition locks every partition and index on it. On a stock cluster one busy page load can exhaust the lock table and fail unrelated transactions, ingestion included.

Environment Variables Reference

Deployment Dependencies

• Source repository:
• Docker image:
• Documentation:
• Runtime: Python 3.14, Django, Granian

Hardware Requirements for Self-Hosting GlitchTip

Event volume, not user count, drives sizing; cold storage keeps the database smaller.

Self-Hosting GlitchTip with Docker

Outside Railway the smallest stack is PostgreSQL, Valkey and the app image:

services:
  postgres:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD: changeme
    command: postgres -c max_locks_per_transaction=512
    volumes:
      - pgdata:/var/lib/postgresql
  valkey:
    image: valkey/valkey:9
  web:
    image: glitchtip/glitchtip:latest
    ports: ["8000:8000"]
    environment: &env
      DATABASE_URL: postgres://postgres:changeme@postgres:5432/postgres
      VALKEY_URL: redis://valkey:6379
      SECRET_KEY: change_me_to_a_random_string
      GLITCHTIP_DOMAIN: https://glitchtip.example.com
  worker:
    image: glitchtip/glitchtip:latest
    environment: {<<: *env, SERVER_ROLE: worker}
volumes:
  pgdata:

Generate a signing key, then start the stack:

openssl rand -hex 32
docker compose up -d
docker compose run --rm web ./bin/run-migrate.sh

The migration step is only needed when web and worker are split; an all-in-one container migrates itself.

How Much Does GlitchTip Cost to Self-Host?

GlitchTip is free and open source under the MIT license, with no paid tier, seat limit or event cap in the self-hosted build. The project's hosted service starts free at 1,000 events per month and charges above that; self-hosting removes those limits. On Railway you pay only for the compute, database and storage consumed, so cost tracks event volume, not team size.

FAQ

What is GlitchTip?

An open-source error tracking and uptime monitoring server. It receives crash reports through the Sentry SDK protocol, groups them into issues, and notifies you when new problems appear.

What does this Railway template deploy?

A GlitchTip web service with a public URL, a GlitchTip worker, managed PostgreSQL, managed Redis, and an object storage bucket. Migrations run automatically before each release.

Why does GlitchTip need both PostgreSQL and Redis?

PostgreSQL is the system of record for projects, issues, events and uptime history. Redis carries the task queue the worker drains, the cache, and user sessions, so you stay signed in across a redeploy.

How do I stop strangers from signing up on my GlitchTip instance?

Set ENABLE_USER_REGISTRATION to false on the web service once your own account exists. Registration is then rejected at the API level, not merely hidden in the interface. Invite colleagues from organization settings.

Do I need to configure email to use self-hosted GlitchTip?

No. Without a mail transport GlitchTip skips email verification, so you can register and use the instance immediately. Set EMAIL_URL and DEFAULT_FROM_EMAIL to have alerts and invitations delivered.