Hanko: an AGPL backend, MIT frontend packages, three artifacts to pin

Three building blocks, one Go service and two npm packages

The repository splits into three pieces that are packaged and versioned apart. `backend/` is a Go authentication API for passwords, passkeys, email passcodes, OAuth SSO, user and session management, and JWT issuing. `frontend/elements/` is the Hanko Elements set of web components covering onboarding, login and user profile, customisable with CSS and published to npm as `@teamhanko/hanko-elements`. `frontend/frontend-sdk/` is the client package those components are built on, published as `@teamhanko/hanko-frontend-sdk`, which handles the communication with the backend API so you do not have to write that client yourself. Around those sit `quickstart/`, an example app that doubles as the reference implementation, `frontend/examples/` for framework-specific builds, and `e2e/`. Because the elements are written for the Hanko API, they are not login widgets you can point at an unrelated provider.

Four named alternatives and no migration guide in the tree

The repository description positions Hanko as an open source alternative to Auth0, Clerk, WorkOS and Stytch, and the summary restates the pitch as API-first, lightweight and cloud-native, with configuration options including passkey-only, OAuth-only and user-deletable passwords. Privacy appears as a design principle rather than a toggle, in the form of data minimalism and phishing resistance. None of that tells you what switching costs. There is no comparison table in the repository, no guide for moving existing sessions or password hashes from the root, and no note about accounts you choose not to import. The closest evidence is a release title: backend/v2.7.0 is named Hanko v2.7: Firebase User and Password Hashes Import, which shows one migration path exists and that it is scoped to a single source system.

The licence changes halfway through the repository

One line splits the project in half. `hanko-elements` and `hanko-frontend-sdk` are under the MIT License, the permissive option most teams want when embedding a widget into a product. Everything else, and the sentence says so explicitly, including the hanko backend, is under AGPL-3.0. The repository's licence field reports AGPL-3.0 for the project as a whole, which is exactly why the per-directory split matters: a scanner that reads one licence field at the root will miss that the two frontend packages are MIT. Non-copyleft commercial licensing is offered on request rather than through a self-serve path, so a team that needs permissive terms for the backend has to start a conversation with the vendor instead of picking a tier, and that conversation belongs in your planning rather than in your integration phase.

Every release tag is prefixed backend/ and named for a version

Look at the three most recent releases and the first thing to notice is the namespace. They are backend/v3.1.0, named Hanko v3.1, published 2026-10-01; backend/v3.0.4, named Hanko v3: Multitenancy, published 2026-07-27; and backend/v2.7.0, named Hanko v2.7: Firebase User and Password Hashes Import, published 2026-06-05. The tag namespace tells you the backend runs its own release line, which is sensible for a Go service, but nothing on the root page pairs a backend version with an elements or SDK version. If you upgrade the service and keep an older `@teamhanko/hanko-frontend-sdk` from npm, there is nothing in the repository that tells you whether the API contract moved underneath you. Pin all three artefacts separately and read each one's own release notes.

Three rows of the feature table carry no delivered mark

The feature table is where Hanko is blunt about its edges, because three rows never get the tick. Organizations, Roles and Permissions carry a gear rather than a check, and the `<hanko-menu>` web component along with the iOS, Android, React Native and Flutter SDKs have no status mark at all, which leaves them ambiguous between planned and in progress. Everything above them is marked delivered: email and username identifiers, passwords, passcodes and passkeys, the Elements web components, OAuth SSO with Apple, Google and GitHub, i18n and custom translations, SAML Enterprise SSO, webhooks, server-side sessions with remote session revocation, MFA through TOTP and security keys, custom OIDC and OAuth connections, and the JS SDK. The consequence for a reader is concrete: a product that needs organizations, roles and permissions cannot count on them from this table, and a mobile client has to reuse the same web components or build its own client.

The Docker door starts the frontend you did not ask for

Two doors lead to a running system and they do not open the same thing. The bare metal route sends you to the `backend/` section for the API, and points at Hanko Cloud if you would rather not host it. The Docker route goes through the quickstart, and the wording there is the catch: it creates everything, including frontend and backend components, not just the service you came for. To keep only the backend you have to edit two files yourself, and both are named in the instructions:

./deploy/docker-compose/quickstart.yaml
./deploy/docker-compose/config.yaml

The first is where you delete the services you do not need, the second is where you change the configuration to meet your needs. So the advertised path is a starting point rather than a finished deployment, and the distance between a demo stack and your own configuration is precisely those two files.

The documentation has already left the repository

The architecture section names a docs directory and then immediately notes that it moved to its own repository at `github.com/teamhanko/docs`, with the live site at docs.hanko.io. That detail matters more than it first appears, because everything you need after the quickstart lives outside the artefact you version: the guides, the API reference and the per-framework integration instructions are all in the other repository. A checkout pinned to a given tag will not contain the guide written for that tag, so you cannot treat the documentation and the code as one release. The root page compensates by linking a hosted live example at example.hanko.io and a passkeys companion site, but both are running deployments rather than files you can read or diff. If your team freezes an old release, expect to locate the matching documentation revision yourself.

Quality gates appear as badges, not as an audit

The repository advertises its checks as five badges rather than as prose, and they name what actually runs: a CodeQL analysis workflow, a `go.yml` workflow, a godoc page, and the two npm package listings. The tree carries the matching governance files, namely SECURITY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md and a .editorconfig. What a badge row cannot tell you is whether any of it ran against the release you are about to deploy, or whether the npm packages pass the same checks as the Go module, since both named workflows are Go tooling and nothing on the page claims otherwise. Static analysis is not a review of your authentication flows and this repository does not present it as one. Read CONTRIBUTING and SECURITY before you file anything upstream, and assume your own assessment still has to cover the deployment configuration.

Editorial conclusion

Hanko suits a team that wants to host its own authentication with passkeys and passwordless options and is prepared to pin three artefacts separately, and it does not suit anyone who needs organizations, roles and permissions, a menu web component or a native mobile SDK today, because the feature table marks none of them as delivered. Before you commit, confirm the licence split is acceptable for your deployment, pin backend, `@teamhanko/hanko-elements` and `@teamhanko/hanko-frontend-sdk` independently, and read the two docker-compose files the quickstart expects you to edit.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. teamhanko/hanko on GitHub