Hanko

Open-source authentication, honestly reviewed. No marketing fluff, just what you get when you ditch Auth0 and run your own auth server.

TL;DR

• What it is: Open-source (AGPL v3) authentication and user management platform — think Auth0 or Clerk, but the source code runs on your server and passkeys are a first-class citizen, not an afterthought [2].
• Who it’s for: Developers and non-technical founders who want a drop-in auth layer with modern passwordless flows — passkeys, OAuth SSO, MFA — without paying Auth0’s per-MAU pricing. Especially relevant for GDPR-sensitive products; the team is European and the infrastructure can stay in the EU [website].
• Cost savings: Auth0 and Clerk pricing scales with monthly active users (MAU). Self-hosted Hanko on a small VPS handles unlimited users at the cost of infrastructure — typically $5–10/mo. Exact comparisons require knowing your MAU count, but the math favors self-hosting past a few thousand active users.
• Key strength: Passkey support is genuinely mature. The pre-built web components (<hanko-auth>, <hanko-profile>) drop into any frontend stack without framework lock-in, and the underlying API is clean enough that custom implementations don’t feel painful [1][2][3].
• Key weakness: AGPL v3 license creates friction for commercial embedding — if you’re building a SaaS and want to distribute Hanko as part of your product, you either need to open-source your own code or get a commercial license [2]. Organizations features (roles, permissions) are still in progress as of this writing [README].

---

What is Hanko

Hanko is an authentication backend. You deploy it alongside your app, and it handles every part of the login flow: user registration, passkeys, passwords, email passcodes, OAuth social logins (Google, Apple, GitHub, and more), SAML SSO for enterprise customers, MFA via TOTP or hardware security keys, session management, and JWT issuance [README][2].

The company pitches it as “an open source alternative to Auth0, Clerk, WorkOS, Stytch” [GitHub]. That framing is accurate. Those are all managed services that charge based on how many users sign into your app. Hanko’s self-hosted community edition has no per-user pricing — you pay for a server, not for your users’ authentication events.

What distinguishes Hanko from older self-hosted auth projects (Keycloak, Authentik, Zitadel) is the deliberate focus on passkeys. While most auth vendors have retrofitted passkey support as a feature toggle, Hanko was built from the start around FIDO2/WebAuthn. The default onboarding flow the team recommends is passwordless with passkeys and email passcodes as a fallback — not the reverse [website]. This isn’t just marketing positioning: the implementation detail that passkeys can sync across a user’s devices via iCloud Keychain, Google Password Manager, or Microsoft accounts means passkey adoption no longer requires a hardware token [3].

The project is backed by a Berlin-based company, sits at 8,873 GitHub stars, and has been running since at least 2022. CEO Felix Magedanz’s stated mission is migrating users away from passwords as the default [2].

---

Why people choose it

The three articles we synthesized cover different angles — developer tutorial, security press coverage, and a framework integration guide — but they converge on the same value proposition.

The passkey experience is legitimately good. Developer Atharva_404, writing about integrating Hanko into an issue tracker app, notes that the pre-built components handle the entire authentication flow without requiring custom WebAuthn code: “Hanko’s intuitive docs and beautifully created inbuilt components made development straightforward” [1]. This matters because implementing WebAuthn from scratch is error-prone. The @github/webauthn-json serialization step, the attestation verification, the credential storage — these are where auth bugs tend to live [3]. Hanko abstracts all of it.

The developer experience is a deliberate differentiator. The HelpNetSecurity profile [2] quotes CEO Magedanz explicitly naming developer experience as a core focus, alongside the clean API design and the framework-agnostic web components. Multiple independent testimonials on the Hanko homepage echo this: “The Hanko Elements workflow on the web is excellent and incredibly easy to integrate with. I’ve used Auth0 & Firebase Authentication in the past, both of them are way more complicated to integrate & understand” [website]. This comparison with Auth0 specifically — a platform developers regularly describe as powerful but dense — comes up unprompted.

GDPR and data sovereignty matter to its audience. The website prominently flags “GDPR compliant, Made & hosted in Europe” [website]. For European founders, or for non-European founders with European customers, this is a real procurement argument. Managed auth services like Auth0 and Clerk run on US infrastructure by default. Self-hosted Hanko can run in Frankfurt, Amsterdam, or wherever your data residency requirements point.

Passkeys as two-factor, not replacement. The Telerik tutorial [3] makes a useful architectural point: passkeys don’t have to replace your existing login system. You can implement them as a second factor layered on top of email-password auth — biometrics (what you are) on top of credentials (what you know). This is a practical path for products that can’t force a full passkey migration on existing users.

---

Features

Based on the README and source articles:

Authentication methods:

• Passwords, email passcodes, passkeys (FIDO2/WebAuthn) [README]
• OAuth SSO: Google, Apple, GitHub, and custom OIDC/OAuth connections [README]
• SAML Enterprise SSO [README]
• MFA via TOTP and hardware security keys [README]
• Configurable stacking: passkey-only, passwords-optional, social-only, or any combination [website]

Frontend components (Hanko Elements):

• <hanko-auth> — full login/registration UI, drop-in, no redirect required [README][website]
• <hanko-profile> — user account management component [README]
• Customizable via CSS; framework-agnostic (Web Components standard) [website]
• i18n and custom translations [README]

Backend / API:

• REST API for all auth flows, session management, user management [README]
• JWT issuance and server-side sessions with remote session revocation [README]
• Webhooks [README]
• JavaScript frontend SDK (@teamhanko/hanko-frontend-sdk) [README]

In progress / upcoming:

• Organizations, roles, and permissions — listed as ⚙️ (in development) in the README [README]
• <hanko-menu> web component [README]
• iOS, Android, React Native, and Flutter SDKs [README]
• Self-serve data migration between cloud and self-hosted [2]

What’s not there yet: Native mobile SDKs are listed as upcoming, not shipped. Organizations/RBAC is in development — meaning right now, if you need to manage teams with role-based access, you’re building that layer yourself or waiting for the feature to ship [README][2].

---

Pricing: SaaS vs self-hosted math

Hanko’s pricing page data wasn’t captured in the provided scrape, so exact tier breakdowns aren’t available here. What is clear from the website and articles:

• Hanko Cloud is a managed hosting option — “Get started for free” is the entry point [website]
• Self-hosted runs on your infrastructure at no software licensing cost, subject to AGPL v3 compliance

For comparison, the services Hanko positions against:

• Auth0: free up to 25,000 MAU, then paid tiers scale per-MAU — well-documented to become expensive past 50K–100K users
• Clerk: free up to 10,000 MAU, Pro at $25/mo base with per-MAU charges above threshold
• WorkOS: usage-based, enterprise-focused, pricing available on request

The self-hosted math is straightforward: a VPS in the $5–10/mo range handles Hanko plus a small Postgres database for most early-stage products. If you’re at 5,000 MAU, the savings versus Auth0 or Clerk managed tiers may be modest. At 50,000+ MAU, the managed-service bills start to compound in ways that make infrastructure ownership increasingly attractive.

One caveat: AGPL v3 means self-hosting is free for internal use and open-source products, but if you’re embedding Hanko inside a closed-source commercial product you distribute to customers, you need to either open-source your product or negotiate a commercial license with the Hanko team [2]. This is a real friction point for SaaS builders.

---

Deployment reality check

The README offers two paths: bare metal (the Go binary) or Docker Compose [README]. The Docker path is the sensible default for most teams.

What you actually need:

• A Linux VPS (2GB RAM is workable for small traffic; 4GB+ recommended as traffic grows)
• Docker and docker-compose
• PostgreSQL (bundled in the default compose or external)
• A domain and reverse proxy for TLS (Caddy or nginx)
• An SMTP provider for email passcode flows

What the developer experience looks like: The tutorials from Atharva_404 [1] and Christian Nwamba [3] both cover framework integration (a React/Next.js frontend talking to a Hanko backend) rather than bare-metal deployment, which suggests the docs are more mature on the integration side than the self-hosting side. Neither article spends time troubleshooting deployment — which could mean it’s smooth, or could mean the tutorial authors used Hanko Cloud rather than self-hosting.

Watch out for:

• The AGPL license. Most developers treat it as “free to use,” which is true for internal tools and open-source projects. It becomes a conversation when your legal team asks whether deploying AGPL software in your SaaS constitutes distribution [2].
• Mobile SDK gaps. If your app is primarily native iOS or Android, the SDK is listed as upcoming, not available. You’d be working against the REST API directly [README].
• Organizations and RBAC are not shipped. If your product needs multi-tenant team management with per-user roles, this is either a blocker or a build-it-yourself problem right now [README].

Realistic setup time for a developer who’s done Docker deployments before: 1–2 hours to a working instance with a custom domain. The quickstart app in the repository is a useful reference implementation to verify your setup against [README].

---

Pros and cons

Pros

• Passkey-first from the ground up. Most auth tools added passkeys as an afterthought. Hanko’s default recommended flow is passkey + email passcode fallback — the product is designed around the assumption that passwords are going away [website][1].
• Drop-in web components. <hanko-auth> and <hanko-profile> are genuine drop-ins that work across React, Vue, Svelte, plain HTML — no framework lock-in [README][website][1]. Multiple independent developers describe this as the smoothest auth integration they’ve done compared to Auth0 and Firebase [website].
• API-first design. The REST API is clean enough that you can skip the web components entirely and build a fully custom auth UI against the same backend. Both paths are supported [README][2].
• GDPR-native. European company, European infrastructure option, built-in data minimalism principles. For EU-focused products, this matters at procurement time [website][2].
• No per-user pricing. Self-hosted means your auth cost doesn’t scale with your user count. This is the most direct financial argument against Auth0 and Clerk [website].
• SAML SSO included. Enterprise customers often require SAML. Hanko has it, which is less common in the open-source auth space [README].

Cons

• AGPL v3 is restrictive for SaaS builders. If you’re building a closed-source SaaS and want to embed Hanko, you need a commercial agreement. This is a real barrier compared to MIT-licensed alternatives [2].
• Organizations/RBAC not shipped. If you need team management with roles and permissions — common for B2B SaaS — this feature is in development, not available [README].
• Mobile SDK gaps. iOS, Android, React Native, Flutter — all listed as upcoming. Native mobile apps are second-class citizens right now [README].
• Smaller community than Auth0/Clerk. The managed-service incumbents have years of documentation, Stack Overflow answers, and integration guides. At 8,873 stars, Hanko is established but not yet ubiquitous — you’ll hit edge cases where you’re on your own.
• Pricing transparency is low. The Hanko Cloud managed offering doesn’t publish a clear pricing page in the scraped content — you get “Get started for free” without the paid tier details visible, which makes it hard to evaluate the managed option honestly.
• Keycloak comparison is unavoidable for enterprise. Keycloak has RBAC, organizations, fine-grained authorization, and 20+ years of battle testing. Hanko wins on developer experience but loses on feature completeness for complex enterprise auth scenarios.

---

Who should use this / who shouldn’t

Use Hanko if:

• You’re building a new web product and want passkeys as the default login experience rather than the opt-in advanced feature.
• You want an auth layer that works with any frontend framework via standard Web Components without redirecting users to an external domain.
• Your product is EU-based or serves EU customers and GDPR compliance is a real concern, not a checkbox.
• You’re comfortable with Docker deployment and want to stop paying per-MAU fees as your user count grows.
• You’re building an open-source product — AGPL doesn’t restrict open-source distribution [2].

Skip it (pick Keycloak) if:

• You need fully mature organizations, roles, fine-grained permissions, and audit logs today — not in the next roadmap cycle.
• You’re running a large enterprise deployment where Keycloak’s decade-plus of production hardening matters more than developer ergonomics.

Skip it (stay on Auth0 or Clerk) if:

• You have fewer than 10,000 MAU and the free tier covers you — the self-hosting overhead isn’t worth it at small scale.
• You’re not comfortable with Docker and don’t have someone who is.
• Your product is primarily native mobile — iOS/Android SDK support isn’t there yet.

Skip it (pick Authentik or Zitadel) if:

• You need RBAC and organizations right now in a fully open-source package without waiting on a roadmap.
• You need finer-grained access control policies that go beyond basic auth.

---

Alternatives worth considering

From the GitHub description and competitive positioning:

• Auth0 — the incumbent. Best documentation, largest ecosystem of integrations and community guides, most expensive at scale. Fully managed, no self-hosting option that matters in practice.
• Clerk — closest competitor on developer experience. Arguably even smoother for React/Next.js. Proprietary SaaS, per-MAU pricing, no self-hosting.
• WorkOS — enterprise-focused, excellent SAML and SSO, expensive, aimed at B2B SaaS selling to large organizations.
• Stytch — developer-first managed auth with good passwordless support. Proprietary SaaS.
• Keycloak — the enterprise-grade open-source option. Mature RBAC, organizations, audit logs. Ugly UI, steep configuration curve, Java-based.
• Authentik — open-source, Python-based, good LDAP and SSO support. More feature-complete on the admin/enterprise side than Hanko, less polished on the passkeys/developer-experience side.
• Zitadel — Go-based, open-source, has organizations and RBAC today. Less passkey-focused than Hanko but more complete for B2B multi-tenant scenarios.

For a non-technical founder building a new consumer or prosumer web app who wants to escape Auth0 pricing: Hanko vs Authentik is the honest comparison. Hanko wins on passkeys and developer experience. Authentik wins on feature completeness.

---

Bottom line

Hanko is the most serious open-source bet on passkeys being the future of authentication. The product is coherent: the default flow is passwordless, the web components are genuinely drop-in, the API is clean, and the European GDPR-native positioning is real rather than marketing. The gaps are also real — no organizations/RBAC yet, no mobile SDKs, and an AGPL license that creates friction for commercial SaaS builders. For a new web product where the founder doesn’t want to think about auth complexity and doesn’t want an Auth0 bill that scales with their growth, Hanko is a compelling choice. For a B2B SaaS that needs team management and role-based access today, wait six months or look at Zitadel.

If deployment is the blocker — setting up Postgres, Docker, a reverse proxy — that’s a one-time problem, not a recurring one. It’s exactly the kind of setup that upready.dev handles for founders who want the infrastructure without the afternoon of command-line work.

---

Sources

1. Atharva_404, dev.to — “Passkeys > Passwords. A complete Hanko Tutorial” (October 19, 2024). https://dev.to/atharva3000/passkeys-passwords-a-complete-hanko-tutorial-p7e
2. Mirko Zorz, Help Net Security — “Hanko: Open-source authentication and user management” (May 19, 2025). https://www.helpnetsecurity.com/2025/05/19/hanko-open-source-authentication-user-management/
3. Christian Nwamba, Telerik Blog — “Passkey Authentication in Next.js Using Hanko” (November 25, 2024). https://www.telerik.com/blogs/passkey-authenticationn-nextjs-using-hanko

Primary sources:

• GitHub repository and README: https://github.com/teamhanko/hanko (8,873 stars, AGPL v3)
• Official website: https://www.hanko.io
• Quickstart and live example: https://example.hanko.io