Backing up and restoring authentik: what a complete backup covers
A complete authentik backup has two parts: a copy of the PostgreSQL database and copies of the file directories that the database does not hold. PostgreSQL stores all users, policies, flows, providers and configuration, so it carries nearly everything you would need to rebuild your identity setup. Uploaded and generated files live outside the database, though, so a database-only backup can leave you with users and applications that point at certificates, templates or storage paths that no longer exist. Plan both parts together from the start, and treat any production deployment as needing this plan, whatever its size.
authentik runs as two containers from the same image: a server container, which runs the core application with an embedded outpost, and a worker container, which runs background tasks. Neither container should hold state you cannot rebuild. The state sits in PostgreSQL and in the mounted directories, so your backup target is the database plus those mounts, not the containers. Confirm exactly which volumes or paths your Docker Compose or Helm setup mounts for /data, /certs, /custom-templates and /blueprints, and whether you use S3 storage for uploaded files. Ask your team to write this inventory down, because it is the list your restore will be checked against.
A backup does not replace high availability or monitoring. A replica or a second server keeps authentik running through a node failure, but it copies bad changes just as quickly, and it does not give you an older point to return to. Backups also do not tell you that a worker has stopped or that logins are failing. Keep backups for recovery, use replication for uptime, and use monitoring to see problems early. The authentik backup and restore documentation is the reference for the directory list, and you should confirm it against the release you run.
Which parts of authentik to back up and when each applies
This table lists each part of an authentik deployment that may need backing up, what it holds, when it is required and which condition changes the decision. Read it against your own storage layout: the PostgreSQL database is always in scope, while the static directories depend on whether you use S3, whether certificates are imported elsewhere and whether you customize templates or blueprints.
| Component | What it holds | When it applies |
|---|---|---|
| PostgreSQL database | All users, policies, flows and configuration, plus event and session data | Always. Back it up with pg_dump, pg_dumpall or continuous archiving, stored off the database host where possible |
| /data directory | Uploaded files and other local data written by the server | Required unless S3 storage is used. Skip it when all file storage sits in S3 |
| /certs directory | Certificates and keys imported into authentik | Required only if certificates are not already kept in another system you can re-import from |
| /custom-templates directory | Your customized HTML templates for flows and pages | Required if you have changed any template. Skip it on a stock deployment |
| /blueprints directory | Blueprint files that declare configuration as code | Optional. Keep it if blueprints are the only record of your configuration, or if you also keep them in version control |
| S3 buckets | Files stored in object storage in place of /data | Required when S3 storage is in use. Confirm bucket versioning or replication with your storage team and the authentik backup guide |
How pg_dump, pg_dumpall and continuous archiving differ for authentik
The choice between logical dumps and continuous archiving comes down to how much data loss your organization accepts and how long a restore may take. authentik keeps all users, policies, flows and configuration in PostgreSQL, so the database backup is the part of the plan that cannot be rebuilt from files. The authentik backup documentation names pg_dump, pg_dumpall and continuous archiving as options, and the restore must put the database back before authentik restarts.
A logical dump with pg_dump (one database) or pg_dumpall (the whole cluster, including roles) produces a file you can read, copy and restore into a server of a compatible version. Recovery is simple to reason about, but the recovery point is the moment the dump finished, so anything changed after that is lost, and restore time grows with database size. Continuous archiving takes a base backup and ships write-ahead log segments as they are produced, which is the approach described in the PostgreSQL continuous archiving and point-in-time recovery documentation. It narrows the recovery point and supports restoring to a chosen moment, at the cost of more moving parts: archive storage, retention of the archived segments, and a tested restore procedure.
Store either form off the database host where possible, so a failed server or disk does not take the backups with it. Ask your PostgreSQL platform team which method they already run, how often backups complete, how long a restore of your database size takes in a rehearsal, and where the archives live and for how long they are kept. Confirm those details against your own platform, since the sources do not give timings or storage sizes for authentik deployments.
Setting up a backup routine that you can restore
This sequence turns authentik backups from files that exist into backups you have proven you can restore. It covers the database, the file directories, off-host copies, version records and a scheduled restore test on a separate environment.
Inventory the deployment before writing any backup job
Record how authentik runs (Docker Compose or the Helm chart), whether uploaded files live in local
/dataor in S3 storage, and where TLS certificates come from, either imported into authentik or held in/certs. Also record where PostgreSQL runs, whether it is the chart's bundled database or a separately managed one, and who has access to each. Done means you have a written list of every component that holds state, with its owner and location. Ask your platform team to confirm the storage mode, because the list of directories to back up depends on it.Schedule a PostgreSQL backup that runs off the database host
PostgreSQL holds all authentik users, policies, flows and configuration, so it is the backup that matters most. Choose pg_dump or pg_dumpall for a logical dump, or continuous archiving if you need point-in-time recovery, and schedule it with credentials kept out of the job definition. Write the output to storage separate from the database host where possible. Check the result immediately: the dump file should exist, be non-empty, and be readable by the restore tool (for example, by listing its contents with pg_restore --list for custom-format dumps). Keep a failed-run alert on the job so a silent failure does not go unnoticed.
Capture the file directories at one consistent point
Back up
/data(unless you use S3 storage),/custom-templates,/certswhen certificates are not already imported, and optionally/blueprints. Run these captures in the same window as the database dump, and stop or quiesce writes where your setup allows, so the files and database describe the same moment. Mismatched timestamps can leave uploaded files or certificate references pointing at records that do not exist after restore. Confirm each archive lists the expected paths and that the directory sizes are plausible compared with the previous run.Back up S3 buckets with their own schedule
If authentik stores uploaded files in S3, the bucket is not covered by a copy of
/data. Enable whatever versioning, replication or bucket-level backup your storage platform provides, and confirm with your storage team what retention applies. Verify by listing object counts or checking a sample object's version history against the database backup window. This step is only needed for S3 storage mode, so skip it and record that decision in your inventory if you do not use S3.Copy every backup off the host and encrypt it
Move the database dumps, directory archives and any bucket exports to storage that survives loss of the authentik host, such as an object store or backup platform in another location you control. Encrypt backups at rest and restrict access, because they contain password hashes, secrets and signing keys. Confirm the copy by comparing checksums between the source and the destination. A backup that exists only on the machine it protects is not a recovery plan.
Record the authentik and PostgreSQL versions with each backup
Write a manifest beside every backup set containing the authentik version, the PostgreSQL major version, the deployment method and the backup timestamp. The restore must use the same authentik version the data came from, and the PostgreSQL major version determines the restore target. Store the manifest with the backup, not in a wiki, so the information travels with it. Check that each manifest matches the running system at backup time, and flag any mismatch for review before the next upgrade.
Run a scheduled restore test on a separate environment
Restore the most recent backup set to an isolated instance, following the documented order: restore the database first, then start authentik with the restored directories. Confirm the restore by signing in with a test user, checking that an application's provider still issues tokens, and reviewing that uploaded files and custom templates load. Record the result, the time taken and any manual steps in the restore runbook. Repeat this on a schedule you set, and treat a failed test as an incident. Ask the authentik team or DeployOpen to review the runbook if the test uncovers gaps.
Restore order: database first, then authentik
Restore PostgreSQL before you start authentik. This is the documented order, and it matters because the database holds all users, policies, flows and configuration. If authentik starts against an empty or older database, it will run migrations or present a fresh-looking install, and the restored data can be harder to reconcile than to rebuild. Start by provisioning a PostgreSQL server at the same major version as the one that produced the backup, then restore the dump or replay the base backup and archived WAL files to the point you intend to recover. Confirm the restore completed cleanly and that you can connect with the credentials authentik will use.
Next, restore the file-based state that the database does not hold. Put back /data if you do not use S3 storage, then /certs if the certificates were not already imported into authentik, then /custom-templates and, if you back it up, /blueprints. Confirm that the restored S3 bucket is reachable with the same access settings if object storage is in use. Keep the restored authentik version identical to the version that produced the backup. Any version change belongs in a separate, planned upgrade with its own rollback point, not folded into the restore.
Only then start the worker and server containers, so the worker can pick up scheduled and background tasks against a consistent database. Verify three things: an administrator can sign in, a test user can complete a login through a non-critical application, and any proxy or LDAP outpost reconnects to the server. Check the logs for migration messages or missing file errors before declaring success. Record the restore point and the checks you ran, because the first questions after an incident are usually which data was current and which version was running.
Protecting backups that contain identity data
An authentik backup holds the same material as the live directory: user records, password hashes, signing keys and certificates. The cards below cover how to control who can read, store, restore and keep those copies, and what to confirm with your security team before the first backup runs.
Restrict and encrypt every copy
A database dump or archive of authentik contains password hashes and configuration that can be used to impersonate users. Limit read access to the few people and services that run backups, encrypt the files at rest, and send them over encrypted channels. Keep the /certs and /data copies under the same controls as the database dump, since they hold keys and uploaded material. Confirm the encryption method with your security team, because this page does not prescribe a product.
Separate backup credentials from admin access
The account that writes backups should not be the same account that signs in to the authentik admin interface or the one that can change flows and providers. Give the backup job its own database role with only the rights a dump needs, and its own storage credentials for the bucket or archive location. If the authentik admin path is compromised, the attacker should not also gain the ability to erase or read the backups.
Protect the restore environment
A restored copy of the directory is a working identity provider. If it comes up on a network that users or applications can reach, it can issue sign-ins and tokens again, including for accounts that were disabled after the backup was taken. Restore into an isolated network first, confirm which signing keys and redirect URIs are active, and only then point DNS or the reverse proxy at it.
Set retention and deletion rules
Older backups keep credentials for users who have since left, and keep keys that may have been rotated. Decide with your security and records owners how long each backup type is kept, and document the deletion process so expired copies are removed from object storage, replicas and offsite locations. Ask whether any retention obligation applies to identity records in your sector, since that can set a minimum as well as a maximum.
Log backup and restore actions
Record who started each backup, where it was written, who accessed it and every restore, including the restore target and time. These entries belong in the same review trail as authentik audit events, so a copy taken outside normal schedules is visible. Forward them to your log platform and alert when a restore starts outside a change window. A restore that nobody logged is hard to explain during an investigation.
Confirm secret key and certificate handling
Restoring a database without the matching secret key or certificates can leave encrypted fields and signing material unusable, while restoring them to the wrong place can expose them. Before go-live, confirm with your security team where the secret key lives, whether it is stored with the backup or in a separate secrets store, who may read it, and how it is rotated after a suspected exposure. Record the answer in the runbook so restore does not depend on one engineer's memory.
Questions teams ask before backing up authentik
Is pg_dump alone enough to back up authentik?
No. A PostgreSQL dump holds users, policies, flows and configuration, but it does not hold everything authentik may need to start and run. Back up /data unless you use S3 storage, /certs if your certificates are not already imported elsewhere, and /custom-templates. Include /blueprints if you keep it as a working copy. Also back up the S3 buckets if you use them for uploaded files. Restore the database before restarting authentik. The authoritative list is in the authentik backup and restore documentation, and your team should confirm it against the exact version it runs.
How often should authentik be backed up, and what sets the interval?
The interval should follow how much change you can afford to lose. Your recovery point objective sets the target: if losing a day of user, policy or flow changes is acceptable, daily backups may suffice, while frequent administrative changes or continuous archiving call for a shorter interval. Consider how often administrators change flows, providers and applications, how many users generate data that lands in PostgreSQL, and how long you keep older copies. Continuous archiving with point-in-time recovery, described in the PostgreSQL continuous archiving documentation, narrows the gap further but adds storage and operational work.
What does a restore test involve, and who should run it?
A restore test rebuilds authentik in a separate environment from the backups alone, then checks that sign-in, a sample application and the admin interface work. It should restore PostgreSQL first, then the static directories, then start authentik, and it should record the time each step takes. Run the test by the team that operates authentik, with a second person reviewing the results. Test at a set cadence and after changes to the database, storage or certificate setup. An untested backup is an assumption, not a recovery plan.
Can our own team set up authentik backups, and what skills does it need?
Many teams can, provided they already run PostgreSQL and the container platform authentik uses. The work needs someone comfortable with pg_dump or continuous archiving, file permissions on the /data and /certs volumes, object storage access controls if S3 is used, and a restore procedure written down in order. Key-management skills matter too, because encrypted backups are only useful if the keys are kept apart from the backups. Assess your team against these skills before deciding whether to build the procedure in-house or bring in a partner.
What would an outside partner scope for authentik backup and restore?
A fixed-scope engagement typically starts with an inventory of where authentik stores data in your environment, including the database host or managed service, volumes, S3 buckets and the deployment method. It then covers the backup method and schedule, storage location and retention, encryption and access, a written restore runbook, and a restore test with documented results. The client usually provides access to the environment, the existing deployment files, the team's recovery objectives, and a named contact who can approve changes. The exact deliverables and timeline are agreed in writing before work starts.
How is the cost of authentik backup and restore shaped?
Costs fall into two groups. One-time work covers the inventory, the design of the backup method, the restore runbook and the first full restore test. Recurring costs cover backup storage, retention, periodic restore tests, and reviews after upgrades or infrastructure changes. Storage cost grows with database size and retention length. Testing cost grows with how often you test and how much of the environment you rebuild. Ask any quote to separate these items, to state who performs each task, and to list the assumptions about storage and retention. DeployOpen does not publish prices, and a quote follows from the written scope.
How do backups relate to high availability and PostgreSQL replication?
Replication and backups solve different problems. A standby server helps you recover from a primary failure, but it copies mistakes too: a bad deletion or a faulty configuration change reaches the standby almost at once. Backups let you return to an earlier point in time. PostgreSQL supports hot standby and synchronous or asynchronous replication, but it does not detect a failed primary by itself, so automatic failover requires external tools. Keep backups off the database host and separate from any replica, and treat replication as availability, not as a backup.
Why restore testing matters more than the backup job
A backup that has never been restored is an unverified assumption, and for authentik that assumption covers far more than user records. The backup job reports success when files and a database dump land somewhere, but it says nothing about whether a restored instance will let anyone sign in. Because PostgreSQL holds all users, policies, flows and configuration, a dump that is complete on paper can still leave you with a broken login path, missing providers or a flow that no longer runs. Treat the restore test as the only evidence that the backup is usable, and schedule it as a recurring task with an owner, not as a one-time check at go-live.
A restore test should prove four things in a clean environment built from your backup set. First, a user can sign in through the restored instance and complete the MFA steps they normally use. Second, flows and providers are intact: open the key authentication and enrollment flows, confirm that each OAuth2/OIDC, SAML or LDAP provider still points at the right applications, and check that blueprints applied as expected. Third, certificates validate, including any copied from /certs and any imported keys, because a restored instance that serves an expired or mismatched certificate fails in front of every application at once. Fourth, outposts reconnect to the restored server, since embedded and remote outposts depend on the server state you just rebuilt.
Record the results in a dated restore report that names the backup set, the authentik version, the PostgreSQL version, the restore steps as actually run, and the pass or fail result for each of the four checks. Note every deviation from the runbook, because those notes become the fixes that make the next restore faster. Ask your provider or internal team to confirm how long the restore takes in your environment and which steps depend on access to S3 storage or external secrets, since those are the first items that fail during a real incident.
How DeployOpen scopes and delivers authentik backup and restore
DeployOpen plans, implements, backs up and documents self-hosted open-source platforms inside your own infrastructure, including authentik. For backup and restore, we start from what your authentik instance actually stores, build the database and file protections around it, and prove the restore order works before handing the runbook to your team.
How we scope
- Inventory where your PostgreSQL data, /data, /certs, /custom-templates and /blueprints actually live in your deployment.
- Agree the database method (pg_dump, pg_dumpall or continuous archiving) and the off-host storage location in writing.
- Confirm whether S3 storage replaces /data and which buckets, retention periods and access controls apply.
How we build
- Configure scheduled PostgreSQL backups or WAL archiving, with credentials and storage kept outside the database host.
- Capture the static directories and S3 bucket settings in the same backup schedule so the set stays consistent.
- Run a test restore into a separate environment, following the documented order of database first, then authentik.
How we hand over
- Deliver a runbook covering backup jobs, restore steps, verification checks and the owner of each step.
- Document how to restore a single component, such as the database, without touching the other protected directories.
- Walk your operators through a restore drill so they can repeat the process without DeployOpen present.
How we support
- Review backup job logs and restore test results on a schedule agreed in the written scope.
- Update the runbook when your authentik version, PostgreSQL major version or storage location changes.
- Ongoing support, upgrades and testing are available as a retainer after the fixed-scope engagement ends.
