Pocket ID

Self-hosted identity management, honestly reviewed. No marketing fluff, just what you get when you replace your password stack with a Go binary.

TL;DR

• What it is: A lightweight, self-hosted OIDC provider that authenticates users exclusively via passkeys — no passwords, no TOTP codes [README].
• Who it’s for: Homelab operators, indie founders, and small teams who need centralized SSO across their self-hosted services without the operational overhead of Keycloak or Authentik [1][README].
• Cost savings: Auth0 and similar identity-as-a-service platforms charge per monthly active user once you leave the free tier. Pocket ID runs on a $5–10/mo VPS, uses a single Go binary, and has no per-user pricing.
• Key strength: Radically smaller attack surface than alternatives. No password database to breach — only passkeys. The documentation is described as “exceptional — highly detailed and easy to follow” by independent reviewers [1]. Works with any service that speaks OIDC.
• Key weakness: Passkey-only is a hard constraint, not a soft default. If any of your users or integrations expect password-based OIDC flows, Pocket ID cannot help them [README].

---

What is Pocket ID

Pocket ID is a self-hosted OpenID Connect (OIDC) provider built around a single opinionated bet: passwords are the problem, and passkeys are the fix. When a user logs in through Pocket ID, they authenticate with a hardware key (like a YubiKey), Face ID, Touch ID, or any FIDO2-compliant authenticator — and nothing else [README].

The project is explicit about its scope. The GitHub README describes it as “a simple and easy-to-use OIDC provider” and names Keycloak and ORY Hydra as the alternatives it’s positioning against, adding: “they are often too complex for simple use cases” [README]. That’s the whole pitch. It’s not trying to be Keycloak. It ships as a single Go binary, deploys via Docker Compose in under an hour, and exposes a standard OIDC endpoint that any OIDC-compatible application can consume [1][4].

What you get on the other side of that simplicity: any service that supports OIDC — Synology DSM, LXD, Gitea, Proxmox, Nextcloud, Grafana — can delegate authentication to Pocket ID [1][4]. You log into the YubiKey once, and it works everywhere.

As of this review: 7,182 GitHub stars, BSD-2-Clause license, actively maintained [merged profile].

---

Why people choose it

The clearest signal of who reaches for Pocket ID comes from the contexts where it appears in third-party writing.

The blackvoid.club review [1] describes a homelab operator who had already evaluated Authelia and chose not to adopt it — “I eventually chose not to adopt it. All applications running via reverse proxy have some form of authentication (with 2FA added on top), which was more than adequate.” The jump to Pocket ID wasn’t about replacing weak security. It was about replacing friction. Passkeys eliminate the login ceremony across dozens of self-hosted services without adding a password manager dependency or per-service 2FA setup.

William Lam at williamlam.com [3] landed on Pocket ID while building out an identity provider stack for VMware/vCenter environments, putting it in the same evaluation bucket as Authentik, Keycloak, and Synology SSO. The fact that it’s referenced alongside enterprise-grade options for vCenter federation suggests it handles more demanding integrations than homelab toy status would imply.

The Ubuntu LXD documentation team went further: they wrote an official how-to guide making Pocket ID the example OIDC provider for LXD authentication [4]. When a major infrastructure project’s official documentation treats a tool as its canonical example, that’s a credibility signal worth noting.

Versus Keycloak. Keycloak is the default answer to “self-hosted OIDC” and it’s genuinely powerful — SAML, LDAP federation, fine-grained authorization policies, admin consoles. It also requires 2–4GB of RAM for a reasonable setup, takes days to configure correctly, and surfaces XML-era Java UI patterns that haven’t aged well. For a founder who wants Synology and Nextcloud and Gitea to share a login — Keycloak is a cannon aimed at a sparrow [README][1].

Versus Authelia. Authelia solves a different problem: it adds a login portal in front of services that don’t natively support auth, via reverse proxy middleware. It doesn’t expose a full OIDC provider that arbitrary apps can consume natively. The blackvoid reviewer tried Authelia first and moved on specifically because the integration pattern didn’t match their OIDC-native target [1].

Versus Authentik. Authentik is the more direct competitor — it’s also positioned as a user-friendly Keycloak alternative, supports passkeys among other auth methods, and has a polished admin UI. The trade-off: Authentik is substantially more complex (Python stack, multiple services), more configurable, and more appropriate when you need mixed auth methods (passkeys + LDAP + SAML). William Lam evaluated both for the same vCenter use case [3]. Pocket ID wins on simplicity; Authentik wins on flexibility.

---

Features

Based on the README, LXD documentation, and the blackvoid setup guide:

Core identity layer:

• OIDC-compliant authorization server — works with any OIDC client [README][4]
• Passkey-only authentication (FIDO2/WebAuthn) — YubiKey, Face ID, Touch ID [README]
• PKCE support — required for public clients like LXD [4]
• Admin UI served at /setup on first run, /admin thereafter [4]
• Healthcheck endpoint at /healthz [1]

User and group management:

• Manual user creation via admin panel [4]
• LDAP source sync for importing users from an existing directory [4]
• User groups with membership management [4]
• Custom claims: key-value pairs attached to groups, surfaced in the OIDC token [4]
• Per-client “Requires Re-Authentication” option [4]
• Allowed OIDC clients scoped per group — you control which users can access which apps [4]

OIDC client management:

• Multiple OIDC client registrations, each with its own callback URLs and secrets [4]
• Client ID, Issuer URL, and Client Secret visible in admin [4]
• “Show more details” panel in the admin UI [4]

Infrastructure:

• Single Go binary — no JVM, no Python runtime [4]
• Default port: 1411 [1]
• Storage: SQLite (default) or Postgres [1]
• Docker and Docker Compose deployment [1][README]
• Environment-variable configuration: APP_URL, TRUST_PROXY, DB_PROVIDER, DB_CONNECTION_STRING [1]

What it doesn’t do:

• No password fallback. Zero. This is architectural, not a missing feature [README].
• No SAML (OIDC only) [README]
• No built-in MFA beyond the passkey itself (the passkey IS the second factor)
• No workflow automation, user provisioning flows, or identity governance — those belong in a different tier of tool

---

Pricing: SaaS vs self-hosted math

Pocket ID has no SaaS tier and no paid license. It’s BSD-2-Clause open source. The cost is the infrastructure you run it on.

Self-hosted:

• Software: $0 [README]
• VPS: $5–10/mo (Hetzner CX11 or equivalent — the Go binary is light, Postgres adds maybe 512MB)
• Your time: ~30 minutes for a technical user with an existing Docker host [1]

The comparison isn’t against SaaS Keycloak — there isn’t one. The comparison is against identity-as-a-service platforms that do what Pocket ID does (centralized auth for your apps):

• Auth0 free tier: 7,500 monthly active users, but locks features like custom domains and advanced MFA behind paid tiers
• Auth0 Essentials: $23/mo (billed annually) for up to 1,000 MAU — pricing not included in source data, verify current rates before budgeting
• Okta: per-user pricing typically in the $2–15/user/month range — pricing not included in source data, verify before budgeting
• Pocket ID self-hosted: $5–10/mo flat, unlimited users, no per-seat pricing

The math for a 10–50 person team or a homelab with 5–20 services is decisive: a $6 VPS beats any per-MAU pricing model if you’re willing to manage the deployment.

---

Deployment reality check

The blackvoid.club review [1] is the most detailed public account of a real Pocket ID deployment. Their stack: Docker Compose via Portainer, Postgres on a separate container, NGINX reverse proxy, HTTPS. The reviewer describes the documentation as “exceptional — highly detailed and easy to follow” [1].

The LXD documentation [4] confirms the setup pattern: Pocket ID expects HTTPS — “This guide assumes that Pocket ID is available over HTTPS” — which means you need a domain name and a reverse proxy or a Let’s Encrypt cert before the passkeys can function. Passkeys are tied to the origin (domain), so running it on an IP address or over HTTP breaks the browser’s passkey APIs.

What you actually need:

• A Linux server or VPS (512MB–1GB RAM is sufficient for SQLite; 1–2GB if using Postgres)
• Docker and docker-compose
• A domain name with DNS pointing at your server
• A reverse proxy (Caddy or NGINX) handling TLS termination
• Postgres if you want proper durability; SQLite works for small installs [1]

Environment variables to configure (from the Docker Compose example in [1]):

• APP_URL — your public HTTPS URL
• TRUST_PROXY=true — required if behind a reverse proxy
• PUID / PGID — file permission mapping
• DB_PROVIDER and DB_CONNECTION_STRING — for Postgres

What can go sideways:

• Every passkey is domain-bound. If you change your domain after users register passkeys, their credentials stop working. Plan your URL before you start onboarding users [4].
• Passkey support varies by browser/OS. Modern Chrome, Safari, and Firefox on current operating systems work fine. Older Android WebViews or legacy enterprise browsers may not. This isn’t a Pocket ID limitation — it’s WebAuthn platform behavior.
• LDAP sync is available for user import [4], but the depth of LDAP integration isn’t documented in the third-party reviews. If you’re expecting full LDAP federation comparable to Keycloak, verify against the official docs before committing.
• The blackvoid review notes this reached v1.0 “last week” at time of writing [1] — it’s a relatively young project. The 7,182 GitHub stars suggest strong community adoption, but it doesn’t have the multi-year production track record of Authentik or Keycloak.

Realistic time estimate: 30–60 minutes for a developer who has deployed Docker Compose before. 2–4 hours if you’re also setting up a domain, reverse proxy, and Postgres for the first time.

---

Pros and cons

Pros

• Genuinely simple. The README names Keycloak and ORY Hydra as the alternatives it exists to replace — and delivers on that contrast. Single binary, short Docker Compose file, admin UI that doesn’t require reading a 300-page manual [README][1].
• BSD-2-Clause license. Permissive. You can embed it in a commercial product, deploy it for clients, or fork it without restriction [merged profile]. More permissive than Authentik’s BSL-1.1 restrictions.
• Passkeys eliminate the password database. There’s nothing to breach because there’s nothing to store. The security model is hardware-bound cryptographic keys, not hashed strings [README].
• YubiKey support out of the box. One physical key can authenticate across every OIDC-connected service in your stack [README].
• Custom claims for role mapping. You can attach arbitrary key-value data to user groups that downstream apps (like LXD) map to authorization roles — without touching the application’s own user database [4].
• Works with anything OIDC-native. LXD, Synology DSM, Gitea, Grafana, Nextcloud, Proxmox — if it speaks OIDC, Pocket ID can be its identity provider [1][4].
• Documentation quality. The blackvoid reviewer calls it exceptional [1]. That matters for a tool you configure once and then forget about.

Cons

• Passkey-only is a hard wall. Not a configuration option you can toggle off. If any user can’t or won’t use a passkey-capable device, they cannot authenticate [README]. This is fine for a technical homelab; it’s a blocker for a mixed team where some users are on shared workstations or outdated hardware.
• No SAML. If your target application supports SAML but not OIDC (older enterprise software, certain VPN solutions), Pocket ID won’t work. Authentik or Keycloak handles both.
• Young project. Reached v1.0 recently [1]. Limited production case studies compared to Authentik or Keycloak. Bug surface in edge cases is less known.
• No hosted tier. No managed cloud fallback if you don’t want to run infrastructure. Authentik and some others offer cloud options for those willing to pay.
• Limited third-party review coverage. The pool of independent reviews is thin compared to Activepieces, n8n, or other tools in adjacent categories. Most coverage is setup guides, not production usage reports at scale.
• LDAP integration depth unclear. The LXD docs mention LDAP source sync for user import [4], but how robust this is — sync frequency, group mapping, conflict handling — isn’t covered in available third-party reviews.

---

Who should use this / who shouldn’t

Use Pocket ID if:

• You’re running a homelab or a small team stack (5–50 services) and want a single login across everything without managing a password database.
• All your users are technical enough to set up a passkey on their device — or you’re the only user.
• You want OIDC SSO with minimal operational overhead. Your deploy time is measured in minutes, not days.
• You value the BSD-2-Clause license and want to integrate it into a commercial product or deploy it for clients.
• Your security model is “eliminate the password attack surface” rather than “add another factor on top of a password.”

Skip it (pick Authentik instead) if:

• You need both passkeys AND passwords (or TOTP/LDAP auth) in the same identity provider. Authentik supports mixed auth methods.
• You need SAML in addition to OIDC.
• You’re managing a larger organization where you need user provisioning workflows, detailed audit logs, or policy-based access controls.
• You want a more mature project with a longer production track record.

Skip it (pick Keycloak instead) if:

• You’re an enterprise with existing LDAP/Active Directory infrastructure, SAML service providers, and dedicated identity team bandwidth to configure it.
• You need fine-grained authorization policies, client scopes, and the full OIDC + SAML + LDAP federation surface.

Skip it entirely if:

• Any of your users cannot use passkeys (shared device, unsupported hardware, accessibility requirements). There is no fallback.
• Your target application doesn’t support OIDC natively and you can’t add middleware.

---

Alternatives worth considering

• Authentik — the most direct competitor. Supports passkeys plus passwords, TOTP, LDAP, SAML. More complex, more capable, BSL-1.1 licensed. The right choice when you need mixed auth methods or SAML. [Referenced in [3] as an alternative evaluated for the same vCenter use case.]
• Keycloak — the enterprise-grade OIDC/SAML provider. Full-featured, Java-based, resource-hungry, complex to configure. Worth it at 100+ users with existing LDAP infrastructure.
• Authelia — solves a different problem: adds a login portal in front of apps via reverse proxy middleware, rather than acting as a native OIDC provider. Good for protecting services that have no auth; not a Pocket ID replacement [1].
• Zitadel — modern OIDC/SAML provider, actively developed, enterprise features. William Lam evaluated it alongside Pocket ID for vCenter federation [2][3]. More complex setup (TLS configuration took trial and error per [2]).
• Kanidm — Rust-based identity management, strong security design, also passkey-native. Less mature ecosystem, smaller community.
• Dex — CNCF project, connector-based architecture, primarily useful as a federation layer rather than an end-user facing IdP.

For a non-technical founder or homelab operator evaluating passkey-native SSO, the realistic shortlist is Pocket ID vs Authentik. Pick Pocket ID if you want simplicity and a hard passkey-only constraint. Pick Authentik if you need flexibility.

---

Bottom line

Pocket ID is a sharp tool with a narrow edge. It solves one problem — centralized, passkey-based SSO across OIDC-compatible services — and solves it well. The BSD-2-Clause license is genuinely permissive, the deployment is as close to painless as self-hosted identity gets, and the security model (no passwords, no breach surface) is more defensible than the alternatives. The constraint is real: passkey-only means everyone in your stack needs passkey-capable hardware and willingness to use it. That’s the right trade-off for a homelab or a technical team. It’s a blocker for a mixed environment where some users are on legacy hardware or shared workstations. If your situation fits the constraint, Pocket ID removes a layer of operational complexity that most self-hosters accept as inevitable.

If deploying it is the blocker, upready.dev handles one-time self-hosted deployments for exactly this kind of tool.

---

Sources

1. Luka Manestar, blackvoid.club — “Pocket ID - passkey OIDC provider”. https://www.blackvoid.club/pocket-id-passkey-oidc-provider/
2. Ubuntu LXD Documentation — “How to configure Pocket ID as login method for LXD” (LXD 6.7 docs). https://documentation.ubuntu.com/lxd/latest/howto/oidc_pocket_id/
3. William Lam, williamlam.com — “vCenter Server Identity Federation with Zitadel” (references Pocket ID in series on self-hosted identity providers). https://williamlam.com/2025/04/vcenter-server-identity-federation-with-zitadel.html

Primary sources:

• GitHub repository and README: https://github.com/pocket-id/pocket-id (7,182 stars, BSD-2-Clause license)
• Official website: https://pocket-id.org
• Documentation: https://docs.pocket-id.org