Deploy and Host GlitchTip (hardened) on Railway

GlitchTip is open-source error tracking that speaks the Sentry protocol. Any Sentry SDK points at it by changing a single environment variable, so adopting it — or leaving it — costs one line of configuration. This build runs GlitchTip as one service with its background worker embedded, backed by PostgreSQL and Redis on Railway's private network.

About Hosting GlitchTip (hardened)

GlitchTip is a Django application with two hard dependencies: PostgreSQL for storage and Redis as a task broker. Events arrive over HTTP and are queued; a background worker groups them into issues, applies retention, and sends alert mail. Without a worker running somewhere, events arrive and are silently never processed.

This template embeds that worker in the web process. One service to operate instead of two, and no SECRET_KEY to keep synchronised between them. Migrations run automatically on first boot. Both datastores carry persistent volumes and are reached over private networking, so a redeploy keeps your event history and internal traffic costs no egress.

SECRET_KEY and both datastore passwords are generated fresh on every deploy, and the Postgres superuser is given a random name rather than postgres. User registration is enabled so you can create the first account, and should be closed immediately afterwards.

Common Use Cases

Self-hosted error tracking for teams that cannot send stack traces, request payloads or user identifiers to a third-party service
A drop-in Sentry replacement — identical SDKs, identical DSN format, one variable to switch, and one variable to switch back
A single instance collecting errors from several services or environments, separated by tag rather than by deployment

Dependencies for GlitchTip (hardened) Hosting

PostgreSQL 14 or newer — included in this template, with a persistent volume
Redis, or a Valkey-compatible equivalent — included, acting as the task broker
An SMTP server — not included, and required for alert mail and account confirmation

Implementation Details

Two variables must be supplied at deploy time:

EMAIL_URL=smtp+tls://user:password@smtp.example.com:587 DEFAULT_FROM_EMAIL=errors@example.com

Without them the instance runs normally but never sends mail, which means no alerts and no way to confirm the account you just registered.

Once the first account exists, close signup and redeploy:

ENABLE_USER_REGISTRATION=false

Leaving it open lets anyone who finds the URL create an account on a system holding your stack traces.

Point an application at the instance with its project DSN:

SENTRY_DSN=https://@/

Several services can share one DSN. Tag events by service in your SDK's init() and filter on that tag in the Issues view, rather than running a project per service.

Other variables worth knowing:

GLITCHTIP_EVENT_RETENTION_DAYS — defaults to 90. Lower it to slow database growth.
GLITCHTIP_EMBED_WORKER — keep true. Set it to false only if you add a dedicated worker service, which must then share the same SECRET_KEY and Redis.
ALLOWED_HOSTS — the hostnames Django will serve. Defaults to any host if unset.

Why Deploy GlitchTip (hardened) on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying GlitchTip (hardened) on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

One catch: ALLOWED_HOSTS is named there but isn't in your variable list yet. Add it before publishing:

ALLOWED_HOSTS = ${{RAILWAY_PUBLIC_DOMAIN}} Description: Hostnames Django will serve. Defaults to any host if unset.