LLDAP

Self-hosted identity management, honestly reviewed. No marketing fluff, just what you get when you run your own user directory.

TL;DR

• What it is: A lightweight LDAP authentication server written in Rust — think OpenLDAP, stripped down to just what self-hosters actually need, with a web UI that doesn’t require an LDAP degree to operate [README][5].
• Who it’s for: Homelab operators, small-team self-hosters, and developers running multiple services (Nextcloud, Gitea, Authelia, Proxmox) who want a single source of truth for users instead of managing accounts per-app [4][5].
• Cost savings: No pricing tiers, no per-user fees — LLDAP is GPL-3.0 licensed and runs on the same $5–10/mo VPS you’re probably already renting. The cost is your setup time [README].
• Key strength: Dramatically lower operational complexity than OpenLDAP. No slapd configuration, no schema archaeology. Web UI is usable by non-sysadmins. Bootstrap script supports infrastructure-as-code [README][5].
• Key weakness: Not a full LDAP server — deliberately limited. No account expiry, no disabled/locked account attributes, no native OAuth/OIDC. If you need those, you’re pairing LLDAP with Authelia or Authentik, not replacing them [3][5].

---

What is LLDAP

LLDAP is a lightweight authentication server that speaks LDAP — specifically, just enough LDAP to act as a user directory for the self-hosted apps that require it. The GitHub README opens with “LDAP made easy,” which is a low bar to clear given how painful OpenLDAP configuration historically is, but LLDAP clears it [README].

The project’s goal is stated plainly in the README: it is not a full LDAP server. It is a user management system that is simple to set up, simple to manage via a friendly web UI, low on resources, and opinionated enough that you don’t need to understand LDAP subtleties to get it running [README]. The backend is SQLite by default, with optional MySQL/MariaDB or PostgreSQL for anything more demanding.

What makes LLDAP specifically interesting is the problem it solves for multi-service self-hosting. When you’re running Nextcloud, Gitea, Home Assistant, Proxmox, and a handful of other services, you end up with separate user accounts in each. Resetting a password means touching five systems. Adding a new team member means doing the same. LLDAP solves this with a single user directory those services query via LDAP. One user, one password, propagated everywhere [5].

The project has 6,112 GitHub stars at time of writing, 315 forks, 1,113 commits. It’s written in Safe Rust — the README badges “unsafe-forbidden” as a feature, which in practice means a class of memory-safety bugs is structurally impossible [README]. It ships with 10 releases, a Discord server, and an active issue tracker.

---

Why People Choose It

The consistent reason people land on LLDAP is that OpenLDAP is operationally painful and LLDAP isn’t. The Alpine Linux wiki entry [1] describes a complete from-scratch install in under five minutes: download the binary, write a config file, write an init script, start it. That’s the whole setup for a basic deployment.

Helge Klein’s write-up [4] — which covers a full home network auth stack with Authelia, LDAPS, and Caddy — frames LLDAP as “a lightweight LDAP authentication server with a friendly web UI that aims to make user management easy.” Klein uses it as the identity source for Authelia, which then provides SSO and 2FA. This is the canonical architecture: LLDAP stores users and groups, Authelia handles the actual authentication flow for web services. Each tool does one thing.

The Stonegarden blog [5] offers the most technically detailed take. The author chose LLDAP specifically for two reasons: simplicity to get started, and the bootstrap script that enables declarative user/group management. They also call out that LLDAP is written in Safe Rust as a “nice bonus” for resilience against buffer overflow and use-after-free attacks. For a service that’s permanently exposed to your internal network (and potentially to the internet via LDAPS), that matters.

The Medium guide [2] approaches it from the other direction — GitLab integration — and describes LLDAP as “easier to configure than traditional OpenLDAP” with a “user-friendly web interface for managing users and groups.” The guide walks through a full Docker Compose setup with Caddy handling HTTPS, which reflects the typical production architecture.

Authelia’s own integration documentation [3] lists LLDAP as a supported implementation with dedicated defaults — meaning the authentication_backend configuration is shorter and less error-prone than with generic LDAP. That first-class integration support is worth something in practice.

---

Features

Core directory:

• LDAP interface on port 3890 (configurable) [README][1]
• Web UI on port 17170 for user and group management [README][4]
• Users can self-edit details and request password reset via email [README]
• Custom attributes via web UI or CLI tool (lldap-cli) [README]
• Bootstrap script (bootstrap.sh) to enforce users/groups/attributes from a file — infrastructure-as-code for your user directory [README][5]
• GraphQL API for scripting and automation [README]
• Unofficial Terraform provider for managing user/group lifecycle declaratively [README]

Storage:

• SQLite by default — zero additional dependencies for small deployments [README]
• MySQL/MariaDB or PostgreSQL for scale or HA [README][5]

Security:

• LDAPS (encrypted LDAP over TLS) — optional but recommended for inter-container or internet-exposed setups [README][1][5]
• JWT-based session authentication for the web UI [1][4]
• Safe Rust implementation — no unsafe code by design [README][5]
• Secrets management via file-based env vars (compatible with Docker secrets) [4]

Deployment:

• Docker and Podman support with official images [README][2][4]
• Kubernetes support, including community-maintained Helm chart and Kustomize examples [README][5]
• TrueNAS Scale support [README]
• Distribution packages: Arch, Debian, CentOS, Fedora, OpenSuse, Ubuntu, FreeBSD [README]
• Binary tarball install for non-container environments [1]
• Cross-compilation for different hardware architectures [README]

What LLDAP deliberately does NOT do:

• OAuth/OIDC — pair it with Authelia, Authentik, or Keycloak for that [README][5]
• Account disable/lock attributes — Authelia docs note there’s “no suitable attribute for this as far as we’re aware” [3]
• Password expiry or account expiry tracking [3]
• Full OpenLDAP schema compatibility — it’s opinionated and simplified [README]

---

Pricing: SaaS vs Self-Hosted Math

There is no SaaS tier. LLDAP has no managed cloud offering, no paid features, no freemium gate. The software is GPL-3.0 licensed, the code is on GitHub, and it runs wherever you want to run it [README].

The cost model is simple:

• LLDAP itself: $0
• Infrastructure: whatever you’re already paying for a VPS or home server
• Your time: the main variable

For comparison, the hosted identity-as-a-service alternatives:

• Okta: free up to 100 monthly active users, then $2–$8/user/month. At 25 users you’re looking at $50–$200/mo.
• JumpCloud: free for up to 10 users, then $9–$15/user/month. At 25 users: $225–$375/mo.
• Auth0 (Okta): free tier exists but production use gets expensive fast — $23+/mo for basic features, scaling with user count.
• Azure Active Directory (Entra ID): Free tier for basic features, but MFA and conditional access push you toward $6/user/month tiers.

LLDAP on a $6 Hetzner VPS (which you’re probably already running) vs JumpCloud at 25 users: roughly $3,300/year saved. Even at 10 users, JumpCloud’s commercial tier runs you $90–$150/mo vs essentially nothing for self-hosted.

The honest caveat: LLDAP isn’t a direct replacement for Okta or JumpCloud in an enterprise context. Those products include device management, policy enforcement, MFA built-in, compliance reporting. LLDAP is a user directory for self-hosted apps. The comparison is valid when the use case matches — a team running a homelab or a small company’s internal tools stack, not a 200-person company with compliance requirements.

---

Deployment Reality Check

The Alpine Linux install guide [1] gives you the clearest picture of the floor: download a binary, write a 20-line config file, write an init script, start the service. Five minutes. That’s the minimum viable deployment.

The Docker path is longer but more production-ready. Helge Klein’s setup [4] includes Docker Compose, Caddy as reverse proxy with Let’s Encrypt certificates, Docker secrets for JWT and password files, and ZFS-encrypted storage for sensitive config. That’s probably 1–2 hours for someone comfortable with Docker who hasn’t done it before.

The Medium GitLab integration guide [2] estimates the full setup (Docker, DNS, Caddy, LLDAP, GitLab LDAP config) at a session’s worth of work — the guide is 13 minutes of reading, which suggests the actual setup is 30–90 minutes if nothing goes wrong.

What you actually need for a basic setup:

• A Linux host with Docker (or a package manager)
• A domain name if you want HTTPS for the web UI
• A reverse proxy (Caddy or nginx) for HTTPS
• SMTP credentials if you want email-based password reset
• 5–10 minutes to configure each integrated app after LLDAP is running

What can go sideways:

• DNS rebind protection in home routers can break internal domain resolution — Helge Klein calls this out explicitly [4].
• LDAP filter syntax is arcane. Even LLDAP’s simplified setup requires you to understand distinguished names (UID=user,OU=people,DC=example,DC=com). The Authelia docs [3] give you the correct filter patterns, but if you’re deviating from the documented setup, you’re debugging LDAP, which is unpleasant.
• Account management limitations are a real operational gap. There’s no way to disable an account without deleting it — the Authelia docs note the absence of a disabled/locked attribute [3]. If you need to suspend a user without removing their history, LLDAP doesn’t have a clean answer.
• LDAPS setup requires a certificate and additional configuration. The Stonegarden guide [5] covers this with Cert-manager on Kubernetes. On bare Docker it’s more manual.
• High availability requires switching from SQLite to PostgreSQL/MySQL and putting thought into the database tier [5]. SQLite is fine for single-node, not for multi-node.

Realistic time estimate: 15–30 minutes for a technical user deploying to Docker with an existing reverse proxy. 1–3 hours if you’re also setting up DNS, Caddy from scratch, and connecting your first LDAP-integrated app. Non-technical users will struggle — this is a sysadmin tool.

---

Pros and Cons

Pros

• Radically simpler than OpenLDAP. No slapd, no schema files, no ldapmodify. Config is a TOML file with sensible defaults [README][1]. This is the entire value proposition and it delivers.
• Web UI that non-sysadmins can use. Users can reset their own passwords and edit their own details without involving an admin [README][4]. That self-service angle reduces operational toil for anyone running LLDAP for a team.
• Bootstrap script for declarative config. bootstrap.sh enforces a desired state from a file — add it to your IaC setup and user/group management becomes code-reviewable and reproducible [README][5].
• GraphQL API + Terraform provider. Scriptable and automation-friendly beyond what most lightweight auth servers offer [README].
• Safe Rust implementation. Memory safety by construction isn’t just a marketing claim — it’s a structural property of the language enforcement [README][5].
• First-class integration with the self-hosted ecosystem. Authelia, Authentik, Keycloak, Nextcloud, Gitea, Proxmox, Home Assistant — the README’s compatible services list is long and the Authelia docs have dedicated LLDAP configuration defaults [README][3].
• Multiple storage backends. SQLite for simplicity, PostgreSQL/MySQL for production durability [README][5].
• Truly free. GPL-3.0, no enterprise tier, no hosted SaaS to accidentally lock yourself into [README].

Cons

• No account disable/lock. This is the most operational painful gap. If a user leaves and you want to disable access without deleting their record, you can’t — you delete the user [3]. This may be a non-issue for homelab use and a hard blocker for team use.
• No native OAuth/OIDC. LLDAP is a user directory, not an identity provider. You must pair it with Authelia, Authentik, or Keycloak to get SSO for modern applications. That’s more components to maintain [README][5].
• No password policy enforcement. Password complexity rules, expiry, rotation — none of that is built in [3].
• LDAP is still LDAP. Even simplified, LDAP concepts (DNs, OUs, filters, objectClasses) are foreign to developers who’ve only worked with OAuth. The learning curve isn’t zero [2][5].
• GPL-3.0 vs MIT. If you’re embedding LLDAP in a commercial product or building a managed service on top of it, GPL-3.0 has implications. Not an issue for self-hosters, but worth noting [README].
• Limited attributes. The opinionated schema means some integrations require custom attributes — which you can add through the UI or CLI, but it’s extra setup [README][3].
• Single-node by default. SQLite and single-instance design means HA requires intentional configuration with an external database [5].

---

Who Should Use This / Who Shouldn’t

Use LLDAP if:

• You’re running 3+ self-hosted services that support LDAP and you’re tired of managing users in each separately.
• Your use case is a homelab or a small internal tools stack — not a company with compliance requirements.
• You want infrastructure-as-code user management via the bootstrap script or Terraform provider.
• You’re already running Docker and a reverse proxy — LLDAP adds minimal operational overhead.
• You want to pair it with Authelia or Authentik for SSO/2FA and need a user directory those tools can query.

Skip it (use OpenLDAP instead) if:

• You need full LDAP schema compatibility — arbitrary objectClasses, complex ACLs, custom schemas beyond what LLDAP supports.
• You’re an enterprise with existing OpenLDAP infrastructure that you understand and maintain.

Skip it (use Authentik or Keycloak instead) if:

• You need OAuth/OIDC, SSO, MFA, and user management all in one place — Authentik does all of that and includes an LDAP provider. You might not need LLDAP at all.
• You need account disable/lock, password expiry, or compliance audit trails.
• Your team has more than ~20 users with varying permission levels that need fine-grained management.

Skip it (use a hosted IdP instead) if:

• You’re a non-technical founder who can’t or won’t maintain Docker services.
• Your compliance team requires SOC 2, HIPAA, or equivalent certification for identity management.
• You have fewer than 5 services and the overhead of a user directory isn’t worth it.

---

Alternatives Worth Considering

• OpenLDAP — the full LDAP server that LLDAP explicitly doesn’t want to be. Complete schema support, ACLs, replication, the works. Also: slapd configuration is a multi-hour exercise and the documentation assumes you already know LDAP. Use if LLDAP’s simplifications are blockers.
• FreeIPA — full identity management suite: LDAP, Kerberos, DNS, certificate management. Far more than most self-hosters need, but genuinely enterprise-grade [5].
• Kanidm — modern, opinionated identity server in Rust. Better OAuth/OIDC story than LLDAP, different philosophy. Worth evaluating if LLDAP’s LDAP-only limitation is the issue [5].
• Authentik — if you want a single system that handles LDAP, SAML, OAuth/OIDC, SSO, and has a web UI for managing it all. Heavier operationally than LLDAP but eliminates the need for LLDAP + Authelia as separate components.
• Authelia — not a replacement, a complement. Authelia provides SSO, 2FA, and reverse proxy auth integration. The recommended architecture is LLDAP (user store) + Authelia (authentication layer) [4][5].
• Keycloak — the enterprise choice. Full IdP with LDAP federation, SAML, OIDC, admin console. Significant resource requirements compared to LLDAP — expect 512MB–1GB RAM just for Keycloak itself.
• Zitadel — newer, cloud-native IdP. Better developer experience than Keycloak, supports LDAP as an external user source, good if you want modern auth standards.
• GLAuth — another lightweight LDAP server, similar positioning to LLDAP but with different feature trade-offs.

For the typical self-hosted homelab or small internal tools deployment, the realistic choice is LLDAP + Authelia (simple, two components, well-documented together [3][4]) versus Authentik (one component, more complex, more capable). Pick LLDAP+Authelia if you want to understand each layer. Pick Authentik if you want fewer services to maintain.

---

Bottom Line

LLDAP solves a narrow problem well: giving self-hosted services a shared user directory without the complexity of OpenLDAP. If you’re managing 5+ services that speak LDAP and you’re resetting passwords in each one separately, LLDAP is the obvious fix — a weekend afternoon to deploy, then largely forget about. The operational gaps (no account disable, no password policy, no native OAuth) are real, but they’re scope decisions, not bugs. The answer to all of them is “pair it with Authelia or Authentik,” which is the architecture the project itself recommends. At 6,112 stars, a maintained Rust codebase, and first-class support in Authelia’s own documentation, it’s not a risky bet. If the deployment is the blocker, that’s exactly what upready.dev handles for clients as a one-time service.

---

Sources

1. Alpine Linux Wiki — Setting up a LLDAP server. https://wiki.alpinelinux.org/wiki/Setting_up_a_LLDAP_server
2. Ugwu Somtochukwu Hyacinth, Medium — “Setting Up LLDAP with GitLab on Docker: A Complete Beginner’s Guide” (Mar 2026). https://medium.com/@somtohyacinthugwu/setting-up-lldap-with-gitlab-on-docker-a-complete-beginners-guide-d9c2ad713e9a
3. Authelia Documentation — LLDAP Integration. https://www.authelia.com/integration/ldap/lldap/
4. Helge Klein — “Authelia & lldap: Authentication, SSO, User Management & Password Reset for Home Networks” (Dec 2022, updated Dec 2025). https://helgeklein.com/blog/authelia-lldap-authentication-sso-user-management-password-reset-for-home-networks/
5. Stonegarden Blog — “LLDAP — Declarative Selfhosted Lightweight Authentication” (Jan 2025). https://blog.stonegarden.dev/articles/2025/01/lldap/

Primary sources:

• GitHub repository and README: https://github.com/lldap/lldap (6,112 stars, GPL-3.0 license)
• Authelia LLDAP client configuration docs: https://www.authelia.com/integration/ldap/lldap/