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. VPS Solo (2 vCPU, 4 GB RAM), our smallest plan, covers this workload with room to spare.
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/glitchtipCreate the environment variable file
Create a
.envfile with the configuration values:SECRET_KEY=<long-random-string>— generate it withopenssl 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]:587Replace values with your own credentials.
GLITCHTIP_DOMAINmust 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.ymlfile with the following content (adapted from the official GlitchTip documentation):Define services
db(postgres:16),redis(redis:7),webandworker(imageglitchtip/glitchtip:latest), binding the web port to127.0.0.1:8000:8080only. The port is bound to127.0.0.1only: 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 migrateRun 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 createsuperuserEnter the email address and password when the prompt asks for them.
Start the stack
Start all containers in the background:
docker compose up -dVerify that all four containers are running with
docker compose ps. The web service responds athttp://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-nginxCreate a vhost in
/etc/nginx/sites-available/glitchtipwith aserverblock listening on port 80, settingserver_name glitchtip.your-domain.comand proxying traffic tohttp://127.0.0.1:8000viaproxy_pass. Enable the configuration, then obtain the certificate:certbot --nginx -d glitchtip.your-domain.comCertbot 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 thedsnparameter passed toSentry.init()) with this new DSN. Restart your processes. Events appear in GlitchTip without any other change.
GlitchTip v6 vs alternatives — what really matters
Scroll the table
| Criterion | GlitchTip v6 | Sentry self-hosted 26.4.x | Rollbar (SaaS) | Bugsnag (SaaS) |
|---|---|---|---|---|
| Memory footprint (prod) | ~500 MB active (4 containers) | ~6-8 GB (20+ services) | None (SaaS) | None (SaaS) |
| Licence | GPL-3.0 — 100% auditable code | BSL 1.1 — commercial restrictions | Proprietary | Proprietary |
| Built-in uptime monitoring | Yes — HTTP ping, alerts included | Not native (Crons extension only) | No | No |
| Sentry SDK compatibility | Full — drop-in DSN | Native | Proprietary SDK | Proprietary SDK |
Post-installation configuration
After the first start, adjust these points in the administration interface:
Additional environment variables. Enable email alerts by setting EMAIL_URL in your .env. Add GLITCHTIP_MAX_EVENT_LIFE_DAYS=90 to limit event retention and control database growth.
Multi-team access. GlitchTip manages organisations and members with different permission levels. Create your teams from Settings → Members and invite developers by email.
Uptime monitors. In the Monitors section of your project, create a ping monitor for each exposed service: GlitchTip sends an HTTP request at regular intervals and creates an issue if the service does not respond within the configured timeout.
Webhook alerts to Slack or ntfy. From Settings → Alerts, add a destination of type "Webhook". For Slack, paste your Incoming Webhook URL (https://hooks.slack.com/services/…); for ntfy, use https://ntfy.sh/<your-topic> with the POST method. GlitchTip sends structured JSON on each new issue or threshold breach.
SDK integration — Python. Replace only the DSN value; the rest of the code stays identical:
import sentry_sdk then sentry_sdk.init(dsn="https://<key>@glitchtip.your-domain.com/<id>", traces_sample_rate=1.0)
SDK integration — React. Same logic on the front end:
import * as Sentry from "@sentry/react" then Sentry.init({ dsn: "https://<key>@glitchtip.your-domain.com/<id>", tracesSampleRate: 1.0 })
GlitchTip receives both Python/Node exceptions and JavaScript errors captured in the browser, all grouped in the same interface.
Data retention. The GLITCHTIP_MAX_EVENT_LIFE_DAYS variable (uncapped by default) controls the maximum age of retained events. On a 60 GB SSD VPS, 90-day retention for a few hundred errors per day rarely exceeds 5 GB — monitor with docker system df.
Stack hardening
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 holds all your error data and configuration. Finally, consult the initial Linux server hardening guide before exposing the instance to production.
Troubleshooting common errors
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 defined 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 the outside (by design). Check that nginx is correctly proxying 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 symlink. Run ln -s /etc/nginx/sites-available/glitchtip /etc/nginx/sites-enabled/ then nginx -t && systemctl reload nginx.
celery.exceptions.WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL) — The worker container was killed by the kernel OOM killer. Your VPS is running out of RAM: lower CELERY_WORKER_CONCURRENCY to 2 in your .env, or upgrade to 4 GB RAM. Confirm with docker compose logs worker --tail 50 and dmesg | grep -i oom.
django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections — PostgreSQL has hit its max_connections limit (default: 100). Add CONN_MAX_AGE=60 in your .env to enable Django-side connection pooling, or set up PgBouncer as an intermediary. This error typically occurs when multiple Celery workers run concurrently without connection pooling.
GlitchTip in production on a VPS
GlitchTip v6, released in February 2026 under GPL-3.0, 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-work-around regressions.
For further reading, see our guide on the Docker Compose production checklist to further secure your deployment, and our article on the self-hosted apps patching routine to keep GlitchTip up to date without service interruption.
A GlitchTip instance fits in 2 GB of RAM: the VPS Solo (2 vCPU, 4 GB RAM) covers this profile with room to spare, with root access and OS choice.
