Deploy and Host Sentry-Compatible Error Tracking (GlitchTip) on Railway

GlitchTip is free, open-source error tracking that speaks the Sentry SDK protocol. Every official sentry-sdk — Python, JavaScript, Go, Ruby, PHP, Java, .NET, React Native — reports to it by changing the DSN and nothing else. You get issue grouping, stack traces with source maps, release tracking, alerts to email/webhook/Slack, performance transactions and uptime monitors, without sending your production errors to a third party.

About Hosting Sentry-Compatible Error Tracking (GlitchTip)

Self-hosted Sentry is a 12-to-23 container distributed system — Kafka, ClickHouse, Snuba, Relay, Symbolicator, a task broker and a fleet of consumers — and its own documentation asks for 16 GB of RAM before it will run. GlitchTip serves the same SDKs from three services: the application, Postgres, and Valkey/Redis. Web server, task worker and scheduler share one container via GlitchTip's own all_in_one mode, so there is no second app service to pay for.

This template runs ghcr.io/bon5co/glitchtip-railway, a thin wrapper over the official upstream image pinned at 6.2.3. No forks, no patches — only the configuration a Railway deployment needs, plus three corrections that are wrong by default on this platform:

Uploaded source maps survive a redeploy — and that matters more than it sounds. GlitchTip stores uploads in a Django FileField, and MEDIA_ROOT defaults to an empty string, which resolves to the working directory /code — the ephemeral container filesystem. On Railway a redeploy replaces the container, so every source map you uploaded is gone. The trap is what happens next: FileBlob deduplicates on a sha1 checksum kept in Postgres, which survives. Re-uploading the identical file finds the surviving row, applies no defaults, and writes nothing — measured as blobs before/after re-upload = 1/1, returning the same id with the file still missing. So sentry-cli reports a successful upload, the UI keeps listing the artifact, and your stack traces stay minified until somebody deletes the row by hand. This template puts MEDIA_ROOT on the volume, and repairs the volume's root ownership before the app's privilege drop so it can actually write there.

Your instance stays yours. Upstream defaults ENABLE_USER_REGISTRATION to True, so a public GlitchTip URL accepts signups from anyone who finds it. This template turns it off, which does not lock you out: GlitchTip already special-cases the empty instance, so the first account — yours — is still allowed, and everyone after it is refused. Verified on a live deployment: first signup 200, second signup 403.

Login works over HTTPS. Railway terminates TLS at the edge and GlitchTip exposes no SECURE_PROXY_SSL_HEADER setting, so Django can compare a browser's https origin against an http view of its own host and reject the POST. The entrypoint derives CSRF_TRUSTED_ORIGINS from the Railway public domain.

The image is pinned rather than tracking :latest, because GlitchTip applies Django migrations on boot that are not designed to roll back. Memory sizing is deliberately left alone — GlitchTip 6 already reads the cgroup for both its malloc arenas and its worker RSS ceiling, so there is nothing to override.

Data lives on three volumes: the Postgres data directory, Valkey's append-only file, and /data on the application for uploaded artifacts.

Why Deploy Sentry-Compatible Error Tracking (GlitchTip)?

Because the alternative to self-hosting is either paying per event to a SaaS vendor or shipping your users' stack traces — which routinely contain request bodies, headers and tokens — to someone else's infrastructure. GlitchTip keeps the data in your own project, on your own database, under your own retention setting (90 days by default, configurable), and costs the same whether you send a thousand events or a million.

It is also the realistic way to run Sentry-compatible error tracking on a platform billed by usage. A 12-service Sentry stack is expensive to keep running and slow to boot; this one starts in well under a minute and idles at a fraction of the footprint, while accepting the exact same DSN from the exact same SDK you already have installed.

Common Use Cases

Drop-in replacement for a paid Sentry plan — change the DSN in your existing sentry-sdk setup, keep every integration, stop paying per event.
Error tracking for client work you cannot send off-site — health, finance, internal tools, or anything under a data-residency clause.
A team error tracker for side projects and small teams — organizations, projects, teams and alert rules, with signup closed so it stays your instance.
Uptime monitoring and release health alongside errors — GlitchTip ships uptime checks and release tracking in the same install, run by the embedded scheduler.

Dependencies for Sentry-Compatible Error Tracking (GlitchTip)

PostgreSQL — every issue, event, organization, project and file-blob checksum.
Valkey/Redis — cache and task broker for the embedded worker and scheduler.
A persistent volume on the application for uploaded source maps and event attachments.

Deployment Dependencies

GlitchTip:
Source (GitLab):
Upstream image:
Railway wrapper image and its measurements:
Sentry SDK docs (client setup is identical):

Implementation Details

The deploy form is fully pre-filled — SECRET_KEY is generated per deploy, the database and Valkey URLs are wired between services, and GLITCHTIP_DOMAIN follows the Railway public domain. After the first deploy, open the public URL and register; that first account is the only one the instance will accept. Create an organization and a project, copy the DSN, and point your SDK at it.

To reopen signups later, set ENABLE_USER_REGISTRATION=True on the application service. To change how long events are kept, set GLITCHTIP_RETENTION_DAYS.