Firebase Auth, Auth0, and Clerk are all solid products. If you need authentication up and running in an afternoon and you never want to think about it again, any of them will do the job.
But there is a problem none of them will tell you about: you do not own any of them.
Your user data lives on their servers. Their pricing teams decide what you pay next year. Their roadmaps decide what features you get. And if any of them go down, change their terms, or get acquired and rebranded into something unrecognisable, which has already happened with Auth0 and Okta, you are along for the ride whether you like it or not.
That is a problem HVT was built to solve.
What the alternatives actually cost you
Firebase Auth is the easiest to get started with, which is exactly why so many teams default to it. But it is a Google product, closed-source, and there is no self-hosted option. Your user data sits on Google's infrastructure permanently. If you are building anything in fintech, healthtech, or any space where data residency matters, that is a compliance conversation waiting to happen.
Auth0 used to be the serious choice for teams that needed more control. Then Okta acquired it, and the pricing has become infamous enough that "Auth0 pricing shock" is practically a genre of developer blog post at this point. It is powerful, but closed-source and expensive at scale.
Clerk has arguably the best developer experience of the three. The DX is genuinely good. But it is entirely hosted, there is no self-hosting path at all, and the MAU-based pricing model means your auth bill scales against you as your product grows. For non-US teams, data residency is also a real concern.
The pattern across all three is the same: you are renting infrastructure from a company whose priorities are not necessarily yours.
What HVT does differently
HVT is open-source, AGPL v3, and fully self-hostable. You run it on your own infrastructure, your user data never leaves your servers, and because the entire codebase is public, you can audit it, fork it, and modify it.
But self-hosting is not the only differentiator. SuperTokens, Keycloak, and others are also self-hostable. What separates HVT is the access model.
Most auth tools think in terms of users and sessions. HVT thinks in terms of a hierarchy:
Org → Project → API key → Runtime token
You create an organisation. Within it, you create projects. Each project has scoped API keys with explicit permissions. At runtime, those keys exchange for short-lived tokens. Every layer is explicit, auditable, and scoped.
This matters more than it sounds. When your product grows from one service to ten, when you bring on contractors who need access to one project but not others, when you need to rotate credentials without touching your entire auth layer, a flat user-session model becomes a liability. The hierarchy scales with you.
Who HVT is for
HVT is not trying to replace Firebase Auth for the developer spinning up a weekend project. If you need auth in two hours and you will never think about data ownership, Firebase is fine.
HVT is for teams that have been burned before. Developers building in regulated industries. Founders who want infrastructure they actually control. Anyone who has ever had to explain to a client why their user data lives on a third-party server in a country they did not choose.
If that is you, HVT is worth a look
Get started
Live platform: hvts.app
Documentation: docs.hvts.app
GitHub: Star the repo and follow the project, HVT is actively developed and community feedback shapes the roadmap.
If you have questions, run into issues, or want to discuss a specific use case, drop a comment below. Always happy to talk through it.
Top comments (0)