How to Deploy GlitchTip on a VPS

copysudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw --force enable
sudo ufw status verbose

#Download and edit the compose file

GlitchTip publishes a sample compose file. Its install docs say to save it as compose.yml and edit the environment section:

copymkdir -p ~/glitchtip && cd ~/glitchtip
[ -f compose.yml ] || curl -fsSL -o compose.yml https://glitchtip.com/assets/compose.sample.yml
grep -n 'image:\|SECRET_KEY\|GLITCHTIP_DOMAIN\|"8000:8000"' compose.yml

The file defines three services. postgres runs Postgres 18, valkey runs Valkey 9, and web runs glitchtip/glitchtip:6 with SERVER_ROLE: all_in_one, so one container serves both the web app and the background worker. The shared settings sit in an x-environment block at the top.

Now make the edits, each one idempotent so you can re-run the block:

copycd ~/glitchtip
# 1. A real secret key — the sample ships a placeholder
sed -i "s|SECRET_KEY: change_me_to_something_random|SECRET_KEY: $(openssl rand -hex 32)|" compose.yml
# 2. Your public URL — DSNs and email links are built from it
sed -i 's|GLITCHTIP_DOMAIN: https://glitchtip.example.com|GLITCHTIP_DOMAIN: https://errors.example.com|' compose.yml
# 3. Loopback-only port — Caddy is the public entry point
sed -i 's|- "8000:8000"|- "127.0.0.1:8000:8000"|' compose.yml
# 4. No public self-signup, and only the hostnames you serve
grep -q ENABLE_USER_REGISTRATION compose.yml || \
  sed -i '/ENABLE_ADMIN:/i\  ENABLE_USER_REGISTRATION: "False"\n  ALLOWED_HOSTS: errors.example.com,127.0.0.1,localhost' compose.yml
grep -n 'SECRET_KEY\|GLITCHTIP_DOMAIN\|127.0.0.1:8000\|ENABLE_USER_REGISTRATION\|ALLOWED_HOSTS' compose.yml | sed 's/SECRET_KEY: .*/SECRET_KEY: (set)/'

Replace errors.example.com with your real domain in both places. Here is what each edit does:

• SECRET_KEY signs sessions and tokens. The sample value is public, so never run with it.
• GLITCHTIP_DOMAIN must include the scheme. The DSN each project shows is built from it, so a wrong value hands your SDKs a wrong ingest URL.
• ENABLE_USER_REGISTRATION: "False" follows the docs' definition: self- signup is disabled after the first user is registered. Anyone else must be created by a superuser, and organisation invitations can only go to existing users. Leave it at the default True and anyone who finds the URL can make an account.
• ALLOWED_HOSTS. Without it, GlitchTip logs a warning at startup that ALLOWED_HOSTS is the wildcard default and should be restricted in production.

EMAIL_URL stays consolemail://, which prints emails to the container log. Before inviting teammates or relying on alert emails, set it to your SMTP server in the form smtp://user:password@host:port, and set DEFAULT_FROM_EMAIL to match. The sample's Postgres uses trust authentication on the internal Compose network. It isn't published to the host, but the sample's own comment suggests setting a password for anything long-lived.

#Start GlitchTip

copycd ~/glitchtip
docker compose up -d
for i in $(seq 1 60); do
  [ "$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8000/_health/)" = 200 ] && break
  sleep 3
done
curl -s http://127.0.0.1:8000/_health/; echo
docker compose ps

Database migrations run automatically on start. _health/ answering ok means the web process is up and serving.

#Create the admin account

With self-signup closed, create the first account yourself. Django's createsuperuser command runs non-interactively when the password comes from the environment. This generates one and saves it to ~/glitchtip/admin-password:

copycd ~/glitchtip
[ -f admin-password ] || openssl rand -base64 18 > admin-password
chmod 600 admin-password
docker compose exec -T -e DJANGO_SUPERUSER_PASSWORD="$(cat admin-password)" web \
  ./manage.py createsuperuser --noinput --email admin@example.com 2>&1 | tail -1
curl -s http://127.0.0.1:8000/api/settings/ | grep -o '"enableUserRegistration": [a-z]*'

"enableUserRegistration": false confirms public signup is off. Use your own email. It is the login. Once you're signed in, create an organisation and then a project for each application. Each project shows its DSN.

#HTTPS + domain

Point an A record for errors.example.com at the server and put Caddy in front of the loopback port:

errors.example.com {
    reverse_proxy 127.0.0.1:8000
}

GlitchTip's docs recommend a proxy that buffers requests and handles chunked transfer encoding, and their nginx example raises the body limit to 40 MB so large event payloads and source-map uploads aren't rejected. Caddy sets no request-body limit by default, so this works as is.

#Point an application at it

In each app, keep the Sentry SDK and swap the DSN for the one from the GlitchTip project page. It looks like https://<key>@errors.example.com/<project-id>. For example, in Python:

copyimport sentry_sdk
sentry_sdk.init(dsn="https://<key>@errors.example.com/1")

Trigger a test exception from the app, and it appears in the project's issue list, grouped with any repeats.

#Retention

GlitchTip cleans up old data automatically. GLITCHTIP_RETENTION_DAYS (default 90) is the master setting. Per-type overrides exist for events, transactions, logs, uptime checks and files, plus GLITCHTIP_RELEASE_RETENTION_DAYS (default 365). Recent events stay in Postgres for GLITCHTIP_EVENT_HOT_DAYS (default 30). Older ones can move to an optional cold-storage archive, enabled with GLITCHTIP_ENABLE_DUCKDB. On a small disk, lower the master value in the x-environment block and recreate the containers.

#Backups

Postgres holds everything: users, organisations, projects and events. Dump it with the stack running:

copycd ~/glitchtip
docker compose exec -T postgres pg_dump -U postgres postgres | gzip > glitchtip-$(date +%F).sql.gz
ls -lh glitchtip-*.sql.gz

Also keep compose.yml, which holds your SECRET_KEY, and the uploads volume if you upload source maps or debug files. Copy all of it off the box. To restore, bring up an empty stack with the same compose.yml and pipe the dump into psql in the postgres container before starting web.

#Upgrades

The docs' procedure is pull, stop, start. Migrations run automatically:

copycd ~/glitchtip
docker compose pull
docker compose stop
docker compose up -d

The glitchtip/glitchtip:6 tag follows the 6.x line. A new major version means editing the tag, and the sample's comment points to the GlitchTip blog for those announcements. The Postgres tag is a separate decision. A major Postgres upgrade needs a dump and restore, not just a new image. Take a dump before either.

#Troubleshooting

The UI loads but SDK events never arrive. Check GLITCHTIP_DOMAIN. The DSN is built from it, so if it still says glitchtip.example.com, every SDK sends to the wrong host. Fix it, recreate the containers, and copy the DSN again.

"Bad Request (400)" through the domain. The hostname isn't in ALLOWED_HOSTS. Add it (comma-separated) and recreate web.

No alert or invite emails. EMAIL_URL is still consolemail://, so the emails went to docker compose logs web. Configure SMTP.

Memory is tight on a 512 MB box. Use the sample file's own low-RAM options: set VALKEY_URL: "" to use Postgres for the queue and cache, remove the valkey service, and turn off GLITCHTIP_ENABLE_LOGS and GLITCHTIP_ENABLE_UPTIME if you don't use them.

#Verification + next steps

You're done when https://errors.example.com loads over a valid certificate, you can sign in as the admin while the signup page is refused to everyone else, a test exception from a real app shows up as an issue, and a Postgres dump sits off the box.

Next: configure SMTP so alerts reach people, create one project per service, and add GlitchTip's uptime monitors for your public endpoints. For dedicated uptime monitoring and status pages, see Uptime Kuma.