The lldap vs OpenLDAP decision comes down to one trade-off: simplicity or full protocol compliance. lldap is a lightweight, opinionated server built for user authentication. It ships with a web interface and needs almost no configuration. OpenLDAP implements the complete LDAP standard, including custom schemas, replication, and fine-grained access control. That flexibility brings a steeper learning curve and more upkeep. Small self-hosted setups usually fit lldap, while larger or compliance-driven environments usually need OpenLDAP.
Both servers run well in Docker on a small Linux VPS. The sections below compare both servers and outline a basic OpenLDAP Docker setup. They also help you match the right option to your team.
How lldap and OpenLDAP Differ
Both projects speak LDAP, but they target different jobs. lldap describes itself as a user management system rather than a full directory server. It stores users and groups in SQLite by default, with MySQL, MariaDB, or PostgreSQL as alternatives. The directory tree is fixed: users live under ou=people and groups under ou=groups. You manage everything through the built-in web UI or the GraphQL API. Users can edit their own details and reset forgotten passwords by email once SMTP is configured. Built-in groups such as lldap_strict_readonly let you give each application a read-only bind account instead of admin rights.
OpenLDAP takes the opposite approach. It implements the full LDAPv3 protocol plus a long list of extensions. You design the directory tree, load the schemas you need, and control access with detailed ACLs. Overlays add features such as password policies, memberOf attributes, and multi-provider replication. Configuration lives in the cn=config tree and changes through LDIF files. OpenLDAP has no web interface, so most admins add a separate tool for daily management.
Resource use and defaults differ too. lldap is written in Rust and runs comfortably on very small machines. According to its maintainers, its image is roughly ten times smaller than a typical OpenLDAP image. By default, lldap listens on port 3890 for LDAP and 17170 for the web UI. It stores passwords using the OPAQUE protocol, while OpenLDAP supports several standard hash formats. lldap also has no replication of its own. Data protection depends on regular backups or on a replicated database server behind it. OpenLDAP, by contrast, can keep several directory servers in sync across sites.
| lldap | OpenLDAP | |
| Setup complexity | Low. One container, a few environment variables, and a working web UI on first start. | High. The directory tree, schemas, ACLs, and TLS need planning before production use. |
| Feature completeness | Covers authentication needs: users, groups, memberOf, and custom attributes. LDAP support is intentionally partial. | Full LDAPv3 with extensions, overlays, custom schemas, and replication. |
| Day-to-day management | Built-in web UI, user self-service, and a GraphQL API for scripting. | Command-line tools and LDIF files. Web interfaces are separate add-ons. |
| Storage | SQLite by default, with optional MySQL, MariaDB, or PostgreSQL. | Its own LMDB-based database backend. |
| Typical use case | Homelabs and small teams connecting apps like Nextcloud, Gitea, or Authelia. | Larger organizations, Linux accounts at scale, and multi-site or compliance-heavy setups. |
Setting Up an OpenLDAP Server
Running OpenLDAP in Docker keeps the directory isolated and makes upgrades easier to roll back. This section covers the container side only. For LDIF files, adding entries, and writing access rules, the LDAP management basics guide explains each task in detail.
Start with the image, because the choice matters more than usual here. The long-popular osixia/openldap image has not received updates since 2021. In 2025, Bitnami moved its free OpenLDAP image behind a commercial subscription. Its older tags now sit in a legacy repository without security patches. Choose an image with recent releases, or build your own from your distribution’s slapd package. Pin a specific version tag rather than latest.
The following Compose file uses the Bitnami-style variables that several maintained rebuilds kept. Check your image’s documentation, since variable names and data paths vary between images.
services:
openldap:
image: your-registry/openldap:2.6 # pin a maintained image
container_name: openldap
restart: unless-stopped
environment:
- LDAP_ROOT=dc=example,dc=com
- LDAP_ADMIN_USERNAME=admin
- LDAP_ADMIN_PASSWORD=change-me
ports:
- "127.0.0.1:1389:1389"
volumes:
- openldap_data:/bitnami/openldap
volumes:
openldap_data:Binding the port to 127.0.0.1 keeps LDAP off the public internet. Other containers on the same Docker network reach the server by its service name. If remote clients need access, enable LDAPS with a valid certificate and allow only trusted IPs in your firewall. In Bitnami-style images, LDAPS listens on container port 1636. Before production, move the admin password out of the Compose file and into an .env file or a Docker secret.
Start the container:
docker compose up -dInstall the LDAP client tools on the host:
sudo apt install ldap-utilsThen run a test search against the new directory:
ldapsearch -x -H ldap://127.0.0.1:1389 \
-D "cn=admin,dc=example,dc=com" -W \
-b "dc=example,dc=com"A successful search returns the base entry of your directory. From there, you can add organizational units, users, and groups with LDIF files. Back up the data volume on a schedule, or export the directory with slapcat for a portable copy. For a browser-based interface, run LDAP Account Manager or phpLDAPadmin as a second container on the same network.
Which One to Pick
Start with what the directory actually needs to do. If it only has to confirm who a user is and which groups they belong to, lldap covers it. That describes most homelabs and small teams running Nextcloud, Gitea, Jellyfin, or a reverse proxy with login protection. One person can run lldap without learning LDAP internals. For single sign-on and OpenID Connect, pair it with Authelia, Authentik, or Keycloak.
OpenLDAP earns its complexity once requirements grow. Choose it when you need custom schemas, for example for mail routing or device inventories. It also fits when several sites need replicated directories, or when auditors expect strict ACLs and password policies. Teams with a dedicated admin handle this well. A solo admin with little spare time often ends up with a fragile setup.
Tolerance for complexity matters as much as headcount. A five-person company with strict compliance rules may still need OpenLDAP. A 50-person company that only uses web apps may run happily on lldap. When requirements are unclear, a test deployment of lldap takes minutes and quickly shows whether your apps work with it.
Neither server needs much hardware at typical directory sizes. A Contabo Cloud VPS 4 offers 4 vCPU cores and 8 GB RAM. That is enough to run either option alongside the apps that authenticate against it. Planning to host OpenLDAP next to a larger application stack? Cloud VPS 6 adds headroom with 6 vCPU cores and 12 GB RAM. For OpenLDAP replication, a second server in another region gives you a real failover target. Whichever server you choose, it holds every credential in your stack. Keep it patched, firewall the LDAP port, and store backups off the server.
FAQ: lldap vs OpenLDAP
Is lldap compatible with tools built for OpenLDAP?
Mostly, as long as the tool uses LDAP for authentication. Applications that verify logins and read group membership usually work out of the box. Group filters based on memberOf are supported, which covers most access rules. The lldap project maintains example configurations for many popular services, and Linux logins work through PAM and nslcd. Gaps appear at the edges. Generic LDAP browsers often behave oddly, and some apps expect attributes you must first create as custom attributes. Services that need to read password hashes, such as Synology NAS systems, do not work at all. lldap uses a zero-knowledge password scheme and never hands out hashes. Before committing, test each application against a throwaway lldap container with a dedicated read-only bind user. Failed binds or missing groups usually show up in the app’s logs right away.
Which one is easier to maintain long-term?
lldap wins for most setups. Its state lives in one database plus a config file, so a backup is a copy of the data folder. Updates usually mean pulling a new image and restarting the container:
docker compose pull && docker compose up -d
OpenLDAP asks for more ongoing attention. Schema changes, ACL edits, and overlay settings all go through LDIF and cn=config. Replication needs monitoring, and consistent backups rely on slapcat exports. In return, OpenLDAP has more than two decades of production use and commercial support from vendors like Symas. lldap is a younger community project with a smaller maintainer team. Security updates work the same way for both: watch the project releases and rebuild containers when patches land. With OpenLDAP, also review TLS certificates and ACLs after major upgrades.
Can I migrate from OpenLDAP to lldap later?
Yes, if your directory fits lldap’s model. The lldap repository includes a migration tool that reads users and groups from an existing LDAP server. Password hashes do not carry over, because lldap stores credentials in a different format. Plan for every user to set a new password, ideally through the email reset flow, and announce the change early. Review your client configurations as well. lldap uses a fixed tree, so base DNs and search filters in your apps may need updates. Export a full LDIF backup with slapcat before you start, so a rollback stays possible. Run both servers in parallel during the switch. Move one application to lldap first, confirm logins work, then migrate the rest. Custom schemas, extra organizational units, and replication have no equivalent in lldap. Directories that depend on those features should stay on OpenLDAP.
