LLDAP vs GLauth: Best Lightweight LDAP Servers for Self-Hosted Auth 2026

Running a full enterprise LDAP directory like OpenLDAP, 389 Directory Server, or FreeIPA is overkill for homelabs, small teams, and personal infrastructure. If you only need a simple way to authenticate users across self-hosted services — Dashboards, Proxmox, Nextcloud, or Gitea — you want something that installs in minutes, not days.

This guide compares the two most popular lightweight LDAP servers: LLDAP and GLauth. Both are open source, self-hosted, and designed for environments where simplicity matters more than enterprise feature depth.

For readers already running a full directory service, our OpenLDAP vs 389DS vs FreeIPA guide covers the enterprise alternatives in detail. If you’re building a complete auth stack, also see our Casdoor vs Zitadel vs Authentik comparison for SSO and identity management options.

Why Choose a Lightweight LDAP Server?

Traditional LDAP directories are powerful but complex. They require deep knowledge of LDIF schemas, overlay modules, and replication topology. For many use cases, you don’t need that complexity:

• Homelab authentication: A single source of truth for usernames and passwords across Jellyfin, Gitea, Proxmox, and other services
• Small team infrastructure: Shared credentials management without cloud dependency
• Development and CI/CD environments: Disposable LDAP instances for testing authentication flows
• IoT and edge deployments: Low-resource LDAP servers for constrained hardware

A lightweight LDAP server gives you the standardized LDAP protocol that hundreds of applications already support, without the operational overhead of an enterprise directory.

LLDAP: Modern Lightweight LDAP

LLDAP (Light LDAP) is a modern, opinionated LDAP server written in Rust. It targets simplicity: a web UI for user management, SQLite or PostgreSQL backends, and straightforward Docker deployment. As of April 2026, it has 6,193 GitHub stars and remains actively maintained.

Key Features

• Built-in web UI for user and group management — no LDIF files needed
• SQLite or PostgreSQL backend — SQLite is perfect for single-server setups
• Docker-native — single container deployment
• Schema management — supports standard LDAP object classes (inetOrgPerson, posixAccount)
• Password policies — configurable strength requirements
• TOTP support — optional two-factor authentication
• REST API — programmatic user management
• Low resource usage — Rust binary, typically under 100MB RAM

Docker Compose Setup

Here is a production-ready Docker Compose configuration for LLDAP with PostgreSQL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

version: "3"

services:
  lldap:
    image: lldap/lldap:latest
    container_name: lldap
    restart: unless-stopped
    ports:
      - "1717:1717"    # Web UI
      - "3890:3890"    # LDAP
      - "6360:6360"    # LDAPS
    volumes:
      - ./data:/data
    environment:
      - LLDAP_HTTP_PORT=1717
      - LLDAP_LDAP_PORT=3890
      - LLDAP_LDAP_BASE_DN=dc=home,dc=lan
      - LLDAP_JWT_SECRET=replace-with-random-secret
      - LLDAP_LDAP_USER_PASS=replace-with-strong-password
      - LLDAP_DATABASE_URL=postgres://lldap:lldap@lldap-db:5432/lldap

  lldap-db:
    image: postgres:17-alpine
    container_name: lldap-db
    restart: unless-stopped
    volumes:
      - ./db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=lldap
      - POSTGRES_PASSWORD=lldap
      - POSTGRES_DB=lldap

For the simplest setup, use SQLite by omitting the LLDAP_DATABASE_URL variable — the database file is stored in the mounted /data volume.

Reverse Proxy Configuration (Nginx)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

server {
    listen 443 ssl http2;
    server_name auth.example.com;

    ssl_certificate /etc/ssl/certs/lldap.crt;
    ssl_certificate_key /etc/ssl/private/lldap.key;

    location / {
        proxy_pass http://localhost:1717;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

GLauth: Config-Driven Lightweight LDAP

GLauth is a lightweight LDAP server written in Go, designed around configuration files rather than a database backend. It reads users and groups from YAML, JSON, or environment variables, making it ideal for infrastructure-as-code workflows and ephemeral environments. It currently has 2,816 GitHub stars and is actively maintained.

Key Features

• Config-file driven — YAML or JSON configuration defines all users, groups, and policies
• No database required — stateless by default; reads from config files
• Multiple backends — supports config files, LDAP proxy mode, and SQLite
• TOTP and WebAuthn — two-factor authentication support
• Multi-tenant — supports multiple organizations in a single instance
• WireGuard integration — built-in WireGuard key generation for VPN setups
• POSIX schema — supports uidNumber, gidNumber for Linux authentication (nslcd/SSSD)
• Go binary — single binary deployment, cross-platform

Docker Compose Setup

GLauth uses a configuration file mounted into the container. Here is a complete setup:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

version: "3"

services:
  glauth:
    image: glauth/glauth:latest
    container_name: glauth
    restart: unless-stopped
    ports:
      - "389:389"
      - "5555:5555"    # Optional: REST API
    volumes:
      - ./glauth.cfg:/app/glauth.cfg:ro
      - ./data:/config  # For SQLite backend (optional)

volumes:
  data:

GLauth Configuration (YAML)

Create glauth.cfg in the same directory as your compose file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

---
backend:
  datastore: config
  baseDN: "dc=home,dc=lan"

groups:
  - name: admins
    gidnumber: 5501
  - name: developers
    gidnumber: 5502
  - name: services
    gidnumber: 5503

users:
  - name: admin
    uidnumber: 5001
    primarygroup: 5501
    passsha256: "SHA256_HASH_OF_PASSWORD"
    otpsecret: ""
  - name: deployer
    uidnumber: 5002
    primarygroup: 5502
    passsha256: "SHA256_HASH_OF_PASSWORD"
    sshkeys:
      - "ssh-ed25519 AAAA... deployer@server"
  - name: app-service
    uidnumber: 5003
    primarygroup: 5503
    passsha256: "SHA256_HASH_OF_PASSWORD"

frontend:
  listen: 0.0.0.0:389

api:
  listen: 0.0.0.0:5555
  tls: false

Generate password hashes with:

1

echo -n "your-password" | sha256sum | awk '{print $1}'

Traefik Reverse Proxy Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# traefik dynamic config (YAML)
http:
  routers:
    glauth:
      rule: "Host(`ldap.example.com`)"
      service: glauth
      entryPoints:
        - websecure
      tls:
        certResolver: letsencrypt

  services:
    glauth:
      loadBalancer:
        servers:
          - url: "http://glauth:5555"

Feature Comparison: LLDAP vs GLauth

Choosing the Right Tool

Pick LLDAP if:

• You want a visual web interface for managing users and groups
• Your team prefers GUI-based administration over config file editing
• You need PostgreSQL for durability and multi-writer scenarios
• You want built-in password strength policies and TOTP setup flows
• You’re running a homelab or small team with 5-50 users

Pick GLauth if:

• You manage infrastructure with GitOps — config files live in version control
• You need stateless deployments where users are defined in code
• You want WireGuard integration built into your LDAP server
• You need multi-tenant support for multiple organizations
• You prefer the simplicity of a single Go binary with no database dependency
• You’re provisioning ephemeral environments (CI/CD, staging) where config-as-code is the norm

Integration Examples

Authenticating Linux Login via SSSD

Both LLDAP and GLauth support POSIX attributes, enabling Linux machines to authenticate against your LDAP server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Install SSSD LDAP packages
sudo apt install sssd sssd-ldap sssd-tools

# Configure /etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = home.lan

[domain/home.lan]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.home.lan:389
ldap_search_base = dc=home,dc=lan
ldap_tls_reqcert = never
ldap_id_use_start_tls = false
cache_credentials = true

[ldap]
ldap_search_base = dc=home,dc=lan
ldap_user_search_base = ou=people,dc=home,dc=lan
ldap_group_search_base = ou=groups,dc=home,dc=lan

Connecting Gitea to LLDAP

In Gitea’s app.ini:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[oauth2]
ENABLED = true

[service]
ENABLE_CAPTCHA = false

[auth]
# Via Admin panel: Authentication Sources -> Add LDAP (via BindDN)
# Server: ldap://lldap:3890
# Base DN: ou=people,dc=home,dc=lan
# User Filter: (&(objectClass=inetOrgPerson)(|(uid=%s)(mail=%s)))

Connecting Jellyfin to GLauth

Jellyfin supports LDAP authentication via its built-in LDAP plugin:

1
2
3
4

LDAP Server: ldap://glauth:389
Base DN: dc=home,dc=lan
Bind DN: cn=bind,ou=svcaccts,dc=home,dc=lan
User Search Filter: (objectClass=posixAccount)

FAQ

What is the difference between LLDAP and GLauth?

LLDAP provides a web-based user interface with SQLite or PostgreSQL backends, making it ideal for teams that want to manage users visually. GLauth is config-file driven (YAML/JSON) and stateless, making it better suited for infrastructure-as-code workflows and GitOps pipelines. Both support the standard LDAPv3 protocol and POSIX schemas.

Can I migrate from GLauth to LLDAP or vice versa?

Both servers use standard LDAP schemas (inetOrgPerson, posixAccount), so users can be exported via ldapsearch and re-imported. However, GLauth stores passwords as SHA256 hashes while LLDAP uses its own hashing mechanism. You would need to reset passwords or use a migration script that handles password re-hashing.

Do these lightweight LDAP servers support replication?

Neither LLDAP nor GLauth natively supports multi-master replication like OpenLDAP. If you need high availability, place the LDAP server behind a load balancer with a shared PostgreSQL backend (LLDAP) or use a configuration management tool to keep GLauth config files synchronized across instances.

Can I use LLDAP or GLauth with SSH key authentication?

GLauth has built-in SSH key support — you can store public keys in the config file and use them for SSH authentication. LLDAP does not natively store SSH keys, but you can use the ldapssh or sssd integration on the client side to pull keys from LDAP if you add them as custom attributes.

Are LLDAP and GLauth production-ready?

Yes, both are used in production environments. LLDAP is widely deployed in homelabs and small businesses, with over 6,000 GitHub stars and active development. GLauth is used in CI/CD pipelines, edge deployments, and by teams that prefer config-driven infrastructure. Neither is designed for enterprise-scale deployments with thousands of users — for those scenarios, consider OpenLDAP or 389 Directory Server.

How do I backup LLDAP data?

For LLDAP with SQLite, simply backup the /data volume directory. For PostgreSQL, use standard pg_dump commands. GLauth requires no backup if you use config-file mode — your users are defined in version-controlled YAML files. If using GLauth’s SQLite backend, backup the SQLite database file.

Further Reading

If you’re building out a complete authentication infrastructure, consider these related guides from our collection:

• For enterprise-scale directory services, see our OpenLDAP vs 389DS vs FreeIPA guide
• For single sign-on and identity federation, check out Casdoor vs Zitadel vs Authentik
• For managing access across services, our Authentik vs Keycloak vs Authelia comparison covers full identity providers