VoidAuth is an open-source, self-hosted single sign-on and user management provider, written in TypeScript under the AGPL-3.0 licence, that places one authentication service in front of the self-hosted applications of homelab operators, self-hosters and small teams.

What it is

VoidAuth is a self-hosted identity and access management service that acts as an OpenID Connect (OIDC) provider, a proxy ForwardAuth endpoint and an LDAP directory server for the applications running behind it. It lives in the Docker and self-hosting ecosystem, distributed as the container image voidauth/voidauth:latest and documented at voidauth.app. The code is TypeScript under AGPL-3.0, and the project shows roughly 2,843 stars, 124 forks and 60 open issues on GitHub, with recent activity in September 2026. Users, groups and service settings are managed from an Admin Panel reached through the sidebar menu.

The problem it solves is the fragmentation of logins across a self-hosted stack. Each application behind a reverse proxy such as Caddy, Traefik or nginx normally carries its own accounts, password reset and sessions, so an operator running a dozen services maintains a dozen sets of credentials. VoidAuth replaces that scattered per-application authentication with a single provider in front of the stack: applications that speak OIDC can delegate login to it, applications that authenticate through a proxy can use ForwardAuth, and applications that expect a directory can read from its LDAP server. Around that core it adds invitation-based user creation, self-registration, secure password reset with email verification, multi-factor authentication, passkeys and passkey-only accounts, and encryption at rest when backed by Postgres or SQLite.

Key capabilities

• An OpenID Connect (OIDC) provider, so applications with native OIDC support can use VoidAuth as their identity source.
• A proxy ForwardAuth endpoint for applications that authenticate through a reverse proxy rather than speaking OIDC directly.
• An LDAP directory server for applications that expect to read users and groups from a directory.
• User and group management through the Admin Panel, reached from the sidebar menu.
• User self-registration and administrator-issued invitations, created on the Invitations page and delivered as invitation links.
• Multi-factor authentication, passkeys and passkey-only accounts.
• Customisable logo, title, theme colour and email templates, plus encryption at rest with a Postgres or SQLite database.

Who uses it and how

• Self-hosters running a reverse proxy such as Caddy, Traefik or nginx in the same Docker Compose stack, who add VoidAuth so the applications behind the proxy no longer issue their own logins.
• Administrators of invite-only deployments, who create users by generating an Invitation and sending the invitation link instead of leaving registration open.
• Households and small teams that want more than a password, using multi-factor authentication or passkey-only accounts.
• Operators who want the user store encrypted at rest, choosing a Postgres database for a fuller deployment or SQLite for a lighter one.

Getting started

Add a voidauth service using the voidauth/voidauth:latest image, plus a voidauth-db service on postgres:18, to a compose.yml; mount ./voidauth/config at /app/config and set the required variables APP_URL, STORAGE_KEY, DB_PASSWORD and DB_HOST before running docker compose up -d. The password reset link for the initial admin account appears in the logs after the first start, retrieved with docker compose logs voidauth.

How it compares

No list of paid products that VoidAuth replaces is included in the facts, and no comparable identity tools are named, so it stands alone in this registry. There is no stated basis for contrasting it with commercial single sign-on services.

When to use it — and when not to

Running VoidAuth means operating more than a single application: the documented deployment expects a Postgres 18 database container, a configuration volume and required environment variables, and the invitation, self-registration and password reset flows depend on email delivery the operator must keep working. Anyone who needs an audited identity provider, or who would rather not run a database alongside their services, should look elsewhere, since the project states that it has not been audited and uses third-party packages for much of its functionality. It is actively monitored through issues and discussions, but it also carries 60 open issues and its application setup guides are largely community driven.

services:
  # ---------------------------------
  # Your reverse-proxy service here:
  # caddy, traefik, nginx, etc.
  # ---------------------------------

  voidauth: 
    image: voidauth/voidauth:latest
    restart: unless-stopped
    volumes:
      - ./voidauth/config:/app/config
    environment:
      # Required environment variables
      # More environment variable options can be found 
      #   on the Getting Started page.
      APP_URL: # required, ex. https://auth.example.com
      STORAGE_KEY: # required
      DB_PASSWORD: # required, same as voidauth-db POSTGRES_PASSWORD
      DB_HOST: voidauth-db # required
    depends_on:
      voidauth-db:
        condition: service_healthy

  voidauth-db:
    image: postgres:18
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: # required, same as voidauth DB_PASSWORD
    volumes:
      - db:/var/lib/postgresql/18/docker
    healthcheck:
      test: "pg_isready -U postgres -h localhost"

volumes:
  db: