Which Authelia user backend fits your team
The file backend suits a small, stable user list managed by one or two administrators, while the LDAP backend suits teams that need central user and group management across several services. Both options authenticate users for the same Authelia login portal, so the decision is about where user accounts live and who maintains them, not about which second factors you can use. Authelia's one-time passwords, security keys, passkeys and Duo push apply either way, and so does self-service password reset as the backend allows.
With a file backend, users and their hashed passwords sit in a YAML file that you edit and reload, which keeps the moving parts few. The cost is that every change, including a password reset or a group membership update, is an administrator task performed on that file, and the file must be kept in step with any other system that needs the same people. If a second application, a wiki or a VPN needs the same accounts, that duplication becomes the signal to look at LDAP. Ask yourself who will make changes at 2 a.m. and whether they can do it without touching the proxy configuration.
An LDAP backend moves account and group administration into a directory such as LLDAP, OpenLDAP, FreeIPA or Active Directory, which other services can also query. Choose the directory first, then confirm the exact connection, bind, filter and group settings in the Authelia first factor documentation, because the attribute names differ between directories. Moving from file to LDAP is possible but needs a plan: create the directory accounts, verify each user can sign in with the same second factors, test password change and reset paths, and keep the file backend available for rollback until the cutover is confirmed.
File and LDAP backends side by side
This table compares where Authelia reads users from, a YAML file of hashed passwords or an LDAP directory, across storage, password reset, groups, scale, administration and migration. Read the LDAP column as a range, because several factors depend on which directory server you choose. Items marked as a confirmation point should be checked against your own environment before you commit.
| Factor | File backend | LDAP backend |
|---|---|---|
| User storage | Users and hashed passwords sit in a YAML file read by Authelia | Users sit in a directory such as LLDAP, OpenLDAP, FreeIPA or Active Directory |
| Password reset | Authelia documents self-service reset; confirm how it works with file users | Depends on the directory; LLDAP supports email-based reset, so confirm the others |
| Group management | Groups are maintained by editing the file; confirm the format in your version | Groups live in the directory's own tools, such as the LLDAP web UI or GraphQL API |
| Scale and tenancy | Suited to small, fixed user sets; confirm your ceiling with the Authelia maintainers | Directories are built for larger user bases; LLDAP has one base DN and no native multi-tenancy |
| Storage requirements | Authelia's own database holds preferences, device registrations and logs | Adds a directory service; LLDAP defaults to SQLite and can use MySQL, MariaDB or PostgreSQL |
| Directory software options | None; no separate directory is required | LLDAP (GPL-3.0), OpenLDAP (OpenLDAP Public License), FreeIPA (GPL-3.0-or-later) or Active Directory |
| Who administers accounts | Whoever has write access to the users file, usually the Authelia operator | Directory administrators, with Authelia authenticating against accounts it does not own |
| Support and migration | No directory to support; confirm the path to LDAP and how second factors carry over | LLDAP offers no commercial support; confirm vendor or community support for your chosen server |
What each backend stores and where it runs
Each option answers a different question: where user accounts live, where Authelia keeps its own state, and who runs the directory. The first two cards cover the file option and Authelia's own storage. The remaining four cover the LDAP sources Authelia can authenticate against.
YAML user file
Authelia can authenticate users from a YAML file that holds usernames and hashed passwords, so no directory service is needed. Every account change is an edit to that file, which makes the file the entire user store. Check who can edit the file and how changes are reviewed, because the file itself does not record who changed what. Before you rely on self-service password reset with this backend, confirm its behavior in Authelia's first factor documentation.
Authelia's own database
Whichever user source you choose, Authelia stores user preferences, second factor device registrations and authentication logs in a SQL database. The supported options are PostgreSQL, MySQL or local SQLite. Plan backups for this database, because losing it can mean users must register their second factors again. Confirm which engine fits your availability and log retention needs with the storage documentation before you deploy.
LLDAP front end
LLDAP is a lightweight LDAP authentication server with a web interface where administrators manage users and groups, and users can reset their own passwords by email. It stores data in SQLite by default and can use MySQL, MariaDB or PostgreSQL instead. Its scope is narrow: all users sit under one base DN, the project offers no commercial support, and its FAQ describes it as volunteer-built software. Confirm that a single base DN and one instance fit your tenancy model.
OpenLDAP directory server
OpenLDAP's slapd is a full LDAPv3 directory server that supports SASL authentication and TLS certificate authentication. Its main MDB backend is built on LMDB. For resilience, slapd offers single-provider replication with multiple consumers and multi-provider replication, which matter where a single point of failure is not acceptable. Schema design, replication topology and access control are your responsibility, so confirm that your team has the LDAP administration skills to run it.
FreeIPA identity platform
FreeIPA bundles a 389 Directory Server LDAP directory, an MIT Kerberos key distribution center for single sign-on and a Dogtag certificate authority. It is packaged for Fedora, Debian, CentOS and Red Hat Enterprise Linux as Identity Management, and Authelia can bind to it over LDAP. Its Kerberos and certificate components add operating scope beyond what Authelia uses. If you also need an Active Directory trust, confirm the requirements in the FreeIPA trust guide first.
Active Directory Domain Services
Active Directory Domain Services is a Windows Server role that stores users, computers and other directory objects. It replicates that data to every domain controller in a domain and provides a schema and global catalog. Authelia can authenticate against Microsoft Active Directory through LDAP, so existing accounts can sign in without a second user store. Check domain controller placement, your Windows Server licensing and who administers the forest before you point Authelia at it.
When to move from a file to an LDAP directory
Move from the YAML file to an LDAP directory when user management stops fitting in one person's head. The file works well while one or two administrators can edit a short list of hashed passwords by hand. The case for LDAP strengthens when several applications need the same accounts, when group membership has to drive access rules rather than per-user entries, or when the organization already runs a directory such as Active Directory or FreeIPA that holds the accounts people expect to log in with. In that last case, the question is usually not whether to move but whether Authelia should bind to the existing directory directly. Confirm with your directory team which group attributes they maintain, and whether Authelia's access rules can key off those groups without a second copy of membership to keep in sync.
If you have no existing directory, LLDAP is the lighter option to evaluate, and its own README points away from using it alone. LLDAP provides a web front end for users and groups and password reset by email, but the README says it is not a full LDAP server and suggests adding components such as Keycloak or Authelia that use LLDAP as the source of truth over LDAP. Its FAQ also says it is not recommended for the infrastructure of a big organization unless you are prepared to audit and maintain the code, and it offers no commercial support. Before deciding, ask who would own patching and incident response for LLDAP, whether the single-maintainer risk is acceptable to your security team, and whether you will need OpenLDAP or FreeIPA instead if the directory must serve more than Authelia.
Plan the move as a data and recovery exercise, not only a configuration change. Users will need to re-register second factors if their device records do not carry across, and you should confirm how Authelia's stored preferences and registrations in PostgreSQL, MySQL or SQLite relate to accounts that now live in the directory. Test password reset and account lockout through the new backend before cutting over, and agree in writing with whichever team operates the directory who can create, disable and remove accounts. Those decisions, more than the choice of LDAP product, determine how much effort the change takes.
Operating each backend day to day
This table compares the routine work each Authelia user backend asks of your team, from changing accounts to patching and recovering data. Read each row against your own staffing, because the file backend moves work into configuration files while LDAP adds a directory service you must run. The main takeaway is that the file backend is simpler to operate but shifts account lifecycle work onto whoever edits the YAML, while LDAP centralizes accounts at the cost of another system to maintain.
| Operating task | YAML file backend | LDAP backend (LLDAP, OpenLDAP, FreeIPA, Active Directory) |
|---|---|---|
| Account onboarding and offboarding | Edited by hand in the users file; removing an entry revokes sign-in only after Authelia reloads its configuration | Created in the directory or a web UI; offboarding happens in one place that Authelia reads, so the same change applies to every application behind it |
| Password reset | Users cannot change passwords through the LDAP path; self-service reset depends on Authelia's own reset feature and the file being updated | Reset is handled by the directory (LLDAP sends reset emails; FreeIPA and Active Directory have their own password policy and self-service tools); confirm which of these your setup enables |
| Group management | Groups are maintained as attributes in the same file, so every change is a file edit reviewed like any other config change | Groups live in the directory and are managed by directory administrators, which suits organizations that already manage groups centrally |
| Upgrades | Upgrade the Authelia binary or container; the user data sits in the file and is versioned with your configuration | Upgrade Authelia and also the directory: LLDAP v0.6.3 (April 30, 2026), OpenLDAP 2.7.1 or 2.6.15, FreeIPA and Active Directory on their own lifecycles; confirm each vendor's upgrade procedure before scheduling |
| Backups and recovery | Back up the users file, the configuration and the storage database used for device registrations and logs | Back up the directory database and the Authelia storage database; LLDAP defaults to SQLite, while OpenLDAP and FreeIPA have their own backup tooling; confirm restore tests with each vendor |
| Monitoring | Little to monitor beyond Authelia itself and its storage connection | Monitor the directory service, its replication health and certificate expiry, plus the LDAP bind path that Authelia depends on |
| Replication and availability | No directory replication; availability depends on the single host running Authelia and its file | OpenLDAP supports single-provider multiple-consumer and multi-provider replication; LLDAP has no documented replication, so plan a single instance and confirm with the project |
| Support model | Your team owns the configuration; no separate vendor for the user store | LLDAP offers no commercial support and is volunteer-maintained with a bus factor of one, per its FAQ; OpenLDAP is volunteer-developed; FreeIPA and Active Directory have their own vendor support paths |
| Skills the team needs | Comfort with YAML, hashed password generation and Authelia configuration | LDAP schema, bind accounts, TLS for the directory connection and directory administration; FreeIPA and Active Directory add Kerberos or Windows administration skills |
Choosing the backend by team situation
A single administrator protecting a handful of self-hosted apps usually has a small, stable user list and no directory to integrate with. The YAML file backend fits this case because Authelia authenticates against a file of users with hashed passwords, so there is no directory server to install, patch or back up separately. Changes are made by editing the file and restarting or reloading the configuration, which is manageable when only a few people change access.
- Scale: the file backend suits a short user list that one person can review by hand. Ask yourself whether anyone else needs to add or remove accounts.
- Password reset: Authelia offers self-service password reset, but confirm how it behaves with file-based users in your version before you rely on it.
- Group management: groups are written directly in the user file, so access rules are only as current as the last edit. Keep a copy of the file under version control.
- Storage: user preferences, second factor registrations and authentication logs go to PostgreSQL, MySQL or SQLite, so the file backend does not remove the need for a database.
- Growth: plan the move to LDAP before the user list becomes hard to review or shared by several administrators.
Before you start, confirm how your Authelia version handles group and attribute changes from the file, and test a password reset end to end.
A team that already runs Active Directory or FreeIPA should normally point Authelia at that directory rather than maintain a second copy of users. Authelia supports LDAP directories such as FreeIPA and Microsoft Active Directory, so the identity lifecycle stays where the organization already manages joiners, leavers and group membership. FreeIPA is also packaged in Fedora, Debian, CentOS and Red Hat Enterprise Linux as Identity Management, which matters when the estate is Linux-based.
- Scale: directory-backed users scale with the existing estate, and the directory team already runs replication and backup for it.
- Password reset: check whether password changes and resets are handled in the directory itself or through Authelia, and whether the directory's password policy applies.
- Group management: access rules should map to existing groups. Confirm the group attribute and filter Authelia uses against your schema, because nested groups and custom attributes differ between AD and FreeIPA.
- Storage: Authelia still stores preferences, second factor registrations and logs in its own database, so budget for that database alongside the directory.
- Ownership: agree who may change Authelia's LDAP filters, since a filter change can alter who gets access.
Before you connect, ask the directory team for a read-only bind account and test group membership with a sample of real accounts in a staging setup.
A team that wants central user management without operating a full directory server may consider LLDAP. Its README describes it as a lightweight authentication server with an opinionated LDAP interface and a web front end where administrators manage users and groups. The README also says it is not a full LDAP server and suggests OpenLDAP for that need, so it fits a narrower purpose than AD or FreeIPA.
- Scale: LLDAP's FAQ says it runs in under 10 MB of RAM including the database, and it does not natively support virtual hosts or multi-tenancy, so all users sit under one base DN.
- Password reset: users can reset their password by email through the web front end, so confirm the mail settings work in your environment before go-live.
- Group management: administrators manage groups in the web UI, and LLDAP can be scripted through its GraphQL API. Verify how custom attributes map to the attributes Authelia expects.
- Storage: LLDAP uses SQLite by default and can use MySQL, MariaDB or PostgreSQL, with documented migration away from SQLite. Choose the database before you have many users.
- Support: LLDAP offers no commercial support, and its FAQ says it is not recommended for a large organization unless you can audit and maintain the code.
Before you commit, confirm the current LLDAP release and your support expectations, and test group and attribute handling against your own setup.
Moving users from a file to LDAP without a lockout
This sequence moves Authelia's users from a YAML file to a directory in an order that keeps a working fallback, so you can prove each account and each second factor survives the switch before the file is retired.
Confirm the target directory and its database
Confirm which directory will hold users (LLDAP, OpenLDAP, FreeIPA or Active Directory) and where that directory keeps its own data. For LLDAP, check whether it runs on its default SQLite store or on MySQL, MariaDB or PostgreSQL, since the LLDAP README documents a migration away from SQLite. Record the base DN, bind account and TLS settings Authelia will use. Done when the directory is reachable from the Authelia host with a bind test from that host and the backup plan for the directory is written down.
Load users and groups into the directory
Create every user from the YAML file in the target directory, keeping the same usernames, email addresses and group memberships that Authelia's access control rules reference. Set temporary passwords or use the directory's own reset flow, and do not copy password hashes across formats unless you have confirmed the directory accepts them. Done when a count of accounts and groups in the directory matches the YAML file and each group name used in the access control rules exists in the directory.
Validate Authelia against a test account
Point a staging or second Authelia instance at the directory and sign in with a test account that belongs to each access control group. Confirm the login succeeds, the expected groups appear in the session and an account outside those groups is denied on a protected site. Keep the production file backend untouched while you test. Done when every test account reaches the expected resources and the login logs show the directory as the source of the first factor.
Check second factors and preferences in Authelia's database
Authelia stores user preferences, second factor device registrations and authentication logs in its own database, separate from the user store. Before the cutover, confirm that existing one-time password, security key, passkey and Duo registrations are linked to the same usernames the directory now returns, because a changed username can orphan a registration. Sign in with a test account that has a registered second factor and confirm it is still offered and accepted. Done when each test user's registered factors and saved preferences load after the switch.
Verify password reset behavior after the switch
Authelia offers self-service password reset, but its behavior depends on where passwords are written. Test a reset on a test account and confirm where the new password is stored and whether the user can sign in with it. If you use LLDAP, confirm that its email-based reset is configured. If you use OpenLDAP, FreeIPA or Active Directory, confirm which system owns the reset flow and who answers when a user is locked out. Done when a reset completes end to end and the owning team is named in the runbook.
Cut over and keep the file backend for rollback
Switch the production configuration to the directory backend during a window agreed with the application owners, while leaving the YAML file and its configuration block in place but unused. Keep the prior configuration file under version control so a rollback is a single revert. Done when production sign-ins succeed for a sample of real users and the rollback steps have been rehearsed on staging.
Retire file entries after rollback is no longer needed
Once the team agrees the rollback window is closed, remove the file backend from the active configuration and delete the plaintext or hashed user entries from the YAML file, storing the old file in a restricted backup location according to your retention policy. Confirm that the backup restores in a test environment before deletion. Done when Authelia runs with the directory as its only user source, the file is archived and the change is recorded in your change log.
Storage, scale and what they cost to run
The file backend and an LDAP backend store different things in different places, and that split drives most of the running cost. With the file path, user accounts and their hashed passwords live in a YAML file that you keep under configuration management, while Authelia's own state (user preferences, second factor device registrations and authentication logs) goes to PostgreSQL, MySQL or local SQLite, according to the Authelia storage documentation. Nothing else needs to run. With LDAP, Authelia depends on a directory server that holds the users and groups, so you add a service with its own database, backups, TLS certificates and patching, while Authelia's SQL storage still applies. Before you choose, confirm which SQL engine you will operate and who owns its backups.
LLDAP is the lightest LDAP option in this comparison. Its README and FAQ say it runs in under 10 MB of RAM including the database and that its image is about 10 times smaller than OpenLDAP's, or 20 times smaller with PhpLdapAdmin added. These are the project's own figures, so measure them in your environment before you size a host. LLDAP stores data in SQLite by default and supports MySQL, MariaDB or PostgreSQL, so plan that migration early if you expect growth. For larger directories, OpenLDAP 2.6 documents the MDB backend, built on LMDB, and single-provider, multiple-consumer or multi-provider replication when a single point of failure is not acceptable. Each replica is another server to patch and monitor, so the number you need depends on your availability target, which you should set before you ask for a quote.
Cost comes from who operates the directory, not from the software licenses, which are free in every option here. Ask who patches the directory, who rotates its TLS certificates, who restores it from backup, and who is on call when Authelia cannot authenticate anyone. LLDAP has no commercial support and its FAQ describes it as volunteer-developed with a bus factor of one, so a team that adopts it should budget internal maintenance time. OpenLDAP and FreeIPA are maintained by larger communities and can be paired with paid support from third parties, which you should confirm with each vendor. The migration from file to LDAP is recurring project work: someone must map existing accounts, reset or import passwords, and test each Authelia access rule against the new directory. Ask any implementation partner for a written scope that names those tasks and the testing evidence you will receive.
Questions teams ask before choosing a user backend
Is the YAML file backend enough for a small team?
For a small, stable group of users, usually the file backend is enough, provided you accept that every user change is an edit to a configuration file. Authelia authenticates against a YAML file of users with hashed passwords, and it can also store preferences, second factor registrations and logs in PostgreSQL, MySQL or local SQLite. The drivers to weigh are how often accounts change, whether more than one person administers them, and whether you need group membership to come from a source other than your own files. Confirm in a written scope who edits the file, how changes are reviewed and backed up, and how a departing user is removed the same day.
What does a move from the file backend to LDAP involve?
A move means choosing a directory, loading users and groups into it, pointing Authelia's first factor at that directory, and testing every protected application against it. Authelia supports LDAP directories such as OpenLDAP, OpenDJ, FreeIPA and Microsoft Active Directory, and LLDAP can serve as a lightweight option. The work splits into directory setup, data migration, Authelia configuration, and a cutover plan that keeps existing sessions and second factor registrations usable. Ask for the list of applications, the group rules they depend on, and a rollback step in the written scope before any directory is built.
Do second factors and password resets work the same after moving to LDAP?
Second factors and password reset depend on how each piece is configured, so do not assume they carry over unchanged. Authelia offers one-time passwords, security keys, passkeys and Duo mobile push as second factors, plus self-service password reset and account banning after repeated failures. Authelia stores second factor device registrations in its own database, so a backend change alone does not remove them, but the reset flow and the source of truth for the password change. Confirm with the vendor documentation and in a test environment how password change and reset behave against your chosen directory before cutover.
Does LLDAP suit a large organization?
LLDAP is a poor fit for a large organization unless your own team is prepared to audit and maintain it. Its FAQ describes it as hobbyist software developed by volunteers, with a bus factor of one, and says it is not recommended for the infrastructure of a big organization on that basis. It is GPL-3.0 licensed, it offers no commercial support, and it does not natively support virtual hosts or multi-tenancy, so all users sit under one base DN. Its strengths are a small footprint and a simple web interface for users and groups. For larger deployments, weigh OpenLDAP or FreeIPA, and ask any implementation partner to state in writing which support path applies.
How much effort does a directory add, and what must our team provide?
A directory adds ongoing operational work, because someone must run, patch, back up and monitor it alongside Authelia. The effort depends on the directory you choose, whether it is shared with other systems, and whether it must be highly available. OpenLDAP's slapd supports replication, including multi-provider replication where a single point of failure is not acceptable, which adds design work. Your team should provide the hosting target, a named directory owner, the list of users and groups, TLS certificates, and access to the applications under test. Ask for the effort split between your staff and the implementation partner in the written scope.
Should an implementation partner run the migration from file to LDAP?
A partner is worth considering when the migration touches several applications, shared directories or compliance evidence that your team cannot produce alone. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so the quote follows from that scope. If your team has directory and Authelia experience, you may only need a review. Ask for the deliverables, the acceptance tests, who owns the rollback, and what support follows cutover.
Can we check the directory choice before committing to it?
Yes, and a short proof of concept against a non-production copy of your user data is the most reliable check. Test login with the first factor, each second factor you plan to offer, password change and reset, group based access rules, and removal of a departed user. Record the storage used by Authelia's database and the directory's own backup size, since these shape your hosting plan. Confirm each product's current version and license terms on its official release page before you commit, because licensing and support windows change.
How DeployOpen scopes and delivers identity backend work
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Authelia file backend vs LDAP backend, the work usually starts with deciding which user store fits your directory, then building and handing over the chosen backend.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before any work starts.
- The written scope names which user backend is in play, such as a YAML file or an LDAP directory, and why.
- Scope records the user count, password reset expectations, group model and the reverse proxies Authelia must protect.
How we build
- Work is carried out inside your own cloud accounts, data centers or air-gapped networks, not in a DeployOpen-hosted environment.
- We configure the Authelia backend, storage connection and group-to-access rules, then test login, second factor and password reset paths.
- Testing covers failure cases such as directory outages and locked accounts, with results recorded for your review.
How we hand over
- Deliverables include configuration documentation, runbooks for adding users and groups, and a record of the chosen storage layout.
- Handover covers how to move from a file backend to LDAP later, so the migration path is documented before you need it.
- Compliance-relevant evidence, such as access configuration and logs, is organized so your auditors can review it independently.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- Retainer scope is agreed in writing, so you know which Authelia upgrades, directory changes and tests are covered.
- Ask any provider to confirm in writing who maintains the directory itself, since LDAP operation often sits outside the Authelia engagement.
