GlitchTip

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	the name in `postgresHA.config.credentialsSecretName` (HA) or `postgres.config.credentialsSecretName` (single)	Dictionary secret the chart creates from `postgres.credentials.*` (`username`, `password`, `database`) and hands to whichever database is enabled	—
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	—
Secret	`RELEASE_NAME-redis-auth-password`	Redis password, created by the redis subchart from `redis.redis.auth.password.value`	`redis.enabled: true` (default)
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, the database and Redis secrets, your auth secret, 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 secret is not created by the template — see Prerequisites.

Prerequisites

The Django signing key and the initial superuser login guard a login form on a public endpoint, so they are a dictionary secret you create before installing rather than Helm values. Secrets are org-level, so no GVC flag is involved.

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 auth secret before installing. Installing without it 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.

Installation

Once the auth secret exists, install from the marketplace registry, pointing auth.secretName at it and replacing both bundled-component passwords:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/glitchtip \
  --version 1.3.1 --gvc GVC_NAME \
  --set auth.secretName=AUTH_SECRET_NAME \
  --set postgres.credentials.password='YOUR-DB-PASSWORD' \
  --set redis.redis.auth.password.value='YOUR-REDIS-PASSWORD'

postgres.credentials.password seeds the bundled database in both database modes. Installing a second GlitchTip release in the same org? Also set postgresHA.config.credentialsSecretName (or postgres.config.credentialsSecretName in single-instance mode) to a name no other release uses — secret names are org-wide. 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:
      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

When Redis is enabled the chart requires redis.redis.auth.password.enabled: true with a value, 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 chart builds the database credentials secret from postgres.credentials.* — there is nothing for you to create — and GlitchTip is wired to the active database automatically: the HAProxy leader endpoint in HA mode, the single instance directly otherwise.

postgres:
  credentials: # used in BOTH database modes — the chart writes these into the credentials secret
    username: glitchtip
    password: change-me-glitchtip-db # change before installing
    database: glitchtip

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
  config:
    credentialsSecretName: my-glitchtip-db-credentials # chart-created from postgres.credentials.*; secret names are org-wide, so give each release its own
  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 # chart-created from postgres.credentials.*; secret names are org-wide, so give each release its own
  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

postgres.credentials.password and redis.redis.auth.password.value seed their component on first boot and are used as-is — change both before installing. Later value edits do not update a database that has already initialized; 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 `cpln secret reveal RELEASE_NAME-redis-auth-password -o yaml`.

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.

Upgrading from 1.1.0

Version 1.2.0 adopted the postgres 3.4.1 template, which stopped taking database credentials as values. GlitchTip absorbed that change — the chart now creates the credentials secret itself — so there is no new prerequisite, only a rename of three keys in single-instance mode:

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

Move the keys, keep the same values so the running database still matches, and upgrade in place. A values file that still carries an old key fails the render with the postgres template’s message, which tells you to create a dictionary secret yourself — ignore that advice here; this template creates it.

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. The HA database credentials now come from the same postgres.credentials.* block as the single-instance ones, and the chart creates the secret named by postgresHA.config.credentialsSecretName for both stores.

Removed key (1.2.x)	Replacement (1.3.x)
`postgresHA.postgres.username`	`postgres.credentials.username`
`postgresHA.postgres.password`	`postgres.credentials.password`
`postgresHA.postgres.database`	`postgres.credentials.database`
`postgresHA.backup.minio.accessKey` / `postgresHA.backup.minio.secretKey`	a dictionary secret named by `postgresHA.backup.minio.credentialsSecretName`

Move the three credential values unchanged into postgres.credentials.* — the running cluster was initialized with them — 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.

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.

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: The prerequisite auth secret named by auth.secretName does not exist (or the optional email secret named by email.secretName does not).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.password.enabled must be true with a value or redis.redis.auth.password.value is required when redis is enabled.Cause: Redis is enabled without a password value. GlitchTip’s Sentinel connection URL embeds the password, so the chart requires one; the redis template’s fromSecret method is not supported here.Fix: Set redis.redis.auth.password.enabled: true and redis.redis.auth.password.value, or set redis.enabled: false to run the queue on PostgreSQL.

Second install refused as managed by a different release

Symptom: Installing a second GlitchTip release fails with cannot be updated because it is being managed by a different release and creates nothing.Cause: Both releases use the same credentials secret name (postgresHA.config.credentialsSecretName or postgres.config.credentialsSecretName). Secret names are org-wide, and the first release owns that one. Nothing is shared, overwritten, or deleted.Fix: Set a distinct secret name for the second release and install again.

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, or postgres-highly-available: the postgres block was REMOVED in 2.5.0.Cause: Your values file still carries a key from an earlier template version.Fix: Follow the table for your version under Upgrading from 1.0.x, Upgrading from 1.1.0, or Upgrading from 1.2.x. Do not create a database credentials secret yourself — this template creates it.

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 auth secret before installing — auth.secretName must name an existing dictionary secret with secretKey, adminEmail, and adminPassword. A missing secret wedges both workloads silently.
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.
Change postgres.credentials.password and redis.redis.auth.password.value before installing — both seed their component on first boot and are used as-is.
Give each release its own credentials secret name — secret names are org-wide, and a second release on the same name is refused at install.
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 auth secret survives. 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

Template Catalog

Templates

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

Upgrading from 1.1.0

Upgrading from 1.2.x

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

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

​Upgrading from 1.1.0

​Upgrading from 1.2.x

​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

Upgrading from 1.1.0

Upgrading from 1.2.x

Scaling and Availability

Troubleshooting

Important Notes

External References