Everything private behind my servers asks the same question first: who are you? For a long time Authelia answered it. In October 2026 I started replacing it with authentik, and the interesting part isn’t the choice of product. It’s doing the replacement so that nothing is re-pointed twice, every step can be undone on its own, and the identity configuration ends up in git.
Why now
Authelia had been fine as a sign-in page. What it lacked was the management side: creating a user, inviting one, letting someone recover their own account. Every account change was an edit to a file on a server.
A few weeks earlier I had looked at authentik and concluded: not now. That assessment named the one thing that would change the answer, which was account management becoming the problem. When it did, the plan superseded the earlier verdict on its own trigger, rather than being argued around it. I like plans that say in advance what would overturn them.
Run both, side by side
The rule for the migration is that Authelia keeps running until authentik has taken over everywhere Authelia was used. The new service runs on its own machine, id, under a new hostname. The old hostname is never re-pointed; it retires with Authelia. That way no consumer is moved twice, once to a shared name and once more to the final one.
The order is lowest stakes first. A lower-stakes app went first, then the household budget, then the file-sync server, then the login methods on the edge, then the reverse proxy at home, then the public sites’ admin logins. Each move is its own phase with its own plan, and the plans are written one or two ahead, never all at once, so that what one phase teaches reaches the next.
Identity in git
The part I wanted most was this: the identity configuration lives in the repository as blueprints that authentik applies at start. The groups, the accounts without their passwords, the brand, and every application and its provider are declared in files. Client secrets are pulled from the environment, so no secret value is in the repository.
Before, the identity configuration existed only on one machine and in its nightly backup. Now a change to who may reach what is a commit, with a diff and a history, the same as every other part of the infrastructure.
The first apply taught two lessons, both about the tool rather than the design. A reference from one blueprint file to an object in another doesn’t resolve the way a same-file reference does, so cross-file references needed a lookup by name instead. And when an apply fails, the error isn’t on the blueprint object you’d look at first; it’s in the logs of the apply task. Both are written next to the files now.
Phases, gates and rollbacks
Every phase has its own rollback, and most of them are one thing flipped back: an environment value, a compose change, a provider setting, a login method re-added. Nothing is deleted until the final phase, and that phase’s own rollback is restoring the old machine from its last mirror.
Gates are readings, not dates. The gate out of the enrolment phase is that every account that holds a second factor on the old service has one on the new one, read from the admin interface and recorded. A second factor is required of every account at first login, a passkey or an authenticator app, and sessions last four weeks. The final phase is gated on the old service’s logs showing no successful login across a stated span of normal household use, which is a reading too, not a clock.
As of the plan’s status on 10 October 2026, the new service was running with its blueprints applied, enrolment was under way, the household budget had moved, and authentik was one of the login methods on the edge beside the old one. The post on Access describes where those login methods sit.
What it costs, and what it does not buy
This is the paragraph I’d want a reader to weigh. One remote identity provider still means that when the internet or that machine is down, the private services at home fail closed, exactly as before. authentik is heavier than what it replaces, a server and a worker and a database, and it has to be upgraded one major version at a time. And none of the incidents on my record would have been prevented by it.
What it buys is an admin interface, invitations, self-service recovery, an event log, per-application bindings, and identity configuration in git. For a household, the first three are the whole reason. The last one is the one I’d have done it for alone.
Both sign-in services are watched from outside the house, and their rows are on the public status page. When the old row goes away, the migration is done.