✅ Deploy Preview for authentik-docs ready!

Name	Link
🔨 Latest commit	609f7e7
🔍 Latest deploy log	https://app.netlify.com/sites/authentik-docs/deploys/67cb5e29eac2b0000869c323
😎 Deploy Preview	https://deploy-preview-12943--authentik-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

✅ Deploy Preview for authentik-storybook canceled.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.70%. Comparing base (a07ce35) to head (609f7e7).
Report is 23 commits behind head on main.

@@            Coverage Diff             @@
##             main   #12943      +/-   ##
==========================================
+ Coverage   92.68%   92.70%   +0.02%     
==========================================
  Files         793      793              
  Lines       40347    40364      +17     
==========================================
+ Hits        37395    37421      +26     
+ Misses       2952     2943       -9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Depends on #12962 for the Docker container names.

Depends on #12962 for the Docker container names.

You don't need to, we assume in the documentation that a bunch of commands are run from the docker-compose directory.

One thing I forgot to mention, I don't want us to provide specific instructions for backing things up, but instead provide references to our dependencies respective documentation.

One thing I forgot to mention, I don't want us to provide specific instructions for backing things up, but instead provide references to our dependencies respective documentation.

For example, linking the Postgres backup page instead of providing a command? I'm curious, is there any specific reasoning behind this? While this might simplify things for us, it could ultimately create more challenges for the user, particularly those who aren’t as familiar with Postgres or Redis. There’s a risk they could end up relying on commands from unreliable third-party documentation or their own improvised solutions, which could lead to data loss or improper backups due to incorrect usage or poor practices. Wouldn’t it be safer and more effective to direct them to the official dependency documentation and provide commands?

This is a bit like one of my first PRs to authentik: upgrading PG from v12 to 16. We could have linked pg_restore/pg_dump/pg_whateverelse docs but instead we provided a step-by-step with postgres commands.

For example, linking the Postgres backup page instead of providing a command?

Exactly

I'm curious, is there any specific reasoning behind this?

There is.

First, there is the added maintenance for us. Providing specific instructions would mean that we have to maintain those, possibly for multiple versions of postgres (for instance the helm chart and the docker-compose ones don't currently match). It also means that we would need to provide some level of support for issues and questions coming in. We currently don't have that kind of bandwidth.

Backing things up (whether it's postgres, redis, files, or whatever else) is never easy and straightforward. Providing commands would make it look like it is, but it isn't. There are many other things to consider, like the fact that we also need to backup users and their password so that on restore.

While on the topic of restoration, we would also need to provide additional instructions for that.

We also need to consider that using the provided postgres/redis setup with the docker-compose and helm chart is not the way everyone runs authentik.

I would much rather have explanations of what needs to be backed up, why it needs to be backed up, and solid pointers to resources explaining how to do it, instead of us trying to "make things up" even though it isn't our expertise.

There’s a risk they could end up relying on commands from unreliable third-party documentation or their own improvised solutions

Not our problem. Seriously. I know it sounds harsh, but if anyone is running an application (authentik or else) and rely on that data without having 1. learned how to do backups and 2. proper setup and testing of said backups, they shouldn't be running that application.

Which is why I want us to point people in the right direction, with links to references of the upstream backup documentation for example.

sorry for taking a while to get to this. I've implemented your suggestions in e3292ee . Hope I wasn't too specific or vague on certain points. Restoration docs is also added in b92ab8d

If you choose to keep "Restore Notes" (under "Static directories"), wording will probably have to be updated. I'm not proud of my descriptions.

was out sick some time this week, I'll get to this next week

Comme toujours, c'est un plaisir! @tanberry

Does losing the Redis data mean that pending emails are lost? For invite email that might be considered permanent data loss

Does losing the Redis data mean that pending emails are lost? For invite email that might be considered permanent data loss

That's correct. We're working on solutions to avoid those issues

Does losing the Redis data mean that pending emails are lost? For invite email that might be considered permanent data loss

That's correct. We're working on solutions to avoid those issues

Depending on far away these solutions are it would be best to correct the documentation to state that losing redis does mean losing irrecoverable state