GlitchTip

Overview

GlitchTip is open-source, Sentry-API-compatible error tracking — applications report crashes and exceptions with standard Sentry SDKs pointed at a GlitchTip DSN, and GlitchTip groups them into issues with alerting. It is fully MIT-licensed with nothing feature-gated; there is no paid tier. This template deploys GlitchTip backed by a highly available PostgreSQL cluster and a Redis/Sentinel queue by default. The web UI and SDK event-ingest endpoint are served on one public HTTPS endpoint, and the admin account is created automatically on first boot — so there is never an unauthenticated setup page and self-signup is closed by default.

Architecture

GlitchTip web — A stateless standard workload (default 1 replica, replicas knob for more) serving the UI, API, and SDK event ingest on port 8000.
GlitchTip worker — A single-replica standard workload running the background task worker and scheduler; it also runs database migrations and the superuser bootstrap at boot. It is a fixed singleton and is not scaled.
PostgreSQL (HA, default) — The postgres-highly-available template as a subchart: 3× Patroni PostgreSQL, 3× etcd, and a HAProxy leader-routing endpoint GlitchTip connects through. Holds all issue and event data.
PostgreSQL (dev/lightweight, optional) — The single-instance postgres template instead, for lighter non-HA deployments.
Redis + Sentinel (default, optional) — The redis template in Sentinel mode: the task queue, cache, and sessions. Disable it to run those on PostgreSQL instead (a lighter dev shape).

What Gets Created

Standard GlitchTip Web Workload — The stateless web tier serving the UI, API, and SDK event ingest on port 8000 (replicas controls its scale).
Standard GlitchTip Worker Workload — A single-replica worker + scheduler that runs migrations and the admin bootstrap at boot.
Database Workloads — HA mode: a stateful Patroni PostgreSQL workload, a stateful etcd workload, and a standard HAProxy leader-routing workload. Single mode: one stateful PostgreSQL workload.
Redis Workloads (default) — A master-replica Redis deployment with Sentinel for failover. Omitted when redis.enabled is false.
Volume Sets — The database subchart’s persistent volumes (10 GiB per replica by default), plus Redis persistence when enabled. The GlitchTip web and worker tiers have no volumes of their own.
Secrets — The Django SECRET_KEY, admin bootstrap credentials, two start scripts, and the database and Redis credentials from the subcharts.
Identity & Policy — A shared identity for the web and worker workloads and a least-privilege policy granting it reveal on exactly the secrets it uses (including the optional email secret when configured).

This template does not create a GVC. You must deploy it into an existing GVC.

Prerequisites

None for a default install.
Optional — outbound email (member invites, alerts, password resets): create an opaque secret in your org, with encoding plain, whose payload is a full email URL, for example smtp://user:password@smtp.example.com:587. Set its name in email.secretName and create it before installing. Leave email.secretName empty to run without email.
Optional — database backups: a bucket and access setup for one of the supported providers — see Backing Up.

Change the generated credentials

Change django.secretKey, admin.password, the database password (postgresHA.postgres.password or postgres.config.password), and the Redis password (redis.redis.auth.password.value) from their placeholder defaults before installing.

(Optional) Create the email secret

If you want outbound email, create the opaque secret described above and set email.secretName to its name before installing.

Install the template using your preferred method:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Choosing a Database Mode

Exactly one of the two database modes must be enabled — the chart enforces this at render and fails the install with a clear message otherwise.

	`postgresHA` (default)	`postgres`
What runs	3× Patroni PostgreSQL, 3× etcd, HAProxy leader endpoint	One single-replica PostgreSQL workload
Database failover	Automatic (Patroni leader election)	None
First-boot readiness	~4–6 minutes (worker waits for the HA proxy to open before migrations)	Under a minute
Best for	Production	Development and lightweight installs

Choosing a Queue Mode

By default the redis template is deployed and GlitchTip runs its task queue, cache, and sessions through Redis Sentinel. Set redis.enabled: false to run those on PostgreSQL instead — a lighter “lean” shape with no Redis workloads, at lower throughput. Both modes are supported upstream and are proven end to end.

Configuration

The default values.yaml for this template:

image: glitchtip/glitchtip:6.2.2

replicas: 1 # web tier — stateless; set 2+ for high availability (state lives in PostgreSQL/Redis)

resources: # web workload
  cpu: 1000m
  memory: 1Gi
  minCpu: 250m
  minMemory: 512Mi

worker: # background worker + scheduler; runs migrations and admin bootstrap at boot (single replica)
  resources:
    cpu: 1000m
    memory: 1Gi
    minCpu: 250m
    minMemory: 512Mi
  concurrency: 20 # async tasks processed in parallel (VTASKS_CONCURRENCY)

django:
  secretKey: change-me-glitchtip-secret-key # session/token signing key — change before installing; rotating later logs out all users

admin: # superuser seeded on first boot only — log in with these, then manage in the UI
  email: admin@example.com
  password: change-me-glitchtip-admin # change before installing

registration:
  enabled: false # open self-signup on the endpoint; admin-created users and invites work regardless

email:
  secretName: "" # name of a pre-created opaque secret whose payload is an EMAIL_URL (create BEFORE install; empty = outbound email off)
  fromAddress: glitchtip@example.com # DEFAULT_FROM_EMAIL — used only when secretName is set

domain: "" # full URL used in DSNs and email links (e.g. https://errors.example.com); empty = canonical *.cpln.app endpoint
publicAccess:
  enabled: true # UI + SDK event ingest (DSN) on the canonical *.cpln.app HTTPS endpoint

internalAccess: # internal firewall scope (in-GVC SDK callers)
  type: same-gvc # options: none, same-gvc, same-org, workload-list
  workloads: [] # used with workload-list

redis: # task queue / cache / sessions (default)
  enabled: true # false = PostgreSQL carries the queue, cache, and sessions (lighter dev shape)
  redis:
    replicas: 2
    auth:
      password:
        enabled: true
        value: change-me-glitchtip-redis # change before installing (any characters OK — the boot script percent-encodes it)
    firewall:
      internal_inboundAllowType: same-gvc
    persistence:
      enabled: true
  sentinel:
    replicas: 3
    firewall:
      internal_inboundAllowType: same-gvc
    persistence:
      enabled: true

postgresHA: # default: highly available PostgreSQL
  enabled: true
  postgres:
    username: glitchtip
    password: change-me-glitchtip-db-password # change before installing
    database: glitchtip
  replicas: 3
  volumeset:
    capacity: 10 # initial capacity in GiB per replica (minimum is 10)
  backup:
    enabled: false # optional — see Backing Up
    mode: logical # logical or wal-g
    resources:
      cpu: 100m
      memory: 128Mi
    logical:
      image: ghcr.io/controlplane-com/backup-images/postgres-backup:17.1.0
      schedule: "0 2 * * *"
    walg:
      intervalSeconds: 21600
    provider: aws # options: aws, gcp, minio
    aws:
      bucket: glitchtip-pg-backup-bucket
      region: us-east-1
      cloudAccountName: my-s3-cloud-account
      policyName: glitchtip-pg-backup-policy
      prefix: postgres/backups
    gcp:
      bucket: glitchtip-pg-backup-bucket
      cloudAccountName: my-gcs-cloud-account
      prefix: postgres/backups
    minio:
      endpoint: http://my-minio-workload:9000
      bucket: glitchtip-pg-backup-bucket
      accessKey: my-minio-username
      secretKey: my-minio-password
      prefix: postgres/backups

postgres: # dev/lightweight: single-instance PostgreSQL (disable postgresHA first)
  enabled: false
  config:
    username: glitchtip
    password: change-me-glitchtip-db-password # change before installing
    database: glitchtip
  volumeset:
    capacity: 10 # initial capacity in GiB (minimum is 10)
  backup:
    enabled: false # optional — see Backing Up
    image: ghcr.io/controlplane-com/backup-images/postgres-backup:18.1.0
    schedule: "0 2 * * *"
    resources:
      cpu: 100m
      memory: 128Mi
    provider: aws # options: aws, gcp, minio
    aws:
      bucket: glitchtip-pg-backup-bucket
      region: us-east-1
      cloudAccountName: my-s3-cloud-account
      policyName: glitchtip-pg-backup-policy
      prefix: postgres/backups
    gcp:
      bucket: glitchtip-pg-backup-bucket
      cloudAccountName: my-gcs-cloud-account
      prefix: postgres/backups
    minio:
      endpoint: http://my-minio-workload:9000
      bucket: glitchtip-pg-backup-bucket
      accessKey: my-minio-username
      secretKey: my-minio-password
      prefix: postgres/backups

image — The GlitchTip container image (used by both the web and worker workloads).
replicas — Web-tier replica count. The web tier is stateless (all state is in PostgreSQL and Redis), so scaling to 2 or more gives high availability. The default 1 renders the proven single-replica shape.
resources — CPU and memory for the web container.
worker.resources — CPU and memory for the worker container.
worker.concurrency — Number of async tasks the worker processes in parallel (VTASKS_CONCURRENCY).
django.secretKey — Session and token signing key. Change it before installing. Rotating it later logs out all users but corrupts nothing. It is stored as a secret reference, never in plaintext.
admin.email / admin.password — The superuser account, seeded on first boot only. Change admin.password before installing. Log in with these, then manage users in the UI; changing the values later does not modify the existing account.
registration.enabled — Open self-signup on the public endpoint. Default false (closed) — admin-created users and invites still work either way. See Onboarding Users.

Email

email.secretName — Name of your pre-created opaque secret whose payload is an EMAIL_URL (see Prerequisites). Empty (default) turns outbound email off. Member invites, alert notifications, and password-reset mail all require this to be set.
email.fromAddress — The From address used on outbound mail; applied only when email.secretName is set.

Access

publicAccess.enabled — Serve the UI and SDK event ingest (the DSN endpoint) on the canonical *.cpln.app HTTPS endpoint (default). Because Sentry SDKs typically run outside the GVC, public access is on by default. Set to false for an internal-only instance (external requests are blocked at the edge; in-GVC callers still reach it per internalAccess).
internalAccess.type — Internal firewall scope of the web workload:

Type	Description
`none`	No internal access.
`same-gvc`	Allow access from all workloads in the same GVC (default).
`same-org`	Allow access from all workloads in the same organization.
`workload-list`	Allow access only from workloads listed in `internalAccess.workloads`.

domain — Full URL (for example https://errors.example.com) embedded in DSNs and email links. Empty (default) uses the canonical *.cpln.app endpoint, derived automatically at boot.

Queue / Cache: Redis

redis.enabled — Deploy the Redis subchart in Sentinel mode for the task queue, cache, and sessions (default). Set to false to carry those on PostgreSQL instead — see Choosing a Queue Mode.
redis.redis.replicas — Redis master-replica count.
redis.redis.auth.password.value — The Redis password. Required when Redis is enabled (the chart enforces it). Change it before installing — any characters are fine, the boot script percent-encodes it into the connection URL.
redis.sentinel.replicas — Number of Sentinel instances. Sentinel authentication must stay disabled — GlitchTip cannot send a Sentinel password; the same-GVC firewall is the boundary there.
redis.redis.persistence.enabled / redis.sentinel.persistence.enabled — Persistent storage for Redis and Sentinel.

Database

Enable exactly one of postgresHA (production, default) or postgres (dev/lightweight) — see Choosing a Database Mode. In both modes, change the database password before installing (postgresHA.postgres.password / postgres.config.password). GlitchTip is wired to the active database automatically — the HAProxy leader endpoint in HA mode, or the single instance directly in dev mode.

Onboarding Users

Registration is closed by default (registration.enabled: false) — an override of GlitchTip’s upstream open-signup default. With registration closed, invites only work for accounts that already exist: create teammate accounts first through the Django admin at https://<canonical>.cpln.app/admin/ (log in with the superuser account), then invite them to your organization. Invite, alert, and password-reset emails require email.secretName to be set. To allow open self-signup instead, set registration.enabled: true.

Connecting

What	Value
UI (public)	`https://<canonical>.cpln.app` — `status.canonicalEndpoint` of `{release}-glitchtip`
SDK DSN	Copy from the UI: project → Settings → DSN (it embeds the public endpoint)
Internal (same GVC)	`http://{release}-glitchtip.{gvc}.cpln.local:8000`
Login	`admin.email` / `admin.password`
Django admin (user management)	`https://<canonical>.cpln.app/admin/`
PostgreSQL (internal, HA mode)	`{release}-postgres-ha-proxy.{gvc}.cpln.local:5432`, credentials in the `{release}-postgres-config` secret
PostgreSQL (internal, single mode)	`{release}-postgres.{gvc}.cpln.local:5432`, credentials in the `{release}-pg-config` secret

Reporting Errors

Point any Sentry SDK at your project’s DSN. The DSN is issued in the UI under project → Settings → DSN and embeds the public endpoint, so no extra configuration is needed. Existing @sentry/* SDK setups keep working — only the DSN changes. SDKs running inside the same GVC can send events to the internal endpoint per internalAccess.

Backing Up

Database backups are optional and disabled by default. They cover the PostgreSQL database — the issues, events, and users that make up your GlitchTip instance. Enable them with postgresHA.backup.enabled or postgres.backup.enabled (matching your database mode), and complete the storage setup for your provider before installing. The values below are shown under backup.* — set them within the enabled database block.

AWS S3
Google Cloud Storage
S3-compatible (MinIO, R2, Wasabi)

Create a bucket

Create an S3 bucket. Set backup.aws.bucket and backup.aws.region to match.

Set up a Cloud Account

If you do not have one, create a Cloud Account for your AWS account. Set backup.aws.cloudAccountName to its name.

Create a bucket-scoped IAM policy

Create an AWS IAM policy with the JSON below (replace YOUR_BUCKET), then set backup.aws.policyName to the policy’s name:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:ListBucket",
      "s3:GetBucketLocation",
      "s3:GetObject",
      "s3:GetObjectVersion",
      "s3:PutObject",
      "s3:DeleteObject",
      "s3:DeleteObjectVersion",
      "s3:AbortMultipartUpload"
    ],
    "Resource": [
      "arn:aws:s3:::YOUR_BUCKET",
      "arn:aws:s3:::YOUR_BUCKET/*"
    ]
  }]
}

Create a bucket

Create a GCS bucket. Set backup.gcp.bucket to its name.

Set up a Cloud Account

If you do not have one, create a Cloud Account for your GCP project. Set backup.gcp.cloudAccountName to its name — access is keyless (no stored credentials).

Grant the Storage Admin role (or roles/storage.objectAdmin scoped to the bucket) to the GCP service account created for the Cloud Account.

Create a bucket

Create your bucket on the server. Set backup.minio.bucket to its name.

Set the endpoint

Set backup.minio.endpoint to the S3 API address including port. For the minio marketplace template deployed in the same GVC, this is http://WORKLOAD_NAME:9000.

Set credentials

Set backup.minio.accessKey and backup.minio.secretKey to credentials with access to the bucket.

In HA mode, backup.mode selects logical (scheduled pg_dump via a cron workload) or wal-g (continuous WAL archiving). The single-instance mode takes scheduled logical dumps.

Important Notes

Change django.secretKey, admin.password, the database password, and the Redis password before installing.
Do not scale the worker — it is a fixed singleton (scheduler plus boot-time migrations). Web replicas is the scaling knob; a worker outage pauses processing but ingest keeps accepting events and catches up when the worker returns.
First boot: the web tier stays not-ready until the worker finishes migrations — roughly 4–6 minutes in HA mode while the worker waits for the PostgreSQL HA proxy to open, then self-heals. If it seems stuck, check the worker logs first, not the web logs.
With registration closed (default), invites only work for accounts that already exist — create teammate accounts first at /admin/, then invite them. Invite and alert emails require email.secretName. See Onboarding Users.
DSNs embed the endpoint URL — if you add a custom domain later, set domain, run a Helm upgrade, and update the DSNs in your apps.
Source-map / artifact uploads are ephemeral (local disk) — lost on restart and not shared across web replicas. Error ingest itself is unaffected; events go to PostgreSQL.
Uninstall deletes the database volume sets — all issues, events, and users. Enable backups if the data matters.
This template ships the MIT-licensed open-source image — GlitchTip is a single edition with nothing feature-gated.

External References

GlitchTip Documentation

Official GlitchTip documentation

Installation Reference

Installation and configuration reference

Sentry SDKs

Client setup for the Sentry SDKs GlitchTip is compatible with

GlitchTip 6 Release Notes

What changed in the GlitchTip 6 release line

GlitchTip Backend Source

Upstream GlitchTip backend source

GlitchTip Template

View the source files, default values, and chart definition

Template Catalog

Templates

GlitchTip

Overview

Architecture

What Gets Created

Prerequisites

UI

CLI

Terraform

Pulumi

Choosing a Database Mode

Choosing a Queue Mode

Configuration

GlitchTip

Email

Access

Queue / Cache: Redis

Database

Onboarding Users

Connecting

Reporting Errors

Backing Up

Important Notes

External References

GlitchTip Documentation

Installation Reference

Sentry SDKs

GlitchTip 6 Release Notes

GlitchTip Backend Source

GlitchTip Template

​Overview

​Architecture

​What Gets Created

​Prerequisites

UI

CLI

Terraform

Pulumi

​Choosing a Database Mode

​Choosing a Queue Mode

​Configuration

​GlitchTip

​Email

​Access

​Queue / Cache: Redis

​Database

​Onboarding Users

​Connecting

​Reporting Errors

​Backing Up

​Important Notes

​External References

GlitchTip Documentation

Installation Reference

Sentry SDKs

GlitchTip 6 Release Notes

GlitchTip Backend Source

GlitchTip Template

Overview

Architecture

What Gets Created

Prerequisites

Choosing a Database Mode

Choosing a Queue Mode

Configuration

GlitchTip

Email

Access

Queue / Cache: Redis

Database

Onboarding Users

Connecting

Reporting Errors

Backing Up

Important Notes

External References