1. Pilae
2. Apps
3. GlitchTip

Running GlitchTip in production: what it takes

1. Agree retention, then deploy

   A version we have run, on PostgreSQL with Valkey beside it and a bucket in the same region, with retention agreed before the first event rather than discovered when the disk fills.

2. Close sign-up, put it behind your IdP

   Self-registration off and organisation creation reserved for administrators. People sign in through Keycloak or your own IdP, such as Microsoft Entra ID, over OpenID Connect.

3. Publish only the ingest path

   Server-side services report over the private network. Where browsers or mobile apps report too, the gate on port 443 publishes the ingest endpoints and nothing else. The interface stays private.

4. Back up hot and cold events together

   PostgreSQL and the bucket go offsite daily, encrypted, together, because with cold storage on, events older than thirty days live only in the bucket. Once a month we restore both into a scratch environment and open a recent issue there.

5. Upgrade after reading the changelog

   Migrations run on start and some drop what the previous release needs, so the rollback we keep ready is the snapshot taken just before. The Pilae Agent tries each release on a copy and applies it in your window after you approve it.

What GlitchTip is, and who runs it

GlitchTip system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory

2 vCPU · 4 GBFor the machine, with PostgreSQL and Valkey on it. Upstream recommends 512 MB for GlitchTip itself, but its worker holds queued events in memory while it drains a backlog, and cold storage runs DuckDB in the same process. The headroom is for the burst a bad deploy sends.

Database

PostgreSQL 14+Holds issues, events, users and uptime checks, partitioned by date. Upstream supports 14 but already tests from 15, ahead of a framework upgrade that drops 14, so we deploy on a current major.

Queue and cache

Valkey 7+Optional. Without it, PostgreSQL carries the task queue, cache and sessions, more slowly, so we add it past a small team. Redis 7+ also works, though upstream tests it less. Upstream says its data must be available but is not necessarily worth backing up, so we leave it out of the backup.

Object storage

S3-compatible bucketFor source maps, debug files and, with cold storage on, events archived as Parquet. A local volume works on one machine; we use a bucket in the same region, so files and archives outlive the machine and are backed up with the database.

Disk

~30 GB per 1M events/monthUpstream's rough guide. Breadcrumbs and payload size move it, and the retention period decides the rest, which is why retention is agreed before the first event arrives.

Migrating from Sentry to GlitchTip

The SDKs stay. GlitchTip accepts events from the Sentry SDKs, so each application keeps its code and changes the DSN it reports to. Its import command reads Sentry's API and copies the organisation, members, teams and projects with their client keys. Upstream has tested it against an older self-hosted Sentry, not sentry.io, so we check what it created before any DSN moves. Issue history does not come across: old issues stay readable in Sentry for as long as you keep it. Session Replay, profiling, release health and Crons check-ins are ignored at ingest, and heartbeat monitors take the place of cron checks. The real work is in alert rules, which are rebuilt by hand, and in the source map uploads in every CI pipeline.

1. Import the organisation

   The import runs first into a scratch instance, with a Sentry auth token, and we compare each project's client keys with Sentry before running it for real. It brings no events and no alert rules.

2. Move the DSNs, one service at a time

   Each application changes the DSN it reports to, staging first. Sample rates are set in the SDK before production traffic arrives, not after the first bad deploy.

3. Switch source map uploads in CI

   Release and source map steps move to glitchtip-cli, the MIT-licensed replacement for sentry-cli, or keep sentry-cli pointed at the new host. A deliberate error in staging proves the stack trace resolves.

4. Rebuild alerts, then close Sentry

   Alert rules and webhook recipients are recreated per project and checked against a real error. Sentry stays readable for lookups until its last useful issue has aged out.

The environment file behind a GlitchTip deployment

# /srv/glitchtip/glitchtip.env  (acme, zur1)
# SECRET_KEY, DATABASE_URL and the bucket keys are in glitchtip.secrets.env.
# DSNs name this host. Only the ingest paths are published through the gate.
GLITCHTIP_DOMAIN=https://errors.acme.ch
ALLOWED_HOSTS=errors.acme.ch
VALKEY_URL=redis://valkey.acme.internal:6379/0
EMAIL_URL=smtp://relay.acme.internal:25
DEFAULT_FROM_EMAIL=alerts@acme.ch

# Accounts arrive through the identity provider only.
ENABLE_USER_REGISTRATION=False
ENABLE_SOCIAL_APPS_USER_REGISTRATION=True
ENABLE_ORGANIZATION_CREATION=False

# 30 days in PostgreSQL, then Parquet in the bucket until day 90.
GLITCHTIP_RETENTION_DAYS=90
GLITCHTIP_EVENT_HOT_DAYS=30
GLITCHTIP_ENABLE_DUCKDB=True
GLITCHTIP_COLD_STORAGE_BUCKET=acme-glitchtip-cold

# Source maps and debug files, in the same region.
DEFAULT_FILE_STORAGE=storages.backends.s3boto3.S3Boto3Storage
AWS_STORAGE_BUCKET_NAME=acme-glitchtip-files
AWS_S3_ENDPOINT_URL=https://s3.zur1.acme.internal

# Redact secrets, card numbers, private keys and emails before storage.
GLITCHTIP_PII_SCRUB_DEFAULT={"enabled": true, "scrub_emails": true}

# Monitors and alert webhooks may reach internal services.
GLITCHTIP_UPTIME_ALLOW_PRIVATE_IPS=True
GLITCHTIP_ALLOW_PRIVATE_IPS=True
GLITCHTIP_ENABLE_MCP=False

What Pilae is responsible for

Where it runs

zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware

Who holds the credentials

You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.

If you leave

The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running GlitchTip

Pricing is on request: a fixed price for onboarding, then a monthly price for GlitchTip, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size

The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.

High availability

One machine with tested restores, or a replicated setup that keeps serving when a node fails.

Storage and backups

How much data it holds, how long backups are kept, and point-in-time recovery for its database.

Plan and support

Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.

Region

Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.

Sign-on and integrations

Single sign-on, directory sync, mail relays and the other systems the app has to reach.

GlitchTip: common questions

Also in engineering and security