mrkeyoor.com_
Sat 08 Aug 21:03 UTC
Self-Hostedevaluationupdated 08 Aug 2026

pocket-id

Pocket ID is a self-hosted, certified OpenID Connect and OAuth 2.0 provider that lets people sign in to other applications with passkeys. It gives a home lab or smaller organization one passwordless login service without the administrative weight of a large identity platform.

Verdict

Pocket ID is the most appealing small self-hosted identity provider for people who genuinely want passkeys, not merely an easier Keycloak. The interface, certified protocol support, client guides, directory integrations, and hardening options make it credible beyond a demo. Use it for a carefully backed-up single-node deployment today; choose a heavier platform if passwords, complex federation, or proven horizontal scaling are requirements.

Setup4/5Small Compose file, but HTTPS and recovery need real planning
Docs5/5Excellent setup, hardening, recovery, and client-specific guides
Community5/5Current release, same-day pushes, and active contributor traffic
Maturity3/5Certified and capable, with HA and current reliability work ongoing

Who it’s for

  • Self-hosters who want one passkey login across OIDC-compatible services.
  • Small organizations ready to make passkeys their primary authentication method.
  • Operators who need groups, per-client access rules, LDAP import, or SCIM provisioning without adopting Keycloak.
  • Teams able to run an identity service behind dependable HTTPS and maintain tested recovery procedures.

Who it’s NOT for

  • Organizations that must support passwords, social login, or several interchangeable authentication factors: Pocket ID is intentionally centered on passkeys, with recovery codes and an explicitly weaker email option.
  • Deployments requiring finished multi-replica high availability: the active HA tracker still lists signing-key coordination, shared storage, background jobs, and session cleanup work.
  • Operators unwilling to own emergency access: users cannot receive a passkey from an admin, so enrollment and recovery depend on short-lived codes, another enrolled device, or optional email login.
  • Teams that cannot tolerate young identity-server regressions: current reports include SQLite lock crashes, a fail-open API rate limiter on one v2.12 installation, and a v2.13 admin-settings page that does not load in one Kubernetes setup.
  • Anyone without a stable HTTPS hostname: WebAuthn requires a secure context and passkeys are tied to the site where they were created.

Setup reality

The container itself is simple, but an identity provider is never just a container. You need a stable HTTPS URL before WebAuthn works, a reverse proxy with carefully scoped trust settings, a generated encryption key that is backed up separately, persistent database and upload storage, and at least two tested ways to regain administrator access. The supplied Compose file is small and SQLite suits one instance. LDAP, SCIM, PostgreSQL, S3 storage, distroless images, and read-only roots are available, but they raise the operational stakes. The documented export and import feature is experimental, so keep direct storage backups and test a restore before routing important apps through Pocket ID.

A deliberately smaller identity provider

Pocket ID gives self-hosted applications a central login without asking the operator to learn a full enterprise identity suite. It speaks OpenID Connect and OAuth 2.0, has passed OpenID provider certification, and makes passkeys the normal way every user authenticates. Applications redirect to Pocket ID, the user approves with a device, password manager, or hardware key, and the application receives standard identity tokens.

That narrow choice is the product. There is no password database to protect or reset, and a passkey's private material stays on the user's authenticator. Credentials are bound to the Pocket ID site, which makes ordinary phishing much harder. A phone can also approve a five-minute QR login on another device. For a home lab full of OIDC-capable services, this is considerably nicer than maintaining separate passwords.

Passkey-only is both the appeal and the limit

Pocket ID works best when the operator wants to commit to passkeys. A user stores one in a browser, phone, password manager, or security key and unlocks it with the device's own protection. Admins cannot create passkeys for other users, which preserves the security boundary but makes enrollment an operational process. They create a short-lived login code, send it through a trusted channel, and the user registers a credential. Signup tokens can support controlled self-enrollment.

Recovery deserves a written procedure before the first client is connected. An administrator can issue another code from the web interface or command line. Users with an enrolled passkey on another device can approve a QR flow. Email one-time access is optional, but the documentation plainly calls it insecure because control of the mailbox becomes control of the Pocket ID account. If that compromise is unacceptable, disable email login and enroll more than one passkey for administrators. Store a hardware key somewhere safe.

This model will not suit every organization. Users who cannot use WebAuthn, policies that mandate passwords plus a separate second factor, and workflows built around social identity need another product. Pocket ID's simplicity comes from declining those branches, not hiding them behind an easier interface.

Installation is short, trust is not

The recommended Compose file has one service, one environment file, port 1411, and a persistent /app/data mount. Set APP_URL, generate an encryption key, start the container, and create the initial administrator under /setup. A standalone binary is also available. The application itself can be running quickly.

WebAuthn requires a secure browser context, so a real deployment needs HTTPS and a stable hostname. Changing that site later can strand credentials because passkeys are scoped to the relying party. Reverse-proxy trust must be configured narrowly enough that clients cannot forge their address. The environment reference also defaults to allowing insecure callback URLs on non-loopback hosts and recommends setting that option to false unless a client truly needs HTTP. Review the defaults instead of copying the example untouched.

Security-conscious operators get useful choices. A distroless image runs non-root, and the container can use a read-only root filesystem once mount ownership is correct. The normal image starts as root only to prepare permissions, then drops privileges. Offline installations can disable version checks and the daily analytics heartbeat. By default, that heartbeat sends a random instance identifier, version, and timestamps; it can be turned off.

Backups require more caution. The CLI can export and import a ZIP across installations or database providers, but its own guide labels the feature experimental and warns that import erases existing database and upload data. Keep filesystem or database-level backups as the primary safety net, preserve the encryption key, and rehearse recovery on a separate hostname or isolated network.

Directory features without enterprise scale

LDAP sync runs at startup and hourly, bringing users and groups from systems such as OpenLDAP, Active Directory, or LLDAP. Synced records cannot be edited in Pocket ID, which correctly leaves the directory authoritative. An LDAP-first setup needs at least one member in the designated admin group before sync. SCIM works in the other direction, pushing Pocket ID users and groups to supporting client applications on a schedule or after changes.

These features cover a surprisingly useful middle ground, but horizontal scale remains unfinished. The current HA tracking issue still lists coordination for signing keys, LDAP and SCIM jobs, shared filesystem state, WebAuthn and OAuth session expiry, and other cluster-wide tasks. Several foundational items are complete, yet the checklist explicitly retains an HA_ENABLED task. Run one replica unless the project documents otherwise. Keycloak or Authentik is the safer buy when multiple active instances are a hard requirement.

Recent reports also deserve attention because this service sits on every application's front door. One SQLite deployment reports repeated database locks and process exits. A separate v2.12 report says the API rate limiter stayed unavailable and allowed requests through while health checks remained green. After v2.13.0, one PostgreSQL Kubernetes user reported that the application-configuration page stopped loading. These are reports in particular environments, not proof that every instance fails, but they justify monitoring real login and admin flows rather than only /healthz.

Fast development, with the risk that brings

Version 2.13.0 shipped August 7, 2026, and included OAuth token compliance, client session-duration controls, passkey restrictions, and many security and reliability fixes. The repository was pushed again on August 8, while issues and pull requests were active that day. GitHub's open count of 94 combines both types of work. The pace and outside contributions are strong, though the new regression report shows why an identity provider should be upgraded first in a staging copy.

Pocket ID is an excellent fit for a single-node home lab or smaller team committed to passkeys. It earns that recommendation by staying opinionated while still supplying the groups, provisioning, audit, and client guidance needed in real use. Back up the key and data, monitor authentication itself, keep emergency credentials, and wait for the HA checklist if losing one instance is unacceptable.

Alternatives

ProjectWhat it isPick it when
AuthentikA broader self-hosted identity platform with flows, proxies, directories, and many authentication choices.pick this instead when you need flexible login flows, application proxies, or more than a passkey-first OIDC provider.
KeycloakA mature enterprise identity and access-management server with extensive federation and policy controls.pick this instead when enterprise federation, fine-grained administration, and established clustering outweigh setup complexity.
DexA compact OIDC provider that connects applications to existing identity systems through pluggable connectors.pick this instead when an upstream directory or provider should remain the source of user authentication.

What people are saying

  1. [github-trending] pocket-id/pocket-id

Sources

  1. Pocket ID README
  2. Pocket ID installation guide
  3. Pocket ID sign-in methods
  4. Pocket ID data export and import
  5. High availability tracking issue
  6. Pocket ID v2.13.0 release