Something interesting happened on Hacker News this week. Val Town, the popular JavaScript runtime platform, published a detailed post-mortem of their authentication journey — from Supabase to Clerk, and finally to Better Auth. Their story is not unique. Across the industry, development teams are quietly dismantling their third-party authentication stacks and bringing identity management back under their own roof.
It is a trend worth paying attention to, because authentication is arguably the most critical piece of infrastructure in any web application. And the way teams handle it is changing fast.
TL;DR
- Development teams are increasingly migrating from managed auth providers (Auth0, Clerk) to self-hosted, open-source alternatives like Better Auth, Stack Auth, and Hanko.
- Key drivers include cost at scale, vendor lock-in, single points of failure, and data sovereignty requirements under the EU AI Act and GDPR.
- Val Town’s public migration from Clerk to Better Auth highlights real-world pain points: rate limiting, outages that cascade to your entire application, and fragmented user data.
- The open-source auth ecosystem in 2026 is mature enough to handle enterprise requirements including MFA, passkeys, multi-tenancy, and social sign-on.
- The right choice depends on your team’s size, compliance needs, and appetite for infrastructure ownership — there is no universal answer.
What Went Wrong with Managed Auth
Managed authentication providers like Auth0 (now Okta) and Clerk promised to solve one of web development’s most tedious problems: never build auth yourself. For years, that advice was sound. Rolling your own authentication meant rolling your own security vulnerabilities.
But as applications matured, cracks appeared. Val Town’s experience with Clerk is instructive. Their application — a social platform where users share and remix code — needed to display user profiles frequently. Clerk’s API rate limit for user lookups was five requests per second across their entire account. For a social platform, that is not a limitation; it is a showstopper.
Worse still, Clerk’s architecture meant that session management depended entirely on Clerk’s uptime. When Clerk experienced outages — and they did — Val Town’s entire application went down with it. As their engineering lead Tom MacWright put it bluntly: “If Clerk goes down, the whole website goes down.”
This is not a Clerk-specific problem. It is an architectural pattern problem. When you delegate your authentication to an external service, you are accepting that your application’s availability is bounded by theirs.
The Cost Curve That Bites
Then there is pricing. Auth0 and Clerk both charge per monthly active user. At early stages, this is negligible — often free. But SaaS pricing has a way of compounding quietly.
A startup with 10,000 monthly active users might pay a few hundred pounds per month. At 100,000 users, you are looking at several thousand. At scale, authentication becomes one of your largest line items — for a service that, conceptually, checks whether a password hash matches a stored value.
Since Okta acquired Auth0 in 2021, pricing has drifted upward. Teams that built on Auth0’s generous free tier five years ago now face enterprise-tier invoices. And migrating away from a deeply integrated auth provider is one of the most painful refactoring exercises in web development — which is, of course, exactly why vendor lock-in works.
The Open-Source Auth Renaissance
What has changed in 2026 is the maturity of the alternatives. Self-hosted authentication is no longer synonymous with “roll your own and pray.” The ecosystem now offers battle-tested, feature-complete options:
Better Auth has emerged as the TypeScript community’s favourite. Framework-agnostic, MIT-licensed, and plugin-based, it supports everything from basic email/password to passkeys, MFA, multi-tenant organisations, and social sign-on. Val Town’s migration was measured in weeks, not months.
Stack Auth positions itself as a direct Auth0/Clerk replacement with an open-source core (MIT + AGPL). It offers a managed dashboard with the option to self-host and export your data at any time — a crucial escape hatch that proprietary providers simply do not offer.
Hanko takes a passkey-first approach, aligning with the passwordless future we wrote about earlier this year. Its architecture is built around WebAuthn from the ground up, rather than bolting passkeys onto a password-centric system.
For enterprise deployments, Keycloak remains the heavyweight — battle-tested, SAML and OIDC compliant, and backed by Red Hat. And newer entrants like Authentik and SuperTokens fill the middle ground between developer experience and enterprise feature sets.
Why Now? The Convergence of Three Forces
1. Data Sovereignty Is No Longer Optional
GDPR was the first wave. The EU AI Act, with its transparency and data governance requirements taking effect in 2026, is the second. When your authentication provider stores user identity data on infrastructure you do not control — potentially in a jurisdiction you did not choose — compliance becomes a conversation with your legal team, not just your engineering team.
Self-hosted auth puts identity data exactly where your compliance framework says it should be.
2. The AI Agent Identity Problem
As we explored in our piece on AI agent identity, applications increasingly need to authenticate not just humans but autonomous agents. Most managed auth providers were built for human users clicking “Sign in with Google.” They were not designed for machine-to-machine authentication, scoped agent permissions, or JIT-provisioned service identities.
Self-hosted solutions give teams the flexibility to extend their identity layer for these new requirements without waiting for a vendor’s product roadmap to catch up.
3. Infrastructure Maturity
Containerisation, infrastructure-as-code, and managed databases have made self-hosting dramatically less painful than it was five years ago. Deploying Keycloak on Kubernetes or Better Auth on a Railway instance is a morning’s work, not a quarter-long project. The operational burden that once justified managed providers has shrunk considerably.
When Managed Auth Still Makes Sense
This is not a blanket recommendation to rip out your Auth0 integration tomorrow. Managed providers still earn their keep in specific scenarios:
- Early-stage startups with small teams and no dedicated infrastructure engineer should prioritise shipping features over managing auth infrastructure.
- Applications with simple auth requirements — email/password plus one or two social providers — may never hit the pain points that drove Val Town’s migration.
- Teams without security expertise should think carefully before taking ownership of credential storage. A well-maintained managed provider is more secure than a poorly maintained self-hosted one.
The decision is not ideological. It is architectural. At what scale does the cost, risk, and inflexibility of a managed provider outweigh the operational overhead of running your own?
A Practical Migration Checklist
If your team is considering the move, here is what we advise based on migrations we have helped clients execute:
- Audit your current provider’s integration depth. How many services depend on it? Is session management coupled to your provider’s uptime?
- Map your feature requirements. MFA, passkeys, SAML/OIDC federation, multi-tenancy, social sign-on — list what you actually use versus what you are paying for.
- Run the new stack in parallel. Migrate a non-critical internal tool first. Validate session handling, token refresh, and edge cases before touching production.
- Plan the user migration carefully. Password hashes may not be exportable from your current provider. Plan for a “re-authentication” flow or progressive migration.
- Budget for the operational commitment. Self-hosted means you own uptime, patching, and incident response. Ensure your team is genuinely ready for that responsibility.
Where This Is Heading
The auth landscape is following a familiar pattern in software: managed services dominate during a technology’s early years, then open-source alternatives mature and teams reclaim control. We saw it with databases (RDS to self-managed Postgres), with CMS (WordPress.com to headless self-hosted), and with CI/CD (hosted to self-hosted runners).
Authentication is now in that transition. The tools are ready. The economic incentives are aligned. And the regulatory environment is pushing teams toward data sovereignty whether they planned for it or not.
For development teams building in 2026, the question is no longer whether self-hosted auth is viable — it is whether your current managed provider is still the right trade-off for your stage, scale, and compliance requirements.
If you are wrestling with that question, or planning a migration and want to avoid the pitfalls, get in touch. Our team has deep experience building and migrating authentication systems across SaaS platforms, and we would be happy to help you navigate the options.
📷 Photo by Dan Nelson on Unsplash
