GlitchTip - Control Plane

Overview

GlitchTip is open-source, Sentry-API-compatible error tracking: applications report crashes and exceptions with the standard Sentry SDKs pointed at a GlitchTip DSN, and GlitchTip groups them into issues with alerting. It is MIT-licensed with nothing feature-gated. This template deploys a stateless GlitchTip web tier (UI, API, and SDK event ingest on port 8000) and a single background worker, backed by the redis template in Sentinel mode for the task queue and cache, and by PostgreSQL for all durable data — the postgres-highly-available template by default, or the single-instance postgres template with one flag. Public access is on by default so browser SDKs and applications outside the GVC can report events; self-signup is closed.

This template deploys into an existing GVC that you already have — it does not create or manage a GVC.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-glitchtip`	GlitchTip web: UI, API, and SDK event ingest on port `8000` (standard, `replicas` replicas)	—
Workload	`RELEASE_NAME-glitchtip-worker`	Background task worker and scheduler; runs database migrations and the superuser bootstrap at boot (standard, fixed 1 replica)	—
Workload	`RELEASE_NAME-postgres-ha`	Patroni PostgreSQL cluster from the postgres-highly-available template (stateful, `postgresHA.replicas` replicas)	`postgresHA.enabled: true` (default)
Workload	`RELEASE_NAME-etcd`	etcd cluster Patroni uses for leader election (stateful, 3 replicas)	`postgresHA.enabled: true` (default)
Workload	`RELEASE_NAME-postgres-ha-proxy`	HAProxy leader endpoint on port `5432` that GlitchTip connects through (standard, 2 replicas)	`postgresHA.enabled: true` (default)
Workload	`RELEASE_NAME-postgres-ha-backup`	Cron job that dumps the HA database to object storage	`postgresHA.backup.enabled: true` with `mode: logical`
Workload	`RELEASE_NAME-postgres`	Single-instance PostgreSQL from the postgres template (stateful, 1 replica)	`postgres.enabled: true`
Workload	`RELEASE_NAME-postgres-backup`	Cron job that dumps the single-instance database to object storage	`postgres.backup.enabled: true`
Workload	`RELEASE_NAME-redis`	Redis master and replica from the redis template (stateful, `redis.redis.replicas` replicas)	`redis.enabled: true` (default)
Workload	`RELEASE_NAME-sentinel`	Redis Sentinel on port `26379`, the address GlitchTip connects to (stateful, `redis.sentinel.replicas` replicas)	`redis.enabled: true` (default)
Volume set	`RELEASE_NAME-postgres-ha-vs`, `RELEASE_NAME-etcd-vs`	HA database and etcd data, 10 GiB per replica; takes no scheduled snapshots; a final snapshot is taken when the volume set is deleted and kept 7 days	`postgresHA.enabled: true` (default)
Volume set	`RELEASE_NAME-pg-vs`	Single-instance database data, 10 GiB; takes no scheduled snapshots; a final snapshot is taken when the volume set is deleted and kept 7 days	`postgres.enabled: true`
Volume set	`RELEASE_NAME-redis-vs`, `RELEASE_NAME-sentinel-vs`	Redis and Sentinel persistence, 10 GiB each with 7-day snapshots	`redis.enabled: true` (default)
Secret	`RELEASE_NAME-glitchtip-web-start`, `RELEASE_NAME-glitchtip-worker-start`	Start scripts that finalize the public URL and the Sentinel connection URL at boot	—
Identity	`RELEASE_NAME-glitchtip-identity`	Shared by the web and worker workloads	—
Policy	`RELEASE_NAME-glitchtip-policy`	Grants that identity `reveal` on exactly the secrets it reads: the start scripts, your database credentials, Redis password and auth secrets, and your email secret when configured	—
Identity / Policy	`RELEASE_NAME-postgres-ha-identity`, `RELEASE_NAME-etcd-identity`, `RELEASE_NAME-pg-identity`, `RELEASE_NAME-redis-identity`, `RELEASE_NAME-sentinel-identity` and their matching `-policy`	Per-component identities and least-privilege policies from the bundled templates	Follow the component

The web and worker tiers have no volumes of their own: every issue, event, and user lives in PostgreSQL. Your auth, database credentials and Redis password secrets are not created by the template — see Prerequisites.

Prerequisites

The database credentials, the Redis password, and the Django signing key and initial superuser login (which guard a login form on a public endpoint) are dictionary secrets you create before installing rather than Helm values. Secrets are org-level, so no GVC flag is involved.

Create the database credentials secret

The bundled PostgreSQL initializes with these values and GlitchTip connects with them, in either database mode:

cpln secret create-dictionary --name DB_CREDENTIALS_SECRET_NAME \
  --entry username=glitchtip \
  --entry password="$(openssl rand -hex 24)" \
  --entry database=glitchtip

Set its name in the key of the database mode you use: postgresHA.config.credentialsSecretName (HA, the default) or postgres.config.credentialsSecretName (single-instance). Secret names are org-wide, so give each GlitchTip release its own. PostgreSQL reads the secret only when its data is first initialized — see Rotating the Database Password.

Create the Redis password secret

Required while Redis is enabled (the default). Redis requires the password, and Sentinel and GlitchTip connect with it. No spaces, backslashes or double quotes: Redis writes it into its config file and will not start on them (the hex value below is safe):

cpln secret create-dictionary --name REDIS_SECRET_NAME \
  --entry password="$(openssl rand -hex 24)"

Set redis.redis.auth.fromSecret.name to this name. To change the password later, see Rotating the Redis Password.

Create the auth secret

A dictionary secret holding exactly three keys:

cpln secret create-dictionary --name AUTH_SECRET_NAME \
  --entry secretKey="$(openssl rand -hex 32)" \
  --entry adminEmail=admin@example.com \
  --entry adminPassword="$(openssl rand -hex 24)"

Set auth.secretName to this name.

Key	What it is
`secretKey`	Django’s `SECRET_KEY`, which signs sessions and tokens. Keep it for the life of the install: changing it logs every user out.
`adminEmail` / `adminPassword`	The initial superuser, seeded on first boot only. Afterwards manage accounts in the UI; editing the secret does not change the existing login.

Read the values back later with cpln secret reveal AUTH_SECRET_NAME -o yaml — the -o yaml is required, a bare reveal prints only a summary table.

Optional: create the email secret

Member invites, alert notifications, and password-reset mail are sent only when email.secretName names an opaque secret whose payload is a full email URL. Create it before installing; leave email.secretName empty to run without outbound email.

printf '%s' 'smtp://user:password@smtp.example.com:587' | cpln secret create-opaque --name EMAIL_SECRET_NAME --encoding plain -f -

Set email.secretName to this name and email.fromAddress to the sender address.

Optional: set up backup storage

Only if you plan to enable database backups — a bucket and access for one provider, plus a credentials secret for S3-compatible servers. See Backing Up.

Create the secrets before installing. Installing without one reports success, but both workloads then wedge silently — cpln logs returns nothing because no container ever starts, and the only place the missing secret is named is status.versions[].message:

cpln workload get-deployments RELEASE_NAME-glitchtip --gvc GVC_NAME -o yaml

The message reads

The secret AUTH_SECRET_NAME no longer exists. Workload updates are paused until the secret is added or the reference to the secret removed.

The command is get-deployments — plain cpln workload get has no versions key. Creating the secret lets the deployment recover on its own; cpln workload force-redeployment RELEASE_NAME-glitchtip --gvc GVC_NAME skips the wait, and the worker needs the same treatment. A missing Redis password secret also wedges RELEASE_NAME-redis and RELEASE_NAME-sentinel.

Installation

Once the three secrets exist, install from the marketplace registry, pointing the secret-name keys at them:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/glitchtip \
  --version 1.4.0 --gvc GVC_NAME \
  --set auth.secretName=AUTH_SECRET_NAME \
  --set postgresHA.config.credentialsSecretName=DB_CREDENTIALS_SECRET_NAME \
  --set redis.redis.auth.fromSecret.name=REDIS_SECRET_NAME

In single-instance mode set postgres.config.credentialsSecretName instead of postgresHA.config.credentialsSecretName. Other ways to install and manage the template:

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

Configuration

GlitchTip Web and Worker

Both workloads run the same image. The web tier is stateless and scales with replicas; the worker is a fixed singleton because it hosts the task scheduler and runs the database migrations at boot.

image: glitchtip/glitchtip:6.2.2

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

resources: # web workload
  minCpu: 250m
  minMemory: 512Mi
  maxCpu: 1000m
  maxMemory: 1Gi

worker:
  resources:
    minCpu: 250m
    minMemory: 512Mi
    maxCpu: 1000m
    maxMemory: 1Gi
  concurrency: 20 # async tasks processed in parallel (VTASKS_CONCURRENCY)

Authentication and Registration

auth:
  secretName: my-glitchtip-auth # REQUIRED prerequisite dictionary secret (secretKey, adminEmail, adminPassword) — must exist BEFORE install

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

Registration is closed by default, which overrides GlitchTip’s upstream open-signup default. With it closed, onboarding is the superuser creating accounts or sending invites — see First Run.

Email

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

The secret-creation command is in Prerequisites. The GlitchTip identity is granted reveal on exactly that secret.

Access

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

`internalAccess.type`	Who can reach the web workload over the internal network
`none`	No workload
`same-gvc`	Every workload in the same GVC (default)
`same-org`	Every workload in the same org
`workload-list`	Only the workloads listed in `internalAccess.workloads` (`//gvc/GVC_NAME/workload/WORKLOAD_NAME`)

domain is the URL GlitchTip embeds in every DSN and in the links of alert and invite emails. When it is empty, each workload derives the URL from its own endpoint at boot — fine for the web tier, but the worker, which sends the emails, has no public endpoint of its own. Set domain to the address your users actually open — the canonical endpoint of RELEASE_NAME-glitchtip or your custom domain, with the scheme and no trailing slash — and run a Helm upgrade whenever it changes. DSNs already issued keep the old URL, so update them in your applications too. Public access is on by default: SDK event ingest is the point of the service, and browser SDKs and applications outside the GVC must reach the endpoint to report anything. Set publicAccess.enabled: false for in-GVC reporters only and reach the UI through a tunnel (see Connecting). A change to either access knob takes a couple of minutes to take effect after the upgrade reports success.

Redis

By default the redis template runs in Sentinel mode and GlitchTip connects through Sentinel for its task queue, cache, and sessions. Set redis.enabled: false to run those on PostgreSQL instead — a lighter shape with no Redis workloads, at lower throughput.

redis:
  enabled: true
  redis:
    replicas: 2
    auth:
      fromSecret:
        enabled: true # required when redis is enabled (the chart enforces this)
        name: my-glitchtip-redis # PREREQUISITE dictionary secret (key: password) — must exist BEFORE install
    firewall:
      internal_inboundAllowType: same-gvc
    persistence:
      enabled: true
  sentinel:
    replicas: 3
    firewall:
      internal_inboundAllowType: same-gvc
    persistence:
      enabled: true

When Redis is enabled the chart requires redis.redis.auth.fromSecret.enabled: true with redis.redis.auth.fromSecret.name naming your Redis password secret, and requires Sentinel authentication to stay off — GlitchTip does not send a Sentinel password, so the same-GVC firewall is the boundary there. Every other knob of the redis template is available under redis.*.

Database

Enable exactly one database — the chart refuses to render with both or neither. The highly available cluster is the default; the single-instance template is one flag away for development and lightweight installs. In both modes the database credentials come from your prerequisite dictionary secret (username, password and database — see Prerequisites), and GlitchTip is wired to the active database automatically: the HAProxy leader endpoint in HA mode, the single instance directly otherwise.

Highly available (default)
Single instance

The postgres-highly-available template: 3 Patroni replicas, 3 etcd replicas, and the HAProxy leader endpoint GlitchTip connects to. Every knob of that template is available under postgresHA.*; postgresHA.proxy.enabled must stay true.

postgresHA:
  enabled: true
  image: controlplanecorporation/patroni-postgres:0.8 # pgvector 0.8.7 (CVE-2026-103484); tags 0.1-0.7 are refused
  config:
    credentialsSecretName: my-glitchtip-db-credentials # PREREQUISITE dictionary secret (username, password, database) — must exist BEFORE install
  replicas: 3
  volumeset:
    capacity: 10 # initial capacity in GiB per replica (minimum is 10)

  backup: # optional database backups — see Backing Up
    enabled: false
    mode: logical # logical or wal-g
    provider: aws # options: aws, gcp, minio

The postgres template. Disable postgresHA and enable postgres; every knob of that template is available under postgres.*.

postgresHA:
  enabled: false
postgres:
  enabled: true
  config:
    credentialsSecretName: my-glitchtip-db-credentials # PREREQUISITE dictionary secret (username, password, database) — must exist BEFORE install
  volumeset:
    capacity: 10 # initial capacity in GiB (minimum is 10)

  backup: # optional database backups (Postgres 17+) — see Backing Up
    enabled: false
    provider: aws # options: aws, gcp, minio

PostgreSQL reads its credentials secret only when its data is first initialized, and the Sentinels keep the Redis password they started with, so editing a secret alone changes neither — follow Rotating the Database Password or Rotating the Redis Password. Uninstalling the release deletes the volume sets, and a reinstall starts fresh.

Connecting

What	Address	Notes
Public UI and SDK ingest	`https://<canonical>.cpln.app`	Assigned automatically while `publicAccess.enabled` is `true`. Read it from `status.canonicalEndpoint` with `cpln workload get RELEASE_NAME-glitchtip --gvc GVC_NAME -o yaml`.
Login	`adminEmail` / `adminPassword` from `cpln secret reveal AUTH_SECRET_NAME -o yaml`	The superuser seeded on first boot.
Django admin	`https://<canonical>.cpln.app/admin/`	User management with the superuser login.
SDK DSN	Project → Settings → DSN in the UI	Embeds `domain` (or the derived endpoint); paste it into any Sentry SDK.
Health	`/_health/`	Unauthenticated, on the same host.
Internal (same GVC)	`http://RELEASE_NAME-glitchtip.GVC_NAME.cpln.local:8000`	Reachable per `internalAccess.type`; in-GVC SDKs can report here.
PostgreSQL (HA mode)	`RELEASE_NAME-postgres-ha-proxy.GVC_NAME.cpln.local:5432`	`username` / `password` / `database` from `cpln secret reveal SECRET_NAME -o yaml`, where `SECRET_NAME` is your `postgresHA.config.credentialsSecretName`.
PostgreSQL (single mode)	`RELEASE_NAME-postgres.GVC_NAME.cpln.local:5432`	Same keys, from the secret named by `postgres.config.credentialsSecretName`.
Redis Sentinel	`RELEASE_NAME-sentinel.GVC_NAME.cpln.local:26379`	Master name `mymaster`; password in the `password` key of `cpln secret reveal SECRET_NAME -o yaml`, where `SECRET_NAME` is your `redis.redis.auth.fromSecret.name`.

With publicAccess.enabled: false there is no public endpoint; reach the UI from your machine through a tunnel instead and open http://localhost:8000:

cpln port-forward RELEASE_NAME-glitchtip 8000:8000 --gvc GVC_NAME

First Run

GlitchTip has no setup wizard: the superuser from your auth secret is seeded by the worker on first boot, and that is the account you sign in with.

Wait for the web workload to report ready

The database and Redis come up first; the worker then runs the migrations and the web tier becomes ready once the schema is in place. On a fresh HA install this takes several minutes, and the worker restarts until the database leader is elected — that is expected.

cpln workload get-deployments RELEASE_NAME-glitchtip --gvc GVC_NAME -o yaml

If the web tier stays not-ready, read the worker’s logs first — migrations run there, not in the web tier:

cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-glitchtip-worker"}' --limit 50 --since 10m

Open the canonical endpoint (or the port-forward URL), sign in with adminEmail / adminPassword, and create your first organization — organization creation is open to signed-in users.

Create a project and copy its DSN

Create a project for your application’s platform, then copy the DSN from Project → Settings → DSN into your Sentry SDK configuration. Existing @sentry/* setups keep working — only the DSN changes.

Onboard your team

Registration is closed by default, so invites only work for accounts that already exist: create teammate accounts at /admin/ with the superuser login, then invite them to the organization from the UI. Invite emails require email.secretName. Set registration.enabled: true instead to allow self-signup on the endpoint.

Operations

Backing Up

Database backups are off by default and cover everything GlitchTip stores — issues, events, users, and organizations. Enable them under the database block you have enabled (postgresHA.backup.* or postgres.backup.*), choose a provider, and complete the matching storage setup before installing or upgrading with it on. In HA mode, backup.mode selects logical (a scheduled dump through the RELEASE_NAME-postgres-ha-backup cron workload) or wal-g (continuous archiving by a sidecar on the database workload); single-instance mode takes scheduled logical dumps through RELEASE_NAME-postgres-backup. The provider blocks have the same shape in both modes.

AWS S3
Google Cloud Storage
MinIO / S3-compatible

postgresHA: # or postgres: in single-instance mode — same keys
  backup:
    enabled: true
    provider: aws
    aws:
      bucket: my-glitchtip-backup-bucket
      region: us-east-1
      cloudAccountName: my-s3-cloud-account
      policyName: my-glitchtip-backup-policy
      prefix: postgres/backups

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 the AWS account holding the bucket. Set backup.aws.cloudAccountName to its name.

Create a bucket-scoped IAM policy

Create an IAM policy with the JSON below (replace YOUR_BUCKET) and set backup.aws.policyName to its 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/*"
    ]
  }]
}

postgresHA: # or postgres: in single-instance mode — same keys
  backup:
    enabled: true
    provider: gcp
    gcp:
      bucket: my-glitchtip-backup-bucket
      cloudAccountName: my-gcs-cloud-account
      prefix: postgres/backups

Create a bucket

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

Set up a cloud account

Create a cloud account for the GCP project holding the bucket and set backup.gcp.cloudAccountName to its name — access is keyless.

Grant storage access

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

postgresHA: # or postgres: in single-instance mode — same keys
  backup:
    enabled: true
    provider: minio
    minio:
      endpoint: http://my-minio-workload:9000
      bucket: my-glitchtip-backup-bucket
      credentialsSecretName: my-glitchtip-minio-credentials
      prefix: postgres/backups

Create a bucket

Create the bucket on your server. Set backup.minio.bucket to its name and backup.minio.endpoint to the S3 API address including the port — for the MinIO template in the same GVC, http://WORKLOAD_NAME.GVC_NAME.cpln.local:9000.

Create the credentials secret

Both database modes take the bucket credentials as a dictionary secret holding exactly accessKey and secretKey. Create it before enabling the backup and set backup.minio.credentialsSecretName to its name. No cloud account is involved.

cpln secret create-dictionary --name BACKUP_MINIO_SECRET_NAME \
  --entry accessKey=YOUR-ACCESS-KEY \
  --entry secretKey='YOUR-SECRET-KEY'

Two things a database backup does not cover: your auth secret, which lives in the secret you created, and source-map or artifact uploads, which GlitchTip keeps on local disk and which are lost on restart regardless. The database volume sets take no scheduled snapshots; a final snapshot is taken when the volume set is deleted and kept 7 days.

Restoring a Backup

No restore path has been rehearsed against this template. The outline below follows the backup job’s output format and the chart’s configuration; rehearse it against a scratch release before you depend on it. Restoring from a volume set snapshot is likewise unverified here.

Each logical backup is a gzip-compressed SQL dump of the whole server, so restoring means replaying it into the active database with psql from a client that can reach both the bucket and the database — a workload inside the GVC, or your own machine with a tunnel open. Connect as the username from your credentials secret to the postgres maintenance database; in HA mode go through the HAProxy endpoint so the writes land on the leader.

cpln port-forward RELEASE_NAME-postgres-ha-proxy 5432:5432 --gvc GVC_NAME

Use RELEASE_NAME-postgres as the workload name in single-instance mode. Then, with PGPASSWORD set to the password from the credentials secret:

aws s3 cp "s3://BUCKET_NAME/PREFIX/BACKUP_FILE.sql.gz" - \
  | gunzip \
  | psql --host=127.0.0.1 --port=5432 --username=USERNAME --dbname=postgres

Use gsutil cp "gs://BUCKET_NAME/PREFIX/BACKUP_FILE.sql.gz" - for GCS, and add --endpoint-url with your MinIO address for an S3-compatible server. The dump contains the role and database GlitchTip created at first boot, so a straight replay into a running instance collides with them: restore into an empty database (a fresh release, or one whose glitchtip database you have dropped) and keep the web and worker workloads from connecting until the replay has finished. The step-by-step restore procedures for each store, including the WAL-G outline for HA mode, are on the postgres-highly-available and postgres pages.

Upgrading from 1.0.x

Template version 1.1.0 moved the Django signing key and the superuser login out of Helm values into the prerequisite auth secret, and renamed the resource limits. Each removed or renamed key is rejected at render with a message naming its replacement, so a failing upgrade leaves the running release untouched. There are no compatibility fallbacks.

Removed or renamed in 1.0.x	Replacement in 1.1.0 and later
`django.secretKey`	`secretKey` key in the prerequisite auth secret
`admin.email`	`adminEmail` key in the same secret
`admin.password`	`adminPassword` key in the same secret
`resources.cpu` / `resources.memory`	`resources.maxCpu` / `resources.maxMemory`
`worker.resources.cpu` / `worker.resources.memory`	`worker.resources.maxCpu` / `worker.resources.maxMemory`

Put your existing secretKey into the secret rather than generating a new one. It signs live sessions and tokens: a new value logs every user out and invalidates password-reset links already in flight. Nothing is corrupted, but everyone has to sign in again.If your install still carries the published 1.0.x default signing key, its sessions and tokens are signed with a value printed in a public repository. Rotating it is the fix, and the cost is exactly that one forced sign-out — plan the upgrade for a quiet window rather than skipping it, and change the admin password in the UI at the same time.

Rotating the Database Password

PostgreSQL keeps the password it was initialized with, and a running workload keeps the values it started with, so in single-instance mode a rotation takes three steps in order (in HA mode follow Rotating the Database Password in HA Mode instead):

Change it in the database: ALTER ROLE DB_USERNAME PASSWORD 'NEW_PASSWORD'; (DB_USERNAME is the secret’s username; connect as that user from inside the GVC).

Update the secret — export it, change only password, and apply it:

cpln secret reveal SECRET_NAME -o yaml > secret.yaml
# edit only the password key in secret.yaml
cpln apply -f secret.yaml

Right away, redeploy GlitchTip:

cpln workload force-redeployment RELEASE_NAME-glitchtip --gvc GVC_NAME
cpln workload force-redeployment RELEASE_NAME-glitchtip-worker --gvc GVC_NAME

Do not redeploy the database: PostgreSQL reads the secret only when it is first initialized, so restarting it only adds downtime. Connections the app already has open keep working after ALTER ROLE; new ones fail until its redeploy finishes, so rotate in a quiet window.

Rotating the Database Password in HA Mode

The HA database (postgresHA) needs its own order. The replication role repl shares the password, and a member that restarts with the old password can be promoted to leader, which splits the cluster. Move the leader to member -0 first, so it restarts last, after every other member already has the new password. pgx runs a command in one member (LOCATION is your GVC’s location, DB_USERNAME the secret’s username):

pgx() { cpln workload exec RELEASE_NAME-postgres-ha --gvc GVC_NAME --location LOCATION \
  --container patroni-postgres --replica "RELEASE_NAME-postgres-ha-$1" -- "${@:2}"; }
# 1. Find the leader ("role": "leader"); the other two must be "streaming" on the same "timeline"
pgx 0 curl -s localhost:8008/cluster
# 2. If the leader is not RELEASE_NAME-postgres-ha-0, move it there (N = current leader), then repeat step 1
pgx 0 curl -s -XPOST -d '{"leader":"RELEASE_NAME-postgres-ha-N","candidate":"RELEASE_NAME-postgres-ha-0"}' localhost:8008/switchover
# 3. Change BOTH roles on -0
pgx 0 psql -h 127.0.0.1 -d postgres -c "ALTER ROLE DB_USERNAME PASSWORD 'NEW_PASSWORD'; ALTER ROLE repl PASSWORD 'NEW_PASSWORD';"
# 4. Right after, put the same password in the secret (edit only the password key in secret.yaml)
cpln secret reveal SECRET_NAME -o yaml > secret.yaml
cpln apply -f secret.yaml
# 5. Restart the members
cpln workload force-redeployment RELEASE_NAME-postgres-ha --gvc GVC_NAME
# 6. Once the restart completes, confirm one leader and two "streaming" replicas on one timeline (repeat step 1)
# 7. Optional: remove the install-time password Patroni keeps in its cluster config
pgx 0 curl -s -XPATCH -d '{"postgresql":{"authentication":null}}' localhost:8008/config

Then force-redeploy RELEASE_NAME-glitchtip-worker and RELEASE_NAME-glitchtip, which keep the old password until they restart. The database drops connections briefly at each switchover, and the app cannot open new connections from the ALTER ROLE until its own redeploy finishes, so rotate in a quiet window. If a member stays starting, or running without streaming, re-copy it from the leader. This copies the whole database, so it costs network traffic in proportion to its size:

pgx N curl -s -XPOST -d '{"force": true}' localhost:8008/reinitialize

Rotating the Redis Password

Redis keeps no password on disk, but the Sentinels do, so a new password is applied live in three places before anything restarts. Each Redis node first accepts both passwords, which keeps replication and every connected client working throughout. rx and sx run a command on one Redis node or Sentinel (LOCATION is your GVC’s location; nodes and Sentinels are numbered from 0 up to redis.redis.replicas and redis.sentinel.replicas minus one):

rx() { cpln workload exec RELEASE_NAME-redis --gvc GVC_NAME --location LOCATION \
  --container redis --replica "RELEASE_NAME-redis-$1" -- "${@:2}"; }
sx() { cpln workload exec RELEASE_NAME-sentinel --gvc GVC_NAME --location LOCATION \
  --container sentinel --replica "RELEASE_NAME-sentinel-$1" -- "${@:2}"; }
# 1. On EVERY Redis node: accept the new password alongside the old one, and replicate with it
rx 0 redis-cli --no-auth-warning -a OLD_PASSWORD ACL SETUSER default ">NEW_PASSWORD"
rx 0 redis-cli --no-auth-warning -a OLD_PASSWORD CONFIG SET masterauth NEW_PASSWORD
# 2. On EVERY Sentinel
sx 0 redis-cli -p 26379 SENTINEL SET mymaster auth-pass NEW_PASSWORD
# 3. Put the new password in the secret (edit only the password key in secret.yaml) and read it back
cpln secret reveal SECRET_NAME -o yaml > secret.yaml
cpln apply -f secret.yaml
cpln secret reveal SECRET_NAME -o yaml
# 4. Restart GlitchTip, which keeps the old password until it restarts
cpln workload force-redeployment RELEASE_NAME-glitchtip --gvc GVC_NAME
cpln workload force-redeployment RELEASE_NAME-glitchtip-worker --gvc GVC_NAME
# 5. Once get-deployments shows a higher version, alone and ready, for both: retire the old password on EVERY Redis node
rx 0 redis-cli --no-auth-warning -a NEW_PASSWORD ACL SETUSER default "<OLD_PASSWORD"

GlitchTip is briefly unavailable while it restarts. Redis and Sentinel need no restart: when they next start they read the new password from the secret.

Upgrading from 1.1.0

Version 1.2.0 adopted the postgres 3.4.1 template, which stopped taking database credentials as values. In single-instance mode these keys were removed:

Removed key (1.1.0)	Replacement
`postgres.config.username` / `postgres.config.password` / `postgres.config.database`	the `username`, `password` and `database` keys of the database credentials secret named by `postgres.config.credentialsSecretName`
`postgres.backup.minio.accessKey` / `postgres.backup.minio.secretKey`	a dictionary secret named by `postgres.backup.minio.credentialsSecretName`

Put the values your database was initialized with into the database credentials secret under Prerequisites, set postgres.config.credentialsSecretName to its name, and remove the old keys. A values file that still carries one fails the render with config.username was REMOVED in postgres 3.4.0. Then move the Redis password as described in Upgrading from 1.3.1.

Upgrading from 1.2.x

Version 1.3.0 adopted the postgres-highly-available 2.5.0 template, which made the same change on the HA path, and 1.3.1 did the same for its MinIO backup keys.

Removed key (1.2.x)	Replacement
`postgresHA.postgres.username` / `postgresHA.postgres.password` / `postgresHA.postgres.database`	the `username`, `password` and `database` keys of the database credentials secret named by `postgresHA.config.credentialsSecretName`
`postgresHA.backup.minio.accessKey` / `postgresHA.backup.minio.secretKey`	a dictionary secret named by `postgresHA.backup.minio.credentialsSecretName`

Put the three credential values unchanged into the database credentials secret under Prerequisites — the running cluster was initialized with them — set postgresHA.config.credentialsSecretName to its name, and delete the postgresHA.postgres block entirely; a values file that still carries it fails the render with the postgres-highly-available template’s the postgres block was REMOVED in 2.5.0 message. If you back up to an S3-compatible server, create the credentials secret described under Backing Up before upgrading. The upgrade re-points the web and worker workloads at the new secret, so expect them to redeploy; the database data is untouched. The details of the subchart change are under Upgrading From 2.4.x on the postgres-highly-available page. Then move the Redis password as described in Upgrading from 1.3.1.

Upgrading from 1.3.1

postgres.credentials was removed in 1.4.0: the database credentials are now a prerequisite secret, the same one the database templates require on their own. Carrying the old key forward fails the render. This applies to 1.3.0 as well. 1.3.x created the database secret itself, so this upgrade deletes it. Before upgrading, create a secret under a new name holding the values your database was initialized with — not new ones, or GlitchTip loses its database connection:

cpln secret create-dictionary --name RELEASE_NAME-glitchtip-db \
  --entry username=glitchtip \
  --entry password='YOUR_CURRENT_PASSWORD' \
  --entry database=glitchtip

Then upgrade with postgresHA.config.credentialsSecretName (HA mode) or postgres.config.credentialsSecretName (single-instance mode) set to that name, and postgres.credentials removed. Your current values are in postgres.credentials of the 1.3.x release, and also in the old secret (cpln secret reveal SECRET_NAME -o yaml, the name in credentialsSecretName, my-glitchtip-db-credentials by default) until the upgrade deletes it. redis.redis.auth.password was removed the same way (Redis enabled only): the Redis password is now a prerequisite secret too, and this upgrade deletes the RELEASE_NAME-redis-auth-password secret 1.3.x had the redis chart create. Create one under a new name holding your current Redis password — a new one would leave the Sentinels, which keep the password they started with on their volume, unable to reach Redis:

cpln secret create-dictionary --name RELEASE_NAME-glitchtip-redis \
  --entry password='YOUR_CURRENT_REDIS_PASSWORD'

Your current password is redis.redis.auth.password.value of the 1.3.x release, and also in cpln secret reveal RELEASE_NAME-redis-auth-password -o yaml until the upgrade deletes it. Upgrade with redis.redis.auth.fromSecret.name set to the new name and the whole redis.redis.auth.password block removed. The upgrade restarts the bundled PostgreSQL and Redis too (they now read the new secrets), so GlitchTip can briefly lose its database and task queue; it reconnects by itself. The new version of a workload can also wait several minutes with is not allowed to reveal the secret in get-deployments while access to the new secret propagates; the previous version keeps serving meanwhile, and it clears by itself.

The first Helm upgrade after an install can restart the bundled database and Redis even when their values are unchanged, so expect a brief interruption.

Upgrading from 1.4.0 or earlier

1.4.1 moves the HA database (postgresHA) to controlplanecorporation/patroni-postgres:0.8, which carries pgvector 0.8.7 (CVE-2026-103484). The fix takes effect when the upgrade restarts the Patroni members; existing data needs nothing. Nothing limits that rollout, so expect a brief interruption of writes while the leader changes. GlitchTip itself restarts without a gap: the new replica serves before the old one stops. Upgrade in a quiet window. If you pinned postgresHA.image in your values, set it to the 0.8 tag: tags 0.1 to 0.7 are refused at render. GlitchTip does not use the vector extension; if you created it yourself in a database, \dx keeps reporting the old version until you run ALTER EXTENSION vector UPDATE; there, which only updates that record. Single-instance mode (postgres) is unchanged.

Scaling and Availability

replicas is the scaling knob. The web tier is stateless — sessions, cache, and queue live in Redis, everything durable in PostgreSQL — so 2 or more web replicas behind the single endpoint gives high availability for the UI and for event ingest with no sticky sessions.

replicas: 2

The worker stays a fixed singleton: it hosts the task scheduler and runs the migrations at boot, and the chart does not expose a replica count for it. While the worker is down, the web tier keeps accepting events and the worker processes the backlog when it returns; worker.concurrency raises how many tasks it works in parallel. The default database is the 3-replica Patroni cluster with automatic leader failover behind the HAProxy endpoint, and Redis runs as a master and replica behind three Sentinels, so the datastores survive a replica loss without operator action. Switching to postgres.enabled: true trades that for a single database replica whose data survives restarts on its volume set — a node failure means minutes of downtime, not data loss. There is no in-place migration between the two database modes: pick one before the first install, or move the data with a backup and restore.

Troubleshooting

Neither workload becomes ready and the logs are empty

Symptom: cpln helm install reported success, cpln logs returns nothing for either workload, and cpln workload get-deployments RELEASE_NAME-glitchtip --gvc GVC_NAME -o yaml shows

The secret AUTH_SECRET_NAME no longer exists. Workload updates are paused until the secret is added or the reference to the secret removed.

under status.versions[].message.Cause: A prerequisite secret does not exist — the auth secret named by auth.secretName, the database credentials secret named by *.config.credentialsSecretName, the Redis password secret named by redis.redis.auth.fromSecret.name, or the optional email secret named by email.secretName. The message names the missing one.Fix: Create it (see Prerequisites). The deployment recovers on its own once the secret exists; cpln workload force-redeployment RELEASE_NAME-glitchtip --gvc GVC_NAME skips the wait — run it for RELEASE_NAME-glitchtip-worker too.

Web tier stays not-ready on a fresh install

Symptom: RELEASE_NAME-glitchtip never reports ready; its logs show the health check failing, and the worker restarts repeatedly.Cause: The web tier is not ready until the worker has finished the database migrations, and the worker cannot run them until the database accepts connections. On a fresh HA install the worker restarts until Patroni has elected a leader — this is expected and self-correcting.Fix: Wait, and read the worker’s logs rather than the web tier’s: cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-glitchtip-worker"}' --limit 50 --since 10m. A migration error there is the real failure; the web tier’s not-ready state is only the consequence.

Render fails asking you to enable exactly one database

Symptom: glitchtip: enable exactly one database — set either postgresHA.enabled or postgres.enabled to true, not both, or the matching message when both are false.Cause: postgresHA.enabled and postgres.enabled are both true or both false.Fix: Set exactly one of them to true — see Database.

Render fails because the redis password is required

Symptom: glitchtip: redis.redis.auth.fromSecret.enabled must be true when redis is enabled or redis.redis.auth.fromSecret.name is required when redis is enabled.Cause: Redis is enabled without the Redis password secret. GlitchTip’s Sentinel connection URL carries the password, read from the prerequisite secret named by redis.redis.auth.fromSecret.name.Fix: Create the Redis password secret (see Prerequisites) and set redis.redis.auth.fromSecret.enabled: true and redis.redis.auth.fromSecret.name, or set redis.enabled: false to run the queue on PostgreSQL.

Upgrade fails with a removed-key message

Symptom: The render fails with glitchtip: ... was removed in 1.1.0, config.username was REMOVED in postgres 3.4.0, postgres-highly-available: the postgres block was REMOVED in 2.5.0, postgres.credentials was REMOVED in 1.4.0, or redis.redis.auth.password was REMOVED in 1.4.0.Cause: Your values file still carries a key from an earlier template version.Fix: Follow the section for your version under Upgrading from 1.0.x, Upgrading from 1.1.0, Upgrading from 1.2.x, or Upgrading from 1.3.1.

Invite, alert, or password-reset emails never arrive

Symptom: An invite or alert is created in the UI and no email is delivered.Cause: email.secretName is empty, so outbound email is off; or domain is empty, so the links in the emails point at an address the recipient cannot open.Fix: Create the email secret and set email.secretName (see Prerequisites), set domain to the URL your users open (see Access), and run a Helm upgrade.

Symptom: Signing in or submitting a form in the UI fails, while the page itself loads.Cause: The browser origin does not match the URL GlitchTip trusts for form submissions. The start script trusts domain when it is set, otherwise the endpoint derived at boot — so this appears when you reach the UI through an address other than the one domain names.Fix: Open the UI at the address in domain (or the canonical endpoint when domain is empty). If you have moved to a custom domain, set domain to it and run a Helm upgrade.

Important Notes

Create the prerequisite secrets before installing — auth.secretName must name an existing dictionary secret with secretKey, adminEmail, and adminPassword, plus the database credentials secret and, with Redis enabled, the Redis password secret. A missing secret wedges the workloads silently; status.versions[].message from cpln workload get-deployments RELEASE_NAME-glitchtip --gvc GVC_NAME -o yaml names it.
Keep secretKey for the life of the install — rotating it logs every user out and invalidates password-reset links in flight. Nothing is corrupted.
The auth secret seeds the superuser once — editing it after first boot does not change the existing account. Change the password in the UI.
Set domain to the URL your users actually open — DSNs and emailed links embed it; after a change, upgrade and update the DSNs in your applications.
Changing a password takes more than a secret edit — the database password needs ALTER ROLE (and a leader switchover first in HA mode), the Redis password must be applied live on Redis and the Sentinels, and both need a forced redeployment of GlitchTip; see Rotating the Database Password and Rotating the Redis Password.
Give each release its own database credentials secret — secret names are org-wide.
Do not expect to scale the worker — it is a fixed singleton; replicas scales the web tier. Ingest keeps accepting events while the worker is down.
With registration closed, invites only work for existing accounts — create them at /admin/ first; invite and alert emails require email.secretName.
Pick the database mode before the first install — there is no in-place switch between postgresHA and postgres.
Source-map and artifact uploads are ephemeral — kept on local disk, lost on restart, and not shared across web replicas. Error ingest itself is unaffected.
Uninstalling deletes the volume sets and every issue, event, and user in them; your prerequisite secrets survive. Enable backups if the data matters.

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

​Overview

​What Gets Created

​Prerequisites

​Installation

UI

CLI

Terraform

Pulumi

​Configuration

​GlitchTip Web and Worker

​Authentication and Registration

​Email

​Access

​Redis

​Database

​Connecting

​First Run

​Operations

​Backing Up

​Restoring a Backup

​Upgrading from 1.0.x

​Rotating the Database Password

​Rotating the Database Password in HA Mode

​Rotating the Redis Password

​Upgrading from 1.1.0

​Upgrading from 1.2.x

​Upgrading from 1.3.1

​Upgrading from 1.4.0 or earlier

​Scaling and Availability

​Troubleshooting

​Important Notes

​External References

GlitchTip Documentation

Installation Reference

Sentry SDKs

GlitchTip 6 Release Notes

GlitchTip Backend Source

GlitchTip Template

Overview

What Gets Created

Prerequisites

Installation

Configuration

GlitchTip Web and Worker

Authentication and Registration

Email

Access

Redis

Database

Connecting

First Run

Operations

Backing Up

Restoring a Backup

Upgrading from 1.0.x

Rotating the Database Password

Rotating the Database Password in HA Mode

Rotating the Redis Password

Upgrading from 1.1.0

Upgrading from 1.2.x

Upgrading from 1.3.1

Upgrading from 1.4.0 or earlier

Scaling and Availability

Troubleshooting

Important Notes

External References