# Deploy GlitchTip with the glitchtip template

Source: https://docs.quake.ai/resources/deployments/deploy-glitchtip-template
Markdown: https://docs.quake.ai/resources/deployments/deploy-glitchtip-template.md

---

# Deploy GlitchTip with the glitchtip template

Stand up [GlitchTip](https://glitchtip.com), an open-source, Sentry-protocol-compatible error tracker, on a single Quake AI instance using the [validated OpenTofu template](/docs/platform/validation#how-infrastructure-templates-are-checked) `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.

<Figure size="md" caption="What you'll build: a GlitchTip host on a single instance with bundled PostgreSQL and Redis, receiving Sentry-protocol events from an application SDK">

```d2
direction: right

dev: You {shape: person}
app: Your application\n(Sentry SDK)
fip: Floating IP
instance: Ubuntu instance {
  glitchtip: GlitchTip\nweb + worker
  db: PostgreSQL
  redis: Redis
  glitchtip -> db: events, projects
  glitchtip -> redis: queue + cache
}

dev -> fip: HTTPS dashboard
app -> fip: error events (DSN)
fip -> instance.glitchtip
```

</Figure>

<PricingCompanion
  components={[
    { kind: "template", slug: "glitchtip", required: true },
  ]}
/>

## 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](/docs/tools/openstack-cli).
- 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](/resources/iac-templates/glitchtip).
- 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`:

```bash
cp terraform.tfvars.example terraform.tfvars
```

```hcl
key_name = "YOUR_KEY_NAME"
```

Initialize, preview, and apply:

```bash
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`:

```bash
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:

```bash
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"
```



`ENABLE_USER_REGISTRATION` defaults to `true` so you can create the first account without a console session. Anyone who can reach the app before you disable it can also register. Keep `app_allowed_cidr` scoped to your IP or the private network until you complete this step.



## 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:

```bash
npm install @sentry/node
```

```ts

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](/docs/network/how-to/point-domain-to-quake-ai). Wait until it resolves:

```bash
dig +short errors.example.com
```

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

```text
errors.example.com {
  reverse_proxy 127.0.0.1:8000
}
```

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

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

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

```bash
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](/docs/network/how-to/lets-encrypt-certificate).

## 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](/resources/iac-templates/glitchtip): the template reference, parameters, and resource map
- [Deploy Umami with the analytics-umami template](/resources/deployments/deploy-analytics-umami-template): product analytics alongside this application-level error telemetry
- [Monitoring stack](/resources/iac-templates/monitoring-stack): infrastructure metrics (CPU, memory, disk, and service health) for the machines underneath
- [Self-hosted vibecode stack](/resources/solutions/self-hosted-vibecode-stack): where error telemetry fits in the broader self-hosted stack
- [Security hardening checklist](/docs/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:

```bash
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.