GLAuth: a Go LDAP server for development, homelabs and CI

The gap GLAuth fills between OpenLDAP and a throwaway test directory

Running a real directory service to test an application is disproportionate. OpenLDAP needs schema files, a slapd configuration and a database backend before the first bind succeeds. Active Directory needs a domain controller. GLAuth's README positions it as a "Lightweight alternative to OpenLDAP and Active Directory for development, or a homelab", and the stated uses are concrete: central account management across Linux servers, macOS machines and support applications such as Jenkins, Apache or Nginx and Graylog2, plus central management of SSH keys and Linux accounts. The intended user is a developer or systems tinkerer who wants name, uid, gid, password hash and SSH key to come from one place, without operating an identity platform. The repository also lists CI as a use case in its description, which matches the shape of the tool: one binary, one config file, no database to provision.

How GLAuth answers a bind: config backends, chained backends and proxying

The mechanism is a backend selection in the config file. The sample declares `datastore = "config"` and `baseDN = "dc=glauth,dc=com"`, then lists users and groups as TOML arrays. Each user carries a name, a uidnumber, a primarygroup and a password field, and the README shows two hash formats side by side: `passsha256` with a hex digest annotated `# dogood`, and `passbcrypt` with a bcrypt value for the same password. SSH keys are attached per user with an `sshkeys` array. Groups are separate entries with a name and a gidnumber, and a user points at a group by number rather than by name, so the group entry has to exist for the reference to mean anything.

For anything larger, the backend can be swapped. The README states that the directory can live in a file, locally or in S3, in a SQL database, or be proxied to existing LDAP servers, and that multiple backends can be chained to inject features. The proxy example is short: `datastore = "ldap"` with a `servers` list of `ldaps://server1:636` and `ldaps://server2:636`. That second mode is the more interesting one. GLAuth in front of an existing directory is not a replacement, it is an interposer, and the README does not document what a chain of backends does when two of them can answer the same query. Treat chaining as the least specified part of the design and read the linked documentation before relying on it.

Installing GLAuth and running your first ldapsearch

The README's quickstart is four steps and explicitly non-production. You download a precompiled binary from the releases page, download the example config `sample-simple.cfg`, start the server pointing at that file with `-c`, and test with a traditional LDAP client. The binary in the example is named `glauth64`.

./glauth64 -c sample-simple.cfg

With the server running, the README's own test command binds as the service account defined in the sample config and searches the base DN for a user named `hackers`. Note the port: 3893, not 389.

ldapsearch -LLL -H ldap://localhost:3893 -D cn=serviceuser,ou=svcaccts,dc=glauth,dc=com -w mysecret -x -bdc=glauth,dc=com cn=hackers

If that returns the entry rather than a connection error, the directory is answering. The README warns in the same step that SSL (TLS) should be set up for production use, and the usage output shows how: `--ldaps <address>`, `--ldaps-cert <cert-file>` and `--ldaps-key <key-file>`. The command line also accepts `-c, --config <file>`, `-K`, `-S` and `-r` for AWS credentials and region when the config lives in S3, with `us-east-1` as the stated default region.

For a container, the repository publishes an image and the README's badge links to Docker Hub pulls for `glauth/glauth`. The README itself does not spell out a `docker run` invocation, so check the image tags on Docker Hub rather than guessing a flag combination.

The config-file backend is the honest limit of this project

A TOML file with users in it is excellent for a test fixture and poor as a source of truth. There is no documented administrative interface: the README describes no web console, no write API and no account management endpoint, and the related searches for a GLAuth UI or web UI have nothing in the repository to land on. Adding a user means editing the file and restarting, and the README does not document a reload signal. Passwords live in the file as SHA-256 or bcrypt hashes, which is the right choice for storage but still means the file is a secret you have to distribute, and the S3 backend moves that secret into bucket access keys.

The proxy backend has the opposite problem. It is only as available as the servers behind it, and the sample lists two `ldaps://` endpoints without documenting failover order or health checking. If you point GLAuth at a directory that is already the authority for your accounts, you have added a process that can fail between your applications and their authentication. That is a reasonable trade for injecting a feature; it is a bad trade if you only wanted a smaller LDAP server and now have two.

GLAuth against OpenLDAP and against lldap

OpenLDAP is the reference implementation, and the difference is operational rather than protocol-level. OpenLDAP gives you a schema you can extend, replication, an access control model and a long history of production deployments, at the cost of a configuration language and a database backend to maintain. GLAuth gives you one config file and a Go binary, and in exchange you accept a narrower feature set and a smaller community.

lldap appears in the same searches, and the contrast is sharper. lldap is a lightweight LDAP server with a web interface, which is exactly the piece GLAuth's README does not describe. If the reason you are looking at a small directory is that you want to click through users and groups in a browser, GLAuth is the wrong tool and lldap is the closer fit. If you want the directory to be a file you generate from Ansible, Puppet or Chef, which the README names as a legitimate production pattern, GLAuth's config backend is the simpler shape. The two projects are not competing on the same axis: one sells administration, the other sells a declarative file.

Licence, releases and what maintenance costs you

GLAuth is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept. That is a permissive licence with no copyleft obligation and no source-disclosure requirement for your own code. It does not grant trademark rights, and the repository's own branding and website are separate from the code licence. This is not legal advice; read the LICENSE file in the repository for the operative text.

The last push to the default branch was on 2026-08-31, and the most recent release is GLAuth-v2.5.2 from 2026-07-25, preceded by v2.5.1 on 2026-07-18 and v2.5.0 on 2026-04-19. Release cadence over that window is regular, and the repository is not archived. The upgrade cost is the part worth weighing: the configuration is TOML, and a breaking change to backend keys or password fields means editing every deployment's config, including the copies baked into CI images. The README also notes that pull requests should target the `dev` branch rather than `master`, so the default branch you clone is not the branch where changes land first. If you vendor a fork, follow `dev` or you will be reading a branch that trails the project's own work.

Editorial conclusion

GLAuth fits developers, homelab operators and CI pipelines that need a throwaway or self-managed directory with a short config file, and it fits teams that want to keep their existing LDAP server but change how it answers. It does not fit anyone who needs a web console, a supported commercial identity product, or production TLS without reading the certificate flags. Before adopting it, verify that your client works against the config-file backend, confirm which datastore value your intended backend uses, and check whether the LDAPS listener and certificate options are configured, because the quickstart runs plaintext and says so.

Frequently asked questions

Official sources

1. glauth/glauth on GitHub
2. Issues
3. License: MIT
4. README
5. Releases