GL

GLAuth

Lightweight LDAP server for developers and small setups

Identity & SSO ★ 2.9k stars Easy setup MIT

GLAuth is a secure, easy-to-use LDAP server that reads users and groups from simple config files or backends. It provides LDAP authentication for applications without the complexity of OpenLDAP.

Key features

  • Config-file driven LDAP
  • Pluggable backends
  • Tiny footprint
  • Easy to deploy

Pros & cons

Strengths

  • Very simple to run
  • Great for homelabs

Trade-offs

  • Not a full directory
  • Limited write support

GLAuth replaces

Last reviewed Sep 13, 2026 · 883 words

[ldap]
  enabled = true
  listen = "0.0.0.0:3893"

[backend]
  datastore = "config"
  baseDN = "dc=home,dc=lan"

[[users]]
  name = "svc-bind"
  uidnumber = 5000
  primarygroup = 5500
  passsha256 = "057ba03d6c44104863dc7361fe4578965d1887360f90a0895882e58a6248fc86"
  [[users.capabilities]]
    action = "search"
    object = "*"

[[users]]
  name = "aidan"
  uidnumber = 5001
  primarygroup = 5501
  mail = "[email protected]"
  passsha256 = "057ba03d6c44104863dc7361fe4578965d1887360f90a0895882e58a6248fc86"

[[groups]]
  name = "svcaccts"
  gidnumber = 5500

[[groups]]
  name = "users"
  gidnumber = 5501

That file is a complete LDAP directory. Run glauth -c config.cfg, point Jellyfin, Gitea, Grafana or Nextcloud at port 3893 with bind DN cn=svc-bind,ou=svcaccts,dc=home,dc=lan, and every app on the box shares one set of accounts. GLAuth is a single Go binary, uses tens of megabytes of RAM, and has no web interface, no schema editor and, with this backend, no way for a user to change their own password. Whether that last sentence is a limitation or the entire appeal decides whether you should run it.

The config file is the directory

Everything OpenLDAP makes you learn (schemas, LDIF, slapd.conf versus cn=config, ACL syntax) is replaced by TOML. Users have a name, numeric IDs, a primary group, optional extra groups, a mail attribute and a password hash. passsha256 takes the output of echo -n password | sha256sum; passbcrypt is the stronger option and what I would use for anything internet-facing. Per-user otpsecret enables TOTP by appending the six-digit code to the password, which is the cheapest 2FA you will ever add to an app that only speaks LDAP.

Capabilities are the access control model. A user with no capabilities can bind and read themselves; the search capability above turns svc-bind into the service account other apps use to look people up. That is the whole ACL system, and for a homelab it is enough.

Changes take effect on restart, or on the fly when GLAuth is configured to watch the file. The catalogue's Easy rating is accurate, and the GLAuth quick start is short.

What apps get out of it

The reason to run any LDAP server at home is that a large fraction of self-hosted software understands LDAP and nothing more modern. Jellyfin's LDAP plugin, Gitea and Forgejo, Grafana, Nextcloud, Portainer, Proxmox, Jenkins, Home Assistant through a proxy, and most NAS operating systems will authenticate against GLAuth without knowing it is not OpenLDAP. One user list, one password, group membership mapped to app roles: users for everyone, an admins group for the people who get elevated rights.

Deployment is a container with the config mounted read-only:

services:
  glauth:
    image: glauth/glauth:latest
    ports:
      - "3893:3893"
    volumes:
      - ./config.cfg:/app/config/config.cfg:ro
    restart: unless-stopped

Port 3894 serves LDAPS if you enable it with a certificate, and port 5555 exposes a Prometheus metrics endpoint. On a LAN or a VPN, plain 3893 inside Docker networking is fine; across anything else, enable LDAPS or tunnel it.

Where it stops: no UI, no self-service, limited writes

Adding a user means editing a file and restarting. Users cannot change their own password. There is no admin console, no password reset email, and no audit log beyond stdout. The config backend is read-only by design; the database backends (SQLite, MySQL, Postgres) accept some writes, and a plugin can proxy to a real LDAP server, but the catalogue's "limited write support" con is an accurate description of the project's intent, not a missing feature that will land next release. GLAuth is a directory for a handful of people managed by one operator, with uidnumber assigned by hand.

lldap, Authentik and Keycloak are the bigger siblings

lldap is the closer rival and the safer pick for most homelabs: still small, still LDAP-only, but with a web UI for managing users and groups, self-service password change, and a larger community. If the people using your services are not you, lldap's UI pays for itself the first time someone forgets a password. Authentik is the full identity provider with OIDC, SAML and an LDAP outpost, at the cost of several containers and around 1 GB of RAM; the SSO with Authentik and Authelia guide covers when that jump is worth it. Keycloak is the enterprise option and overkill for anything under a small company. The identity category has the full range.

GLAuth wins on exactly one axis, and it is a strong one: it is the least software that can answer an LDAP bind. If you version your homelab in git and treat user accounts as configuration, a TOML file that ships with the rest of your compose repository is the correct shape.

What I'd do

For a household of one operator and fewer than 10 accounts, run GLAuth from a git-tracked config with bcrypt hashes and a dedicated bind user, put every LDAP-capable app on it, and enable TOTP for the admin account. The moment someone who is not you needs to reset a password, migrate to lldap; the moment you want single sign-on rather than shared passwords, go to Authentik and keep GLAuth only if something still needs a raw LDAP bind. Until then, 64 MB and one file is hard to argue with.

Compare GLAuth

2 head-to-head comparisons.

Similar identity & sso apps