2026.10.15
VoidAuth: Centralized Login and Identity Management for Self-Hosted Apps
VoidAuth brings OIDC, ForwardAuth, LDAP, user management, and multifactor authentication into a self-hosted identity service. It suits individuals and small teams that want one login layer, but deployment requires attention to AGPL-3.0, email, persistence, and the project’s unaudited status.
What it does
VoidAuth is positioned as an open-source single sign-on, authentication, and user-management provider for self-hosted applications. By centralizing the identity entry point, administrators can manage users, groups, and selected authentication settings in one service, while applications can integrate through OIDC or proxy authentication. It is aimed at people who want fewer separate application accounts and are prepared to operate their own identity infrastructure.
Image source: voidauth. Published by the project; the interface may vary by version.
Known features
The README lists an OpenID Connect provider, Proxy ForwardAuth, and an LDAP directory server, covering several integration patterns for self-hosted software. It also includes user and group management, self-registration, administrator invitations, and customization for the logo, title, theme color, and email templates.
Authentication-related features include multifactor authentication, passkeys, and passkey-only accounts. VoidAuth also provides password reset with email verification. The v1.16.0 release notes report backchannel logout support for supported OIDC applications and changes to MFA behavior around MFA pages and account factors. The practical scope still depends on the target application and configuration; the feature list alone does not establish universal compatibility.
Image source: voidauth. Published by the project; the interface may vary by version.
Who it may suit
VoidAuth may suit administrators running personal clouds, media services, development tools, or other self-hosted sites who want a shared authentication layer. Experience with reverse proxies, domains, databases, email delivery, and secret management will make deployment and maintenance easier. For someone running only one application without a need for centralized identity, adding another service may increase operational overhead.
Deployment considerations
The README recommends Docker Compose and requires values such as the application URL, storage key, database password, and database host. Its example uses PostgreSQL, while the README also states that SQLite is supported. Plan persistent volumes, database backups, upgrade rollback, and secret storage before exposing the service. After the first start, the initial administrator’s password-reset link is written to the container logs. Access to those logs should therefore be treated as sensitive; after signing in, follow the project guidance to change the default username or create a separate account.
If self-registration, invitations, email resets, or MFA are enabled, verify that email delivery, the public domain, and the reverse proxy are configured reliably. The repository uses AGPL-3.0, so organizations should review their own licensing and compliance obligations when integrating, modifying, or offering the software over a network. Most importantly, the README states that the project has not been audited and relies on third-party packages. VoidAuth can be evaluated as a self-hosted identity-service option, but the available sources do not support claims that it has passed a security audit or is appropriate for high-risk environments.
Sources
Sources checked: 2026-10-15