LLDAP: a Light LDAP Server for Self-Hosted Authentication

What LLDAP is for, and who it is not for

The README opens with a positioning statement that doubles as a warning: the goal is not to provide a full LDAP server, and readers who want one are pointed at OpenLDAP. What LLDAP does instead is act as a user management system with an LDAP interface bolted on, so that services which only support LDAP for external authentication have something to bind against.

The target audience is the self-hoster running Nextcloud, Airsonic and similar open-source components. The README lists four properties it optimises for: setup without slapd, a friendly web UI, low resource use, and opinionated defaults that hide LDAP subtleties. Those four pull in the same direction. Every one of them is a decision to remove configurability, which is why the incompatible-services section of the README exists at all.

If your directory needs schema extensions, replication, referrals or a general-purpose DIT, this is the wrong tool and the project says so itself. If you need OAuth or OpenID rather than LDAP, the README's recommended architecture puts KeyCloak, Authelia or Authentik in front and uses LLDAP as the source of truth for users behind them.

The architecture: a Rust server, a WASM frontend, and a GraphQL API

The workspace in Cargo.toml lists members server, app, migration-tool, set-password and crates/*, with server as the default member. The Dockerfile builds three Rust binaries (lldap, lldap_migration_tool, lldap_set_password) and then runs app/build.sh, which compiles the frontend to WebAssembly for the wasm32-unknown-unknown target. The final image is Alpine, and the entrypoint uses gosu to drop privileges, which matches the README's note that the default container starts as root to fix file permissions before downgrading.

Persistence is pluggable. SQLite is the default, and the README states you can swap the backend for MySQL/MariaDB or PostgreSQL. The presence of a migration-tool binary in the workspace is consistent with that: moving between backends is an explicit operation, not a config flag.

Management happens over two surfaces. The web UI covers users, passwords, groups and custom attributes. Underneath, a GraphQL API is exposed, with schema.graphql at the repository root and a docs/scripting.md guide. The README also mentions a community CLI (Zepmann/lldap-cli) and an unofficial Terraform provider for infrastructure-as-code workflows. The LDAP protocol side is implemented in Rust through ldap3_proto, and the server supports LDAPS for exposing the LDAP port, which the README describes as not recommended for internet exposure but optional for inter-container traffic. Password authentication uses opaque-ke, a PAKE protocol, which means the password is not sent to the server in the clear during the login exchange.

Installing LLDAP with Docker Compose and creating the first user

The README's installation section points to docs/install.md and lists the supported routes: OCI images for Docker and Podman, Kubernetes, TrueNAS SCALE, distribution packages for Archlinux, Debian, CentOS, Fedora, OpenSuse, Ubuntu and FreeBSD, and building from source or cross-compiling.

The repository ships lldap_config.docker_template.toml as the starting point for a container deployment, and config.toml for a local build. The template is where the container settings live, including the environment variables the entrypoint reads.

# lldap_config.docker_template.toml

The README's container guidance is explicit about which ports matter. The web port is the one you expose to your reverse proxy; the LDAP port does not need to be exposed, since only the other containers access it. The README also notes that the default container starts as root to fix up file permissions before downgrading the privilege to the given user, and that the rootless image variants start directly as that user once you have the permissions right, in which case you change from the UID/GID environment variables to the uid docker-compose field.

After the container is up, open the web UI and log in, then change the default admin credentials. From there you create users, set passwords and add group memberships without writing a single LDIF entry. The generate_secrets.sh script in the repository root produces the secrets the server needs, and the config template carries the corresponding keys.

Where LLDAP stops being the right answer

The incompatibility is deliberate and documented. Services that assume a full directory, expect attributes LLDAP does not model, or require write access to the directory from the client side will not work out of the box. The README's remedy is to open an issue with the service logs plus LLDAP logs at verbose=true, which tells you the maintainers treat client gaps as a normal category of problem rather than a bug.

The Windows story is the clearest boundary. The README describes Samba integration as WIP, so anyone hoping to replace an Active Directory domain controller with LLDAP is out of scope. Linux account integration is possible but goes through PAM and nslcd, with a separate guide under example_configs/pam; that is a manual configuration path, not a supported turnkey feature.

There is also an operational constraint in the container design. The default image starts as root to repair file permissions before dropping to the configured user. If your platform forbids root containers, you need the rootless image and you need to get ownership of the data volume right first, or the server will fail at startup. That is a real setup step, not a footnote.

Finally, custom attributes. The README says they can be created through the web UI or the community CLI, and that some service integrations require them. That sentence is doing a lot of work: it means a plain LLDAP install may not satisfy a client until you have modelled extra attributes by hand.

LLDAP versus OpenLDAP, glauth and Authelia

OpenLDAP is the alternative the project itself names. The difference is scope. OpenLDAP is a general directory server with schema control, replication and a configuration model built around slapd; LLDAP deliberately drops all of that in exchange for a web UI and defaults you do not have to understand. If your requirement list includes anything beyond authentication, OpenLDAP is the one that will still fit in two years.

glauth occupies a similar niche to LLDAP, a small LDAP server for authentication against a backend, but the two differ in what you administer. LLDAP ships its own user store and browser UI; glauth is typically configured from files or an existing backend rather than being the place where users live. If you want the directory to be the system of record with a UI on top, LLDAP is the closer match.

Authelia and Authentik are not alternatives to LLDAP in the same sense, and the README's recommended architecture treats them as complements: they sit in front and provide SSO and OAuth/OpenID, with LLDAP as the user source behind LDAP. Choosing between Authelia plus LLDAP and Authentik alone is really a question about whether you want a separate LDAP user store at all, since Authentik can hold users itself. That is a design decision about where identity lives, not a feature comparison.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-18. Releases are infrequent: v0.6.3 landed on 2026-04-30, v0.6.2 on 2025-08-17 and v0.6.1 on 2024-11-22. That cadence matters more than the push history for planning, because it means a fix you are waiting for may sit unreleased for months while the main branch moves. If you deploy from a tagged image, budget for that gap; if you build from source, you are tracking main.

The workspace pins rust-version = 1.91.0 and edition 2024, so building from source requires a recent toolchain. The Dockerfile pins rust:alpine3.21 and installs wasm-pack for the frontend, which is the path of least resistance if you do not want to manage a Rust toolchain yourself.

The licence is GPL-3.0-only, declared in Cargo.toml as GPL-3.0-only and shown in the repository as GPL-3.0. This is a copyleft licence. If you modify LLDAP and distribute it, or distribute a product that links against it, the GPL's terms apply to that distribution. Running it as a network service for your own users is a different situation from shipping it inside a product. That distinction is worth confirming with someone qualified before you build a commercial offering on top of it; nothing here is legal advice.

Upgrade cost is mostly tied to the storage backend. SQLite users upgrade in place. Anyone who has switched to MySQL/MariaDB or PostgreSQL should check CHANGELOG.md before jumping versions, since schema changes across a release boundary are the failure mode that hurts.

Editorial conclusion

Adopt LLDAP if you run a handful of self-hosted services that only speak LDAP and you want user management through a browser instead of slapd configuration files. Do not adopt it if you need a general directory server, Windows domain integration (the README calls Samba support WIP), or LDAP features beyond authentication. Verify first that your client appears in the example_configs folder, and that your deployment path (Docker, Kubernetes, TrueNAS or a distro package) is covered in docs/install.md.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. lldap/lldap on GitHub
4. README
5. Releases