--- title: "Deploy Sentry-Compatible Error Tracking | (Just Updated) GlitchTip, Source Maps Survive Redeploys" category: "Observability" url: https://railway.com/deploy/sentry-compatible-error-tracking-or-glit --- # Deploy Sentry-Compatible Error Tracking | (Just Updated) GlitchTip, Source Maps Survive Redeploys **[Deploy Sentry-Compatible Error Tracking | (Just Updated) GlitchTip, Source Maps Survive Redeploys on Railway](https://railway.com/template/sentry-compatible-error-tracking-or-glit)** - **Creator:** SuperSlowSloth - **Category:** Observability ## Template content ### redis - **Image:** redis:8.2.1 - **Start command:** `/bin/sh -c 'rm -rf /data/lost+found && chown -R redis:redis /data && exec docker-entrypoint.sh redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes --dir /data'` ### glitchtip - **Image:** ghcr.io/bon5co/glitchtip-railway:latest - **Health check:** /_health/ - **Public domain:** Yes ### postgres - **Image:** postgres:17.10-trixie ## Documentation # 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`. ## Similar templates - [Pyroscope profiling](https://railway.com/deploy/pyroscope-profiling) — Protected continuous profiling with durable Pyroscope storage. - [SigOnly](https://railway.com/deploy/sigonly) — Deploy SigNoz with a working demo app & config in one click - [Unwrapped Spotify Music Stats](https://railway.com/deploy/wide-bold) — Unwrapped Spotify Music Stats, Estatísticas de músicas disponíveis Open this page in a browser: https://railway.com/deploy/sentry-compatible-error-tracking-or-glit