Deploy GlitchTip with the glitchtip template

Stand up GlitchTip, an open-source, Sentry-protocol-compatible error tracker, on a single Quake AI instance using the validated OpenTofu template glitchtip. You apply the template, register the first account, lock down public self-signup, create a project, point a Sentry SDK at the DSN, trigger a test error, and confirm the event arrives.

GlitchTip keeps your error telemetry on infrastructure you own. You run it yourself; this is a self-hosted tool you operate, not a managed service.

Prerequisites#

You need:

• OpenTofu 1.6.0 or later (or Terraform 1.6.0 or later) installed locally.
• Your OpenStack credentials sourced into the shell (source openrc.sh). See the OpenStack CLI guide.
• An SSH keypair that already exists in your project. Record its name for the key_name variable.
• A copy of the glitchtip template directory from the template reference page.
• An application already instrumented with a Sentry SDK, or willing to add one for the test in this walkthrough.

Step 1: Apply the template#

Copy the template's example variables file and set key_name:

cp terraform.tfvars.example terraform.tfvars

key_name = "YOUR_KEY_NAME"

Initialize, preview, and apply:

tofu init
tofu plan
tofu apply

OpenTofu provisions a private network, a router, a security group, a block volume mounted at /var/lib/docker, an instance, and a floating IP. On first boot, cloud-init installs Docker Engine, generates the secret key and database password into /opt/glitchtip/.env, runs the database migration, and starts the bundled PostgreSQL, Redis, web, and worker services.

Read the outputs and record floating_ip and app_url:

tofu output

Step 2: Register the first account and lock down self-signup#

Open app_url (for example http://YOUR_FLOATING_IP:8000; reachable from app_allowed_cidr, the private network by default). Register the first account; it becomes the instance superuser, and the registration form is open by default so you can create it.

Lock self-signup down immediately after:

ssh ubuntu@YOUR_FLOATING_IP "sudo sed -i 's/ENABLE_USER_REGISTRATION=true/ENABLE_USER_REGISTRATION=false/' /opt/glitchtip/.env && cd /opt/glitchtip && sudo docker compose up -d"

Step 3: Create a project and read the DSN#

1. Sign in and create an Organization if prompted.
2. Select Projects > Create a new project, choose the platform that matches your application (for example Node.js, Python, or a generic platform), and name it.
3. Open the project's Settings > Client Keys (DSN). Copy the DSN; it looks like http://<public_key>@YOUR_FLOATING_IP:8000/<project_id>.

Step 4: Point a Sentry SDK at the DSN#

GlitchTip speaks the Sentry event-ingestion protocol, so the official Sentry SDKs work unchanged. In a Node.js application:

npm install @sentry/node

import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "http://YOUR_PUBLIC_KEY@YOUR_FLOATING_IP:8000/YOUR_PROJECT_ID",
});

// Trigger a test error
Sentry.captureException(new Error("GlitchTip test event"));

Run the script, then open the project in GlitchTip. The test event appears in the Issues list within a few seconds.

Step 5: Serve the host over HTTPS with Caddy#

For routine use, put a domain and TLS in front rather than reaching the app over its raw HTTP port.

1. Create a DNS A record for your domain (for example errors.example.com) pointing at YOUR_FLOATING_IP. Follow How to point a domain at a Quake AI resource. Wait until it resolves:

dig +short errors.example.com

1. SSH to the instance and create /opt/glitchtip/Caddyfile:

errors.example.com {
  reverse_proxy 127.0.0.1:8000
}

1. Add Caddy to /opt/glitchtip/docker-compose.yml:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    network_mode: host
    volumes:
      - /opt/glitchtip/Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
volumes:
  caddy_data:

1. Update GLITCHTIP_DOMAIN in /opt/glitchtip/.env to https://errors.example.com, then apply:

cd /opt/glitchtip
sudo docker compose up -d

Update your application's DSN to the HTTPS domain once this is in place. For background on certificates, see How to issue and auto-renew a TLS certificate with Let's Encrypt.

What you built#

• Applied the glitchtip template to provision a network, security group, data volume, instance, and floating IP, with PostgreSQL, Redis, and GlitchTip's web and worker services started by cloud-init
• Registered the first account and disabled public self-signup
• Created a project and read its Sentry-compatible DSN
• Pointed a Sentry SDK at the DSN and confirmed a test event arrives
• Served the host over HTTPS through a Caddy reverse proxy

Scope of this deployment#

This template runs a single-VM GlitchTip host, not a managed error-tracking cloud. The instance is CPU-only and runs in one region, and it bundles PostgreSQL and Redis as containers on the same host. You operate the instance, Docker, GlitchTip, the database, Redis, and the data volume yourself: back them up, patch them, and snapshot the volume before you resize or rebuild. For higher event volume, move PostgreSQL and Redis onto their own instances and size the app host up.

Next steps#

• GlitchTip error-telemetry template: the template reference, parameters, and resource map
• Deploy Umami with the analytics-umami template: product analytics alongside this application-level error telemetry
• Monitoring stack: infrastructure metrics (CPU, memory, disk, and service health) for the machines underneath
• Self-hosted vibecode stack: where error telemetry fits in the broader self-hosted stack
• Security hardening checklist: tighten SSH access and exposure before you serve real traffic

Clean up#

When you no longer need the deployment, destroy everything the template created:

tofu destroy

Then remove the DNS A record you created in step 5 and update or remove the DSN from any application you pointed at this instance. Because GlitchTip, its database, Redis, and uploaded files all live on the instance and its attached volume, tofu destroy removes them along with the infrastructure.