Authelia vs Pomerium

Authelia vs Pomerium by scenario

This table maps common team situations to the better fit between Authelia and Pomerium and states the condition that decides it. Read each row against your own identity sources, protocols and network rules, since the answer usually turns on where users already log in.

How Authelia and Pomerium are built and deployed

Authelia and Pomerium both sit in front of your applications, but they divide the work differently. The cards below cover where each component runs, what state it keeps, and where application traffic and identity checks actually flow.

Capability comparison: Authelia and Pomerium

This table compares licensing, protocols, identity sources, proxy support, second factors, policy, remote access and audit features for Authelia and Pomerium. Where the researched facts do not confirm a capability, the cell tells you what to verify with the vendor. Use it to shortlist, then test the rows that matter most for your applications.

What is free and what is paid in each platform

What drives the running cost of each gateway

Moving from Authelia to Pomerium, or back

This sequence takes a team from Authelia's built-in login and second factors to Pomerium's external identity provider model, or the reverse, one route at a time. The output is a documented inventory, a policy map, a verified identity provider, and a cutover record with a rollback path for every protected app.

1. Inventory protected apps and routes

   The platform owner lists every application behind the current gateway, including its hostname, upstream service, path rules, and which teams depend on it. Include apps that bypass the proxy for API or machine traffic, since those need a separate decision. The inventory is complete when each route has an owner, a named business user group, and a note on whether it is user-facing or service-to-service. Confirm the route count against the live Authelia and proxy configuration, not against memory.

2. Map Authelia rules to Pomerium policies

   The security engineer translates each Authelia access rule, which matches on domain, path, subject, and authentication level, into a Pomerium route policy. Pomerium policies are evaluated against identity attributes supplied by the external provider, so group and claim names must be decided before any rule is written. Flag every rule that depends on a second factor level, because that requirement has to be restated in the new model. The map is done when each old rule has a matching new policy or a documented reason it was dropped.

3. Select and connect the external identity provider

   Pomerium relies on an external provider for user identity, and the supported list in its identity provider documentation includes Keycloak, Microsoft Entra ID, Okta, Google, and others. The identity team chooses the provider that already holds the user directory, then registers Pomerium as a client and confirms that the expected claims and groups arrive. Authelia can authenticate against LDAP or a file, so a team moving from a file backend must first decide where users will live. Done means a test user signs in through the new provider and the group claims match the policy map.

4. Rebuild second factor enrollment at the provider

   Authelia stores second factor registrations for one-time passwords, security keys, passkeys, and Duo push in its own storage, and those registrations do not move to Pomerium. Where the identity provider handles MFA, users enroll again in the provider's own factor tools, and the team confirms which assurance level each route requires. Helpdesk staff need a documented reset procedure before users are asked to re-enroll. Ask the provider vendor which factors it supports and how step-up is configured, since this varies by product. The step closes when a pilot group has enrolled and passed a test on a protected route.

5. Move users and group membership

   User identities already in an LDAP directory or in a directory service remain there and transfer by design, so the work is to confirm that group membership is correct and that the provider reads it. Accounts that exist only in Authelia's YAML file must be recreated in the chosen provider with their passwords reset, because stored password hashes are not a migration path into a different identity system. Record the count of accounts moved and the groups mapped. The step is complete when a reconciliation report shows each active user present in the provider with the expected groups.

6. Cut over route by route with rollback

   The team moves one route or a small group of routes to Pomerium at a time while Authelia continues to protect the rest. Each cutover keeps the previous proxy configuration in version control so the route can be returned to Authelia quickly. Monitoring checks login success, denied requests, and upstream health for each moved route before the next one starts. Because both gateways can coexist during the transition, rollback is a configuration change, not a rebuild. The step is done when every route has been moved, tested, and signed off by its application owner.

7. Retire the old session and storage layer

   Once every route is on the new gateway, the team stops Authelia, removes its routes from the reverse proxy, and disposes of its session data and storage. Authentication logs in PostgreSQL, MySQL, or SQLite may hold records that the audit or retention policy requires, so export or archive them first and record where they are kept. Revoke any Authelia client credentials and secrets that are no longer needed. The sequence closes when the old service is stopped, the archive is verified, and the configuration repository shows no remaining references to Authelia.

Where Authelia and Pomerium projects usually run long

Authelia vs Pomerium: questions buyers ask before choosing