Skip to main content

​
Upgrades

Data Definition Language (DDL) changes apply automatically on startup.
Minor and patch releases contain no DDL changes and are safe to apply without a fresh backup. Major releases may include a DDL change, so back up first.
  1. Before a major-version upgrade, back up both PostgreSQL databases.
  2. Stop the stack, load the new images, and start it again. Expect brief downtime if you run a single stack.
  3. Pending DDL changes apply on boot. If the schema doesn’t match a clean upgrade path, startup stops rather than half-applying the change.
There is no rollback — a backup is your rollback path. To roll back, restore the backups and start the previous images, and never start older images against a newer database.

​
Backups and restore

PostgreSQL is the only stateful component; everything else rebuilds from it on start. Back up both databases and .env:
To restore, load the dumps into a fresh PostgreSQL and start the stack.

​
Configuration file management

Keep the generated secrets stable — changing SECRET_KEY logs users out, and changing CREDENTIAL_ENCRYPTION_LOCAL_KEY makes stored integration credentials unreadable. See Installation → Secrets for the full list.

​
High availability

A single stack is not highly available on its own. For high availability, run two stacks behind a load balancer.
In this mode, configuration changes can take up to 60 seconds to be reflected in the enforcement engine.

​
Data retention

The event table stores full agent transcripts and grows without bound. Choose a retention window and prune it on a schedule yourself.
Alerts reference events by id, so prune them on the same window.