Distributors and partners · Platform
Install AuthGuard on a customer's Kubernetes cluster (Helm)
Besides the shared service in the European Union, AuthGuard can run on a customer's own infrastructure. The chart deploy/helm/authguard runs the same image, settings and port as the cloud service; the full procedure is the runbook docs/runbooks/helm-install-upgrade-rollback.md in the AuthGuard repository. This article gives a distributor the picture before quoting.
What does the customer need?
| Need | Detail |
|---|---|
| Kubernetes | 1.27 or later; the pods meet the restricted Pod Security Standard |
| PostgreSQL 18 | External, with TLS, two databases (authguard and authguard_coordination); the chart bundles no database |
| Signing keys | AWS KMS keys for the post-quantum signature profile, and an identity the pods can use |
| TLS | A server certificate for the service's host; the pods terminate TLS 1.3 themselves, so publish them with an L4 load balancer or TLS passthrough, never an ingress that terminates TLS |
| Image | The release image, verified and mirrored to a registry the cluster can reach |
Sovereign installations also need the post-quantum PostgreSQL transport and an ML-DSA-65 certificate chain.
How does an installation go?
- Create the Kubernetes Secrets (database identities, TLS, application keys) from files: the chart never holds a secret value.
- Copy
values-standard.yamlorvalues-sovereign.yamlinto a site file and fill in every example value. - Run
helm upgrade --install. Helm first runs the migration jobs, then starts the service. - Create the first organization with the bootstrap token, then retire the bootstrap. See Self-hosted installation.
- Run the verification smoke after every install, upgrade and rollback.
What must the customer know about upgrades?
- Migrations only go forward. Back up the database before every upgrade.
- Do not use
--atomic: after a successful migration, the old pods cannot serve the new schema. - A release with migrations has a short gap of about one pod start; one without migrations rolls with no gap.
- Rolling back across a migration means restoring the backup taken before the upgrade.
What is not in the chart?
The audit workers run on hardened hosts with their systemd units, because Kubernetes volumes cannot meet their file-ownership checks under the restricted policy. The Entra and Active Directory synchronization workers run as CronJobs from their own images. Edge appliances install separately. See Install the Edge appliance.
Validation status
The chart passes its lint, template and static contract checks for both profiles, but has not yet been installed on a live cluster against a real PostgreSQL 18 and KMS. Plan the first installation in a staging environment and keep its smoke results before going to production.
Was this page helpful?
Thank you. Your answer stays in this browser; nothing is sent.
Sorry about that. Try:
- searching for the exact text of the message or the error code
- the error code index
- asking your organization's administrator