Railway

Deploy GlitchTip | Open Source Sentry-Compatible Error Tracking

Sentry-compatible error tracking. No S3 to set up, private-network ingest

Deploy GlitchTip | Open Source Sentry-Compatible Error Tracking

Just deployed

Just deployed

/var/lib/postgresql

Just deployed

/code/uploads

Deploy and Host GlitchTip on Railway

GlitchTip is open-source error tracking that speaks Sentry's protocol. Every Sentry SDK — Python, JavaScript, Go, Ruby, PHP, Java, .NET — points at it by changing one DSN string, and you get the same grouped issues, stack traces, breadcrumbs, releases and alerts, on infrastructure you own.

About Hosting GlitchTip

This template runs the official glitchtip/glitchtip image on a fully pinned release, with PostgreSQL 18 for storage, Redis as the task broker, and a Railway volume for uploaded artifacts. Nothing is rebuilt or forked.

Three things here differ from the other GlitchTip deployments on Railway.

The version is pinned in full. The official template tracks the 6 tag with patch auto-updates, which means an upstream release lands on a running project on its own schedule. Here the tag is 6.2.6 and it moves when you decide it moves.

There is no object storage to configure. Source maps, avatars and event attachments go on a Railway volume instead of an S3 bucket, which removes a service and four AWS credentials from the first-run screen. Everything else about the deployment is identical.

Your apps can report over the private network. The web server binds the IPv6 wildcard rather than the IPv4-only default, so an app running in the same Railway project sends its events to glitchtip.railway.internal:8000 — no public round trip, no egress charge, no TLS handshake per event. Apps outside the project use the public domain exactly as usual.

Common Use Cases

  • Self-hosted Sentry replacement: Keep stack traces, user emails and request payloads on your own infrastructure — useful when a compliance regime has opinions about where crash data lives.
  • Error tracking for a Railway project: Point the services already running alongside it at the private hostname and get grouped issues, regressions and alerts without leaving the project.
  • Uptime monitoring: GlitchTip also polls HTTP endpoints on a schedule and raises the same alerts as an exception would, so a single deployment covers both.

Dependencies for GlitchTip Hosting

Deployment Dependencies

  • GlitchTip 6.2 — web server and background worker in one container
  • PostgreSQL 18 on a Railway volume: issues, events, users and organizations
  • Redis 8 as the Celery broker
  • A Sentry SDK in the application you want to monitor — any language, any version

Implementation Details

One container runs both roles. GLITCHTIP_EMBED_WORKER=true makes the image's start script take the all_in_one path, which runs Django migrations and Postgres partition maintenance on the way up and then serves web requests with an embedded worker. Splitting web, worker and a one-shot migration job across three services is the documented multi-node layout; at this size it is three billed services doing what one does.

GLITCHTIP_DOMAIN is built from the public domain and ends up inside every DSN you copy into an application. It has to carry the scheme, or the DSN your SDK receives is unusable and the deployment looks broken when it is not.

GRANIAN_HOST is ::. Granian defaults to 0.0.0.0, which answers the public domain but is invisible on *.railway.internal, because Railway's private network is IPv6-only. Rust leaves a wildcard socket dual-stack, so binding :: keeps the IPv4 healthcheck working while making the private hostname usable.

User registration is closed. The first person to visit the deployment registers and becomes the owner; after that the signup route is shut, so nobody who finds the URL can create an account in your error tracker. Invite the rest of your team from inside the app. Register your own account as soon as the deployment is green — until you do, that first slot is open to whoever gets there first.

Email is not configured. EMAIL_URL=consolemail:// writes what would have been sent to the deploy log, so invitations and alerts are visible but do not silently disappear into a broken SMTP setup. Point it at a real provider — smtp://user:pass@host:587 or a provider URL — to turn them on.

GLITCHTIP_MAX_EVENT_LIFE_DAYS is 90. Events are what grow the database, and this is the dial that bounds it.

Why Deploy GlitchTip 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 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.

Resources: idle, this deployment measures around 200 MB for GlitchTip, 190 MB for Postgres and under 20 MB for Redis — roughly 410 MB in total, on the order of $6 a month. What grows is Postgres, and it grows with event volume rather than with traffic to the UI; the retention setting above is the lever. Raise GRANIAN_WORKERS before anything else if the web UI feels slow under a busy ingest.


Template Content

More templates in this category

View Template
SigOnly
Deploy SigNoz with a working demo app & config in one click

zoeyjones
22
View Template
Unwrapped Spotify Music Stats
Unwrapped Spotify Music Stats, Estatísticas de músicas disponíveis

Jorge Henrique
1
View Template
OpenTelemetry Collector and Backend
OpenTelemetry Collector with Backend Stack

Melissa
113