Frank
Most of the comparison posts you’ll find on this topic read like feature matrices. Authentik has OIDC. Authelia has less RAM usage. Both support 2FA. Someone in the comments says “just use Keycloak.” Nobody learns anything.
I’m going to take a different angle, because I’ve actually run both – simultaneously, in production, for different purposes – and the thing that took me the longest to understand wasn’t a feature gap. It was that these two tools were built around fundamentally different mental models, and if you bring the wrong one to the table, you’re going to be confused and frustrated in very specific ways that no comparison chart will prepare you for.
Let me explain what I mean.
The Setup: Why I Ended Up Running Both (And Why That’s Actually the Point)
My homelab isn’t a test environment. It’s a working system I depend on daily, and it has two distinct layers that needed different treatment.
The public-facing layer, which includes knuckledustchronicles.com and familytechlab.com, needed real identity management. People logging in from the outside, enrollment flows that don’t require me to manually provision every account, OAuth2 integrations that actually speak the language modern apps expect. That’s Authentik territory.
The internal layer, the services running inside my homelab network behind Caddy, things like HomeBase, internal dashboards, and various Docker containers I’ve accumulated over the years, needed protection without the overhead. I control the clients, I control the network, and I just need a solid gate that keeps unauthorized requests out. That’s where Authelia lives.
So when I say I run both, I’m not describing some indecisive experiment. I’m describing a deliberate architecture that emerged from learning what each tool actually is, as opposed to what I assumed it was when I first deployed it.
The argument I want to make in this post isn’t “here’s which one is better.” It’s something more specific: the moment you realize the tool you picked was engineered for a different mental model than the one you brought to it is the moment this whole comparison starts making sense. Everything before that moment is just noise.
Authelia: Lightweight by Design, Unforgiving by Nature
Authelia is not an identity provider. That’s the single most important thing to understand about it, and it’s the thing that surprises people who deploy it expecting Authentik-lite.
What Authelia actually is, at its core, is a forward auth middleware layer. It sits between your reverse proxy (Caddy, NGINX, Traefik — take your pick) and your backend services, intercepts requests, checks authentication state, applies policy rules, and either passes the request through or serves up a 401. It doesn’t issue tokens in the OAuth2 sense. It doesn’t manage user enrollment flows. It doesn’t have a rich admin UI where you can build out authentication pipelines visually.
What it has is a YAML configuration file that governs essentially everything: access control rules, session policy, notifier settings, identity providers, 2FA methods. The entire behavior of the system lives in that file.
For someone who has spent the better part of 28 years in enterprise IT where policy-as-config is practically a religion, that’s actually a familiar comfort. You can read the whole thing. You can version control it. You can understand exactly what rule is allowing or denying a specific request if you’re willing to trace through the logic carefully.
The tradeoff, though, is real: Authelia rewards infrastructure thinkers who are comfortable living in config files and mentally modeling HTTP request flows. If you make a mistake in an access control rule at 11pm, you’re not getting a helpful error message that says “hey, your bypass rule is too broad.” You’re getting a 401 and you’re going to sit there staring at your config trying to figure out which rule is firing and why.
I’ve been in that exact position, troubleshooting why a particular internal service was challenging auth on every request even when I was already logged in. The answer turned out to be a rule ordering issue — Authelia evaluates rules top-down, first match wins, and I had a deny rule that was catching my session before my bypass rule could. The fix was two lines. Finding those two lines took forty minutes of methodical elimination.
That’s not a knock on Authelia. It’s just the nature of a stateless, config-driven system. When it’s right, it’s fast, clean, and invisible. When it’s wrong, you’re the debugger.
Authentik: The Feature Richness That Will Either Save You or Swallow You
Authentik is actually an identity provider, and that distinction changes everything about how you work with it.
Full OIDC/OAuth2 provider, LDAP outpost capability, SAML support, user enrollment flows with email verification, a real admin UI with a flow debugger, group-based policy, application-level access control, and a UI that lets non-command-line people actually manage the system without touching a config file. For public-facing services where you need genuine identity management, this is the right level of tooling.
The honest cost of that power level is real though, and I want to be direct about it.
Authentik runs a PostgreSQL database, a Redis instance, plus separate worker and server containers. On a homelab with constrained resources, that’s a meaningful chunk of overhead you’re committing to before you’ve protected a single service. It’s not unreasonable overhead for what you’re getting, but it’s not nothing either.
More importantly, Authentik has its own mental model, and it’s different enough from what most IT veterans are used to that it requires conscious adjustment. The core concepts are Flows, Stages, and Providers. A Flow is an ordered sequence of Stages that gets executed when something happens, like a user logging in or enrolling. A Stage is a discrete step in that flow, such as password collection, 2FA prompt, or user enrollment. A Provider is the OIDC/SAML/LDAP endpoint that applications connect to.
Once that model clicks, Authentik starts making a lot of sense. Until it clicks, you’ll be configuring things in one place, expecting results somewhere else, and wondering what you missed.
The failure mode I want to flag specifically: misconfiguring an enrollment flow doesn’t just lock one service. It can produce half-authenticated states where a user has partially completed a flow, exists in some intermediate state in the database, and is now getting confusing errors that don’t clearly explain what happened. Debugging those states requires understanding both the flow definition and what Authentik recorded during execution. The flow debugger helps, but you have to know it’s there and know how to read what it’s telling you.
For my public-facing sites, this level of capability is worth the complexity. For a homelab dashboard that I access from one browser on one machine, it’s significant overkill.
The Configuration Philosophy Gap Nobody Puts in the README
Here’s where I want to slow down, because this is the thing that actually matters most and I’ve never seen it stated clearly anywhere.
Authelia thinks in rules and policies defined statically in a file. Authentik thinks in flows and stages configured dynamically through a UI. Those aren’t just different implementation choices, they represent fundamentally different philosophies about how authentication logic should be expressed and maintained.
If you come to Authentik with the Authelia mental model, which is to say if you’re looking for a place to write out your access control logic explicitly and completely, you’ll spend a frustrating amount of time trying to find where the “rules” are. The answer is that they’re spread across Flow definitions, Policy bindings, Group memberships, and Application access configurations, all connected through the UI rather than expressed in a single readable file.
Conversely, if you come to Authelia after working in Authentik, you’ll feel like you’ve been handed a powerful engine with no cockpit. All those things you could click through in the UI now have to live in your head as YAML structure.
As someone with nearly three decades of enterprise IT experience, the config-file model is native to me. That’s how Exchange policies work, that’s how GPO logic works, that’s the environment I grew up in professionally. Authentik required a real gear shift — not because it’s harder, but because it’s organized differently, and I had to stop looking for the thing I was used to and start learning to see the thing that was actually there.
The clearest example I can give is MFA enforcement. In Authelia, it’s a few lines in your access control rules: set the policy to two_factor for the resources that require it. Either it works or it doesn’t, and if it doesn’t, you re-read those lines until you find the problem.
In Authentik, enforcing MFA means working with your Authentication Flow, finding or creating the appropriate MFA Stage (probably a TOTP validation stage), binding it to the flow in the right position, and then running it through the flow debugger to make sure the execution order is what you expect. More powerful. More visual. More steps. And more ways to get it subtly wrong in a way that only shows up in specific edge cases.
Neither approach is superior in the abstract. But each one is clearly better suited to certain operators and certain use cases.
When Each One Is Actually the Right Tool, Stated Plainly
I’m going to skip the usual forum hedging here and just say it directly.
Use Authelia when:
-
- You’re protecting internal homelab services where you control the clients and the network
-
- Your reverse proxy is already doing the heavy lifting (Caddy handles this beautifully)
-
- You want minimal resource overhead and maximum config transparency
-
- You’re comfortable in YAML and you prefer your system’s logic to be readable in a single file
-
- You don’t need OAuth2/OIDC token issuance ,you just need a gate
Use Authentik when:
-
- You’re running public-facing services that need real identity management
-
- You need OAuth2/OIDC integration with apps that expect a proper IdP
-
- You want user self-service enrollment and group-based access management
-
- You need LDAP or SAML support for integration with other systems
-
- You’re protecting something where the UX of the login experience actually matters to end users who aren’t you
The “just use Authentik for everything” advice you’ll see on Reddit and in homelab Discord servers is technically fine advice if your homelab runs on beefy hardware and you enjoy maintaining a heavier stack. But on a system like mine, where Caddy is already doing efficient reverse proxying across a bunch of internal services, running a full Authentik stack for every internal service would be like using a crane to hang a picture frame. The capability is there. The situation doesn’t justify it.
Keep your tooling proportional to your actual requirements. That’s not laziness, that’s good engineering.
The Maintenance Reality Six Months In: What the Getting-Started Guides Skip
Here’s what nobody covers in the “how to deploy Authentik/Authelia” tutorials: what it’s actually like to live with these tools after the initial setup high wears off.
With Authelia, the main ongoing hazard is config drift. Every time you add a new service to your homelab, you have to remember to add the appropriate policy rule. If you forget, the service will either be wide open or completely blocked depending on your default policy, and you might not notice immediately. The config file is the single source of truth, which means the config file has to stay current with your infrastructure or it will lie to you. I keep notes in Trilium for every service I add, specifically so I have a record of what rules I added and why. That discipline pays off when you’re staring at an unexpected 401 three months later.
With Authentik, the challenge is different. Authentik’s update cadence is active, and occasionally a significant release will include changes to how Flows and Stages work internally that can affect existing configurations in subtle ways. It’s not reckless, the project generally documents breaking changes but you have to actually read the changelog before you update, not after. I store credentials and service documentation in Passbolt precisely because I’ve learned not to trust my memory when it comes to what I configured, when, and why.
The uncomfortable truth that ties all of this together: neither Authelia nor Authentik is a fire-and-forget solution. Authelia demands ongoing config discipline. Authentik demands ongoing update awareness and flow maintenance. If you treat SSO setup as a one-time project that’s done the day it starts working, you will eventually have a bad day.
What separates homelab operators who maintain functional, trustworthy infrastructure from those who are constantly firefighting isn’t which tools they picked. It’s whether they built operational habits around those tools. Document your flows. Version control your configs. Know what changed before something breaks.
The tool you can maintain reliably is always the right tool, regardless of what the feature matrix says.
