The same question

I migrate my authentik docker installation to standalone linux installation

and I want to export/import de configuration authentik from docker to standalone

thank's

Hi, i have the same question. I want to setup a Test System out of the Prod system :D

Just rsync your mapped docker volumes to your new server/new location and start a new docker container...

Same question. Dumping PostgreSQL and restoring it on another instance would be enough?

Same question. Dumping PostgreSQL and restoring it on another instance would be enough?

Should be. I moved the Authentik postgres to a central Postgres instance and dumped the old DB and re-imported the DB to the new instance and everything still worked.

We've wanted to make a documentation section about this for some time now. I'll just dump some ideas here until we write one:

Things that absolutely need to be backed up:

• PostgreSQL. There are plenty of resources on how to do so. A good starting point is the official documentation https://www.postgresql.org/docs/current/backup.html.
• The /media mountpoint, if you have it. Since 2024.2, that is also valid of the configured S3 bucket.

Optional but very much recommended because of potential inconveniences:

• The redis DB. With the default Docker image, Redis data will get dumped to disk under /data every 60 seconds if there was a write made to Redis since the last dump. This should be backed up. If that data is lost, the following will be lost: user sessions (users will have to log back in), latest reputation scores (which are saved in the database every hour IIRC). If that data is lost, the following may be lost: current waiting tasks, which may be relevant to keep (such as emails to send, etc.), or irrelevant, such as outpost ensurer tasks, as they'll get re-scheduled on their own. All in all, if you lose this data, it doesn't mean that your authentik instance will stop working forever, just that there may be some annoyances for your users.

Optional:

• the /certs, /templates and /blueprints mountpoints. Usually, files in there will be somehow provisioned by the operator, and can be restored in another way. For /certs and /blueprints, they'll be saved in the database once discovered anyway, so it's not really required

I plan to move my Authentik instance to a new server recently, will keep an eye on the doc, and probably give it a try first if I cannot wait that long...

Things that absolutely need to be backed up:

• ...
• The /media mountpoint, if you have it. Since 2024.2, that is also valid of the configured S3 bucket.

How relevant is the /media mountpoint? It seems to be only images which should not prevent authentik from working if they are missing. Sure, the users will see the missing image symbol and stuff might look ugly/unbranded but core functionality should not be impacted or am I missing something?

How relevant is the /media mountpoint? It seems to be only images which should not prevent authentik from working if they are missing. Sure, the users will see the missing image symbol and stuff might look ugly/unbranded but core functionality should not be impacted or am I missing something?

Yeah that's basically what will happen, some stuff in the UI will look ugly, and you'll have to re-upload the icons, but that's basically it. However, if you are storing extra data in there (such as with the prompt stage and a file field type), that will be lost also, but I doubt a lot of people are doing this.

Hi folks, attempting to restore Authentik to a new docker LXC. I was able to create an sql dump file, but can someone explain how to restore it for a novice/lay person? When I tried using:

sudo docker exec -i authentik-postgres psql -U authentik authentik < /${DOCKERDIR}/appdata/authentik/backup.sql

but it gave me multiple errors that each item 'already exists'.

update: I was able to fix by dropping the existing database first, using:

sudo docker exec -i authentik-postgres psql -U authentik -c "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'authentik' AND pid <> pg_backend_pid();" && \
sudo docker exec -i authentik-postgres psql -U authentik -d postgres -c "DROP DATABASE IF EXISTS authentik;" && \
sudo docker exec -i authentik-postgres psql -U authentik -d postgres -c "CREATE DATABASE authentik;" && \
sudo docker exec -i authentik-postgres psql -U authentik -d authentik < /${DOCKERDIR}/appdata/authentik/backup.sql

If anyone else is reading, you'll have to replace ${DOCKERDIR} with your own, e.g., /home/user/...

I understand the sentiment of not wanting to invest in backups, but I think the thing that was overlooked here is that even with a backup you need a way to restore and while there's various ways to do it, a built in way straight from the web interface would be the cleanest solution and provide a framework to ensure that backups and restores are done properly.

...a built in way straight from the web interface would be the cleanest solution and provide a framework to ensure that backups and restores are done properly.

As someone who is not in the Authentik team: Oh hell no. Authentik itself is basically stateless. It should not have to concern itself with the backup/restore of systems (SQL DB, filesystem) for which backups and restores have been a solved problem for decades.

This is just unnecessarily complicated and brings many problems with it. This goes also against any established practices in large teams/companies. Restoring a SQL db and a simple directory is so much easier and more convenient than a web based solution likely will be. You would need some kind of container format (e.g. .tar.gz) which contains all the files plus the SQL database. Then you have to unpack it and put it in the correct location. For the DB backup it might be that Authentik itself does not have enough privileges to restore everything directly. And you would have to generate this file somehow - which is another useless step in making this more complicated.

This is not even touching the problems of uploading large backup files. This means that the whole database with confidential user data would need to be on some developers machine. Uploading a large file would also require Authentik or the reverse proxy in front of it to accept huge body payloads which makes it way easier to DoS it.

I am, however, all in favor of more/proper documentation of the process!

...a built in way straight from the web interface would be the cleanest solution and provide a framework to ensure that backups and restores are done properly.

As someone who is not in the Authentik team: Oh hell no. Authentik itself is basically stateless. It should not have to concern itself with the backup/restore of systems (SQL DB, filesystem) for which backups and restores have been a solved problem for decades.

This is just unnecessarily complicated and brings many problems with it. This goes also against any established practices in large teams/companies. Restoring a SQL db and a simple directory is so much easier and more convenient than a web based solution likely will be. You would need some kind of container format (e.g. .tar.gz) which contains all the files plus the SQL database. Then you have to unpack it and put it in the correct location. For the DB backup it might be that Authentik itself does not have enough privileges to restore everything directly. And you would have to generate this file somehow - which is another useless step in making this more complicated.

This is not even touching the problems of uploading large backup files. This means that the whole database with confidential user data would need to be on some developers machine. Uploading a large file would also require Authentik or the reverse proxy in front of it to accept huge body payloads which makes it way easier to DoS it.

...a built in way straight from the web interface would be the cleanest solution and provide a framework to ensure that backups and restores are done properly.

As someone who is not in the Authentik team: Oh hell no. Authentik itself is basically stateless. It should not have to concern itself with the backup/restore of systems (SQL DB, filesystem) for which backups and restores have been a solved problem for decades.

This is just unnecessarily complicated and brings many problems with it. This goes also against any established practices in large teams/companies. Restoring a SQL db and a simple directory is so much easier and more convenient than a web based solution likely will be. You would need some kind of container format (e.g. .tar.gz) which contains all the files plus the SQL database. Then you have to unpack it and put it in the correct location. For the DB backup it might be that Authentik itself does not have enough privileges to restore everything directly. And you would have to generate this file somehow - which is another useless step in making this more complicated.

This is not even touching the problems of uploading large backup files. This means that the whole database with confidential user data would need to be on some developers machine. Uploading a large file would also require Authentik or the reverse proxy in front of it to accept huge body payloads which makes it way easier to DoS it.

Not disagreeing with you, but having a built in method in no way inhibits you from doing it manually. It’s does make it easier for smaller home lab users to migrate things between boxes without being concerned about whether they need to move just the db, directories, etc.

Not disagreeing with you, but having a built in method in no way inhibits you from doing it manually. It’s does make it easier for smaller home lab users to migrate things between boxes without being concerned about whether they need to move just the db, directories, etc.

I fully agree with this comment, thank you.

An in-built or even guided backup/restore process does not eliminate the option for advanced or commercial users to do so manually according to their own best-practices, but it does add an option for users who may have never backed up or restored a database manually in their own home (or even knew they would have to do so).

Not disagreeing with you, but having a built in method in no way inhibits you from doing it manually. It’s does make it easier for smaller home lab users to migrate things between boxes without being concerned about whether they need to move just the db, directories, etc.

That is certainly true (and sorry if I sounded rude, I just have strong opinions about some stuff which I likely voice louder than necessary). My argument is mostly that sich a feature be needlessly complex and would take an unjustified amount of development time.
The team does not have an unlimited workforce and I would rather see time spend towards fixing some thing or adding features which enable new capabilities - it's not like they are lacking work to get done (sadly also several broken things among those).
So for the near term I would be more than happy with a good documentation of the steps necessary to create a backup and the restoration thereof.

I agree that we definitely need to document what needs to be backed-up (as I listed in #8411 (comment)), with pointers to the documentation of our dependencies on how they recommend the data should be backed up.

However, we won't be including a backup/restore feature in authentik directly. I know many software that are aimed at homelab users do so, but many also do not. The first thing you should do when using new software, especially one that uses a database, is figure out how to backup things. For a database system like postgres or mysql (and variants), those are transferable skills that will come in handy for all things that you run. On top of that, this is definitely feature creep, and something we don't want. By "we" I mean the authentik team, and the user, because then we cannot concentrate on other features, improvements and bug fixes.

Now, backing up postgresql isn't that hard. On my homelab, I run su - postgres -c pg_dumpall --clean --file /var/lib/postgresql/backup.sql --verbose --exclude-database=postgres --exclude-database=template0 --exclude-database=template1 every day, and then back up /var/lib/postgresql/backup.sql like I would any other file, which is something you should already know how to do.

...a built in way straight from the web interface would be the cleanest solution and provide a framework to ensure that backups and restores are done properly.

As someone who is not in the Authentik team: Oh hell no. Authentik itself is basically stateless. It should not have to concern itself with the backup/restore of systems (SQL DB, filesystem) for which backups and restores have been a solved problem for decades.

This is just unnecessarily complicated and brings many problems with it. This goes also against any established practices in large teams/companies. Restoring a SQL db and a simple directory is so much easier and more convenient than a web based solution likely will be. You would need some kind of container format (e.g. .tar.gz) which contains all the files plus the SQL database. Then you have to unpack it and put it in the correct location. For the DB backup it might be that Authentik itself does not have enough privileges to restore everything directly. And you would have to generate this file somehow - which is another useless step in making this more complicated.

This is not even touching the problems of uploading large backup files. This means that the whole database with confidential user data would need to be on some developers machine. Uploading a large file would also require Authentik or the reverse proxy in front of it to accept huge body payloads which makes it way easier to DoS it.

I mean, for docker it could just output the backup to a /backups directory you set in docker. Then when you need to restore, just look at that directory for the most recent backup. That satisfies pretty much all of your comment. about packing/unpacking and uploading/downloading etc since there is no downloading/uploading or packing/unpacking needed on the user end.

I always like it when the apps I am using are able to create the backup file(s) as those files are more likely to work and include all the little 'gotchas' each specific app has in what does/does not need to be backed up. It just increases confidence in the setup.

To that end, though, wouldn't backing up the existing mountpoints be sufficient for backing up Authentik? Why would you need to concern yourself with backing up postgres separately?

I always like it when the apps I am using are able to create the backup file(s) as those files are more likely to work and include all the little 'gotchas' each specific app has in what does/does not need to be backed up. It just increases confidence in the setup.

Well, you're using postgresql with authentik, and postgres is able to output those backup files and restore from them, and does it very well. Better than we could ever do.

To that end, though, wouldn't backing up the existing mountpoints be sufficient for backing up Authentik? Why would you need to concern yourself with backing up postgres separately?

I'll again link to https://www.postgresql.org/docs/current/backup.html and quoting from https://www.postgresql.org/docs/current/backup-file.html (which essentially is what you are describing, aka backing up the postgres docker mount):

There are two restrictions, however, which make this method impractical, or at least inferior to the pg_dump method:

1. The database server must be shut down in order to get a usable backup. [...]

This is obviously not something we want to recommend.

As stated before, authentik itself is basically stateless. The mount directories are all optional:

• the media directory is a nice to have if you do not want to setup S3 to store icons and flow backgrounds, or if you do not have external URLs to point to for those icons
• the certs directory only contains data provided by the operator, nothing is stored there by authentik
• same with the custom-templates mount
• same with blueprints, which we don't even include in the provided docker-compose.yml

As such, you only need to backup postgresql, redis (see #8411 (comment) for details) and your media mount if you have one. The rest is data that the operator is providing optionally, and thus is their responsibility to decide how to back it up.

@tanberry we need to have documentation for this.

Here are a couple of thoughts on this. Primarily from a UX perspective.

When I originally setup authentik the compose db was Postgres 12, it's now 16. You can't just change a PG container from 12 to 16. So if you are moving from one location with 12 to another with 16, you need to make at least a couple of edits to things like the pg_hba.conf among other things, or you need to use a mechanism like pg_upgrade, which is a bit of a nightmare in a docker situation. This isn't too challenging for most, and you could save yourself some headache ensuring you're using the same version of PG. Backing up isn't the issue here, its migration. Eventually people will need to upgrade. Additionally, depending on the environment various versions of postgres might be in use too. In these situations you are going to deal with migration issues. What I suspect will happen is users will come here and open issues, because they will get a litany of spurious errors. Trying to support 100 different errors, forever, will take significantly more effort than adding this as a feature.

Secondly, if Authentik development wants to use the feature set of a new PG they should at a minimum, explain the specific instructions it expects users to take in documentation. Even if it's a dump command. If it is a dump command, in an effort to standardize it, the command should be issued to authentik who should perform that command as a dump command's flags, and params change between versions. authentik backup /some/dir This could also be as simple as including some script along with authentik.

The ideal mechanism would be an export feature for users, databases, configs, files (images, etc), any anything else needed. And an import feature that would put those items where then need to be in the current infrastructure.

I have just moved my entire docker-authentik installation from one VPS to another.
What I have done:

1. Stop the docker service and authentik-containers on your old server
2. (on old server): rsync -aHhP --numeric-ids --delete /opt/containers/authentik/ root@target-[your new server]:/opt/containers/authentik
3. (on old server) rsync -aHhP --numeric-ids --delete /var/lib/docker/volumes/ root@target-[your new server]:/var/lib/docker/volumes
4. Make sure to adjust any configuration variables to your new server, basically I had to adjust the IP/interface the service binds to
5. cd into your authentik directory and docker compose pull && docker compose up (running without -d to see possible errors during first startup)
6. Adjust your DNS accordingly.

That's all I did, took me around 10 minutes to migrate the entire installation and up until now it's working flawlessly. Be sure to adjust the above to your needs.

If I want to just make second Authentik in another server, I can copy all bind mounted data to another server?
Then just to change to auth2.myste.com in authentik?