Why migrate to GlitchTip now
Sentry self-hosted 26.4.x has been suffering from five simultaneous regressions documented by the community since August 2026. Issues #4301 and #4306 describe Snuba consumers that restart in an infinite loop without processing events, and a deadlock in the monitor_consumer that blocks cron recording. Issue #4321 reports a relay authentication failure on HTTP/2 connections, interrupting event ingestion. These regressions have pushed several teams to publicly document their migration to GlitchTip.
The most common objection is compatibility: you have instrumented your applications with the Sentry SDK (sentry-python, @sentry/node, sentry-rails…) and you do not want to rewrite that instrumentation. GlitchTip implements the Sentry API and accepts events sent by these same SDKs. The swap comes down to replacing the value of your SENTRY_DSN environment variable with the DSN GlitchTip provides when you create a project. Zero changes to application code.
What you get with a self-hosted GlitchTip v6
- Minimal footprint — four containers only (Django, Celery, PostgreSQL, Redis), versus the twenty-odd services of Sentry self-hosted.
- Sentry SDK compatibility — all official Sentry SDKs work without modification; only the DSN changes.
- Data sovereignty — error traces and user data stay on your infrastructure, under your retention policy.
- GPL-3.0 licence — the code is auditable, with no proprietary component or feature gated behind a paid plan.
- Uptime monitoring — GlitchTip includes HTTP ping-based uptime monitors with no external dependency.
- Performance management interface — transaction tracking, N+1 traces and slow query monitoring via the compatible Sentry API.
- Low RAM consumption — 2 GB of RAM is enough for solo use or a small team, with no configuration tuning required.
Prerequisites before you start
GlitchTip v6 relies on four containers: Django (the web server and interface), Celery (the asynchronous event-processing workers), PostgreSQL (the primary database) and Redis (the task queue). You need:
- A Linux VPS with at least 2 GB of RAM (4 GB is comfortable for a team of ten developers with a few hundred errors per day).
- Docker and Docker Compose installed — available on all recent distributions.
- A domain name or subdomain pointed at your VPS IP address, to enable HTTPS via Let's Encrypt.
- Ports 80 and 443 open in your firewall.
On a ServOrbit VPS, Docker comes pre-installed. Plans starting at 2 vCPU and 2 GB RAM cover this workload exactly.
Deploy GlitchTip with Docker Compose
Create the working directory
Connect to your VPS via SSH, then create a dedicated directory:
mkdir -p /opt/glitchtip && cd /opt/glitchtip
Create the environment variable file
Create a .env file with the configuration values:
SECRET_KEY=<long-random-string> — generate it with openssl rand -hex 32.DATABASE_URL=postgresql://glitchtip:password@db:5432/glitchtipREDIS_URL=redis://redis:6379/0GLITCHTIP_DOMAIN=https://glitchtip.your-domain.com[email protected]EMAIL_URL=smtp://user:[email protected]:587
Replace values with your own credentials. GLITCHTIP_DOMAIN must match the domain you will secure with HTTPS exactly — it is baked into the DSNs that GlitchTip generates.
Create the docker-compose.yml file
Create a docker-compose.yml file with the following content (adapted from the official GlitchTip documentation):
version: "3.8"
x-environment: &default-environment
env_file: .env
services:
db:
image: postgres:16
environment:
POSTGRES_DB: glitchtip
POSTGRES_USER: glitchtip
POSTGRES_PASSWORD: password
volumes:
- pg_data:/var/lib/postgresql/data
redis:
image: redis:7
volumes:
- redis_data:/data
web:
image: glitchtip/glitchtip:latest
depends_on: [db, redis]
ports:
- "127.0.0.1:8000:8080"
<<: *default-environment
worker:
image: glitchtip/glitchtip:latest
command: ./bin/run-celery-with-beat.sh
depends_on: [db, redis]
<<: *default-environment
volumes:
pg_data:
redis_data:Note that port 8000 is bound to 127.0.0.1 only: the service is never exposed directly, but through a reverse proxy.
Initialise the database
Run the Django migrations to create the schema:
docker compose run --rm web ./manage.py migrate
Run this command once at installation, then again each time you update to a new version of GlitchTip.
Create the first superuser
Create your admin account:
docker compose run --rm web ./manage.py createsuperuser
Enter the email address and password when the prompt asks for them.
Start the stack
Start all containers in the background:
docker compose up -d
Verify that all four containers are running with docker compose ps. The web service responds at http://127.0.0.1:8000.
Configure the nginx reverse proxy with HTTPS
Install nginx and Certbot if not already present:
apt install -y nginx certbot python3-certbot-nginx
Create a vhost in /etc/nginx/sites-available/glitchtip with a server block listening on port 80, setting server_name glitchtip.your-domain.com and proxying traffic to http://127.0.0.1:8000 via proxy_pass. Enable the configuration, then obtain the certificate:
certbot --nginx -d glitchtip.your-domain.com
Certbot automatically updates the vhost to redirect HTTP to HTTPS and adds the SSL block.
Connect the Sentry SDK from your applications
In the GlitchTip interface, create an organisation, then a project. GlitchTip generates a DSN in the format https://<key>@glitchtip.your-domain.com/<project-id>.
In each of your applications, replace the value of SENTRY_DSN (or the dsn parameter passed to Sentry.init()) with this new DSN. Restart your processes. Events appear in GlitchTip with no other modification.
Post-installation configuration
After the first start, adjust these settings in the admin interface:
Additional environment variables. Enable email alert sending by setting EMAIL_URL in your .env. Add GLITCHTIP_MAX_EVENT_LIFE_DAYS=90 to cap event retention and keep the database size under control.
Multi-team access. GlitchTip manages organisations and members with different permission levels. Create your teams from Settings → Members and invite your developers by email.
Uptime monitors. In the Monitors section of your project, create a ping monitor for each of your exposed services: GlitchTip sends an HTTP request at a regular interval and creates an issue if the service does not respond within the configured timeout.
Hardening the stack
Restrict access to port 8000 with ufw: ufw allow 80/tcp && ufw allow 443/tcp && ufw deny 8000/tcp. Add SECURE_SSL_REDIRECT=True and SESSION_COOKIE_SECURE=True in your .env to enforce HTTPS at the Django level. Schedule a daily pg_dump to a remote location — the pg_data volume contains all your error data and configuration. Finally, consult the initial Linux server hardening guide before exposing the instance to production traffic.
Common errors and how to fix them
Error: relation "glitchtip_*" does not exist — The migration has not been run. Execute docker compose run --rm web ./manage.py migrate and check that the db container is healthy with docker compose ps.
CSRF verification failed. Request aborted. — The GLITCHTIP_DOMAIN variable does not match the domain from which you are accessing the interface. Check that it is set without a trailing slash and restart the containers with docker compose restart.
Connection refused on the DSN from your application — Port 8000 is not accessible from outside (this is intentional). Check that nginx is correctly forwarding HTTPS traffic to 127.0.0.1:8000: curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8000/api/0/ should return 200.
Events appear in Celery logs but not in the interface — The Celery worker started before migrations finished. Restart it with docker compose restart worker.
No such file or directory: '/etc/nginx/sites-enabled/glitchtip' — You forgot to create the symbolic link. Run ln -s /etc/nginx/sites-available/glitchtip /etc/nginx/sites-enabled/ then nginx -t && systemctl reload nginx.
GlitchTip in production on a VPS
GlitchTip v6, released in February 2026 under the GPL-3.0 licence, relies on four containers. Its compatibility with the Sentry SDK makes it a clean exit from Sentry self-hosted when the latter accumulates hard-to-workaround regressions.
To go further, see our Docker Compose production checklist to further secure your deployment, and our guide on the self-hosted app patch routine to keep GlitchTip updated without service interruption.
A GlitchTip instance fits in 2 GB of RAM: a VPS with 2 vCPU and 2 GB RAM covers this profile exactly, with root access and your choice of OS.
