multi-site Authentik deployment

[cu]

Hello,

I'm aware that there have been discussion threads that touched on this in the past, and I understand that a scenario like this might not be officially supported, but I have read that it is possible. However, I haven't come across any threads or docs that give any particular general direction to go in.

I do a lot of self-hosting of various things and Authentik looks like a very nice solution these days. I have just a handful of users (family) so performance and scaling are not a huge concern. However, I have two main "sites" that I deploy to: my network at home and a VPS (or two) in the cloud. My goals are:

1. Deploy an instance of Authentik to each site.
2. Synchronize all data between them.
3. Bringing down one site does not negatively impact the other.
4. Can add users or allow users to change passwords at either site.

The last one, I could give up if it would simplify things somehow.

I have read that these days Authentik keeps all of its state in PostgreSQL. And that one way to achieve the above is to configure the PG instances into a high-availability setup. I've been trying to educate myself on PG HA and replication but there seem to be many options here and they all depend on what the goals are and what the application can do. Some of the options are built into PG and others require a third-party extension.

So far, I've done some investigation into Logical Replication. This method has the drawback that it only replicates changes to row data, everything else (column definitions, views, triggers, indexes, etc) must be handled manually somehow. I could use this if there was some kind of guarantee that Authentik only ever modifies row data during normal use, but I don't know if that's the case.

I could set up one site as a normal read/write database and ship the logs off to a read replica on the other site. But modern authentication schemes seem to require all manner of sessions, cookies, and tokens, so I don't think an Authentik instance can even function on a read-only database. Please correct me if I'm wrong.

I have looked briefly into both synchronous and asynchronous multi-master replication but they look like they might require some third-party extensions. Which I am not especially opposed to, I'm just wary of adding unneeded complexity relative to my seemingly simple use case.

Has anyone had any success with what I am trying to achieve? Is there direction you could point me to that is likely worth pursuing? What are Authentik's capabilities and limitations regarding various PG replication types?

Appreciate any guidance.

[rissson]

I don't think an Authentik instance can even function on a read-only database

That is correct, mostly because, as you said, we need to store user sessions, but also append to the event log for audit purposes.

The usual setup we see is this:

Site 1: authentik + postgres primary. authentik is configured with 1 database, the primary one
Site 2 (or more): authentik + postgres replica. authentik is configured with 2 databases: the site 1 one as the main one, and the local site one as a read replica

Upon failover to another site (which is a manual operation, but can probably be automated), mark the site 2 db as the primary one, and update the authentik configuration to use the new primary as the main one.

Note that when automating the failover, in case of a split-brain scenario, you may end up with diverging databases, which is something that needs to be handled, i.e. there should only be one postgres primary at all times.

cc. @dewi-tik as you're working on the HA docs

[cu]

@rissson Thanks for the info.

Reading my own question, it looks like I wasn't thinking very clearly about my own requirements... HA isn't exactly what I'm looking for. Rather, I'm hoping to have two separate instances of Authentik that just happen to share the same set of users, groups, and passwords through some kind of replication or syncing mechanism.

(I acknowledge that it's probably an unusual request!)

[rissson]

Yes, which is why I recommended replicating at the database level.