LLDAP

Last reviewed Sep 13, 2026 · 865 words

LLDAP is what you run when 8 self-hosted apps each have their own user table and you want one place to create an account, one place to disable it, and one password. It speaks enough LDAP for Jellyfin, Nextcloud, Gitea, Grafana, Home Assistant, Authelia and most of the rest to authenticate against it, has a web UI a family member could use, and idles at under 64 MB. It is not a full LDAP server, and the whole point is that you will never need it to be.

Why not OpenLDAP or Keycloak

OpenLDAP is a general-purpose directory with schemas, replication, ACLs and 25 years of configuration idioms; setting it up for a homelab means learning slapd.conf or the cn=config tree to store 6 users. Keycloak is an identity provider with its own user store and needs around 1 GB of JVM to get going. LLDAP occupies the gap: a Rust binary with an SQLite file, a fixed schema of users and groups plus a handful of custom attributes, and a read-mostly LDAP interface that covers what applications actually query. The trade is deliberate. You cannot extend the schema arbitrarily, there is no replication, and LDAP clients cannot create users through the protocol; the web UI and GraphQL API do that. In exchange you get a directory that a person who has never typed ldapsearch can administer.

The compose file

services:
  lldap:
    image: lldap/lldap:stable
    ports:
      - "3890:3890"
      - "17170:17170"
    volumes:
      - ./lldap_data:/data
    environment:
      - TZ=Europe/London
      - LLDAP_JWT_SECRET=a-long-random-string
      - LLDAP_KEY_SEED=another-long-random-string
      - LLDAP_LDAP_BASE_DN=dc=example,dc=com
      - LLDAP_LDAP_USER_PASS=initial-admin-password
    restart: unless-stopped

Port 3890 is LDAP, 17170 is the web UI. Generate the two secrets with openssl rand -base64 32 each and never change LLDAP_KEY_SEED after first start; it encrypts stored secrets. Sign in at 17170 as admin, then create a user for yourself and a group per role. LDAPS on 6360 is available with a cert path, but on a Docker network or a Tailscale mesh I leave the plain port on, because the traffic never leaves a trusted segment. Do not publish 3890 to the internet under any circumstances.

The bind DN cheat sheet

Every app's LDAP settings page asks the same 4 questions and this is the LLDAP answer to each, assuming the base DN above:

Bind user: uid=admin,ou=people,dc=example,dc=com (or better, a dedicated read-only user placed in the lldap_strict_readonly group).

User search base: ou=people,dc=example,dc=com, with filter (&(objectClass=person)(uid={input})) or whatever the app's placeholder syntax is.

Group search base: ou=groups,dc=example,dc=com, with members listed in the member attribute and the user's groups in memberOf.

Attributes: username is uid, email is mail, display name is displayName, first and last names are givenName and sn. Avatars are jpegPhoto.

Restricting an app to a group is a filter on memberOf=cn=jellyfin_users,ou=groups,dc=example,dc=com. The LLDAP repository keeps a per-application configuration directory with worked examples for around 40 apps, which has saved me more time than any other single document in this space.

Pair it with an SSO layer, do not stop at LDAP

LLDAP is the user store. It does not do single sign-on, OIDC or two-factor; that is the job of Authelia or Authentik, both of which take LLDAP as their backend. The combination I run is LLDAP plus Authelia: Authelia handles the login page, TOTP and the forward-auth rules in front of the reverse proxy, and LLDAP holds the accounts. Apps that support OIDC log in through Authelia; apps that only know LDAP talk to LLDAP directly; both see the same users and groups. The Authentik versus Authelia walkthrough covers picking between the two front ends. If you would rather have the store and the SSO in one binary, Kanidm does that and is the more ambitious project, at the cost of a stricter model and less mainstream LDAP compatibility.

Operational notes

Back up /data, which holds the SQLite file; it is a few hundred kilobytes. Password resets can be emailed if you configure SMTP; otherwise the admin sets them in the UI. There is a PostgreSQL and MySQL option for the database, and I have never met a homelab that needed it. Upgrades are pull and restart, and the project has been careful about migrations. Around 6,484 stars and a maintainer who answers issues is a comfortable place for infrastructure this simple to sit.

What I'd do

Deploy LLDAP first, before any SSO tool, and repoint 2 or 3 apps that already support LDAP at it in an evening; Jellyfin and Grafana are quick wins. Once you trust it, add Authelia in front for OIDC and 2FA. Keep the admin account for emergencies, do your day-to-day work with a user in lldap_admin, and give each app a read-only bind user. If you find yourself wanting schema extensions or replication, you have outgrown it and Kanidm or Keycloak are next; most people never do.