The Perils of Outsourcing Authentication: Lessons from Val Town's Migration to Better Auth
Authentication is often viewed as a commodity—a solved problem that can be offloaded to a third-party provider to accelerate development. However, as Val Town's journey from Supabase to Clerk and finally to Better Auth demonstrates, the decision to outsource your identity layer can introduce systemic risks that are difficult to reverse.
For many startups, the allure of "zero-config" authentication is strong. But when the requirements of an application evolve—particularly for social platforms where user data is frequently accessed and displayed—the abstractions provided by managed services can become bottlenecks. This is a detailed look at why Val Town moved away from Clerk and the architectural lessons learned during the process.
The Danger of the "Managed User Table"
One of the most contentious architectural patterns in modern auth services is the suggestion to drop your own users table and let the provider act as the single source of truth. While this simplifies the initial setup, it creates two primary points of failure: reliability and rate limiting.
The Rate-Limit Footgun
When a service manages your user table, every request for user metadata (avatars, emails, settings) must go through their API. Val Town discovered that while this worked seamlessly in development, production reality was different.
"In production, the rate limit for that endpoint was five requests per second. For the whole account, across all users."
For a social website where pages often list content from multiple users, this model is fundamentally broken. To circumvent this, developers are often forced to sync data via webhooks back into their own database, effectively creating two sources of truth and doubling the complexity of user management.
Session Management as a Single Point of Failure
When a provider manages sessions, they aren't just handling the login; they are part of the critical path for every single request that requires authentication. If the provider experiences an outage, users cannot refresh their session cookies, and the entire site becomes unusable—even for those already logged in.
Val Town noted that their site's reliability became the product of the reliability of all its critical parts. As one community member pointed out in the discussion, if your software, auth layer, and cloud provider each have 99% availability, your total availability drops to 97%.
Evaluating the Alternatives
Finding a replacement for a managed service is challenging because the market is often split between "ancient and semi-abandoned" open-source libraries and high-risk vendor lock-in platforms.
Why Better Auth?
Better Auth was selected because it balances the convenience of a library with the sovereignty of self-hosting. Unlike a fully managed service, it allows the developer to maintain control over the database and session management while providing the necessary framework integrations (Remix, Fastify, Express).
Key advantages cited include:
- Reduced Vendor Risk: The system no longer depends on a third party staying online for sessions to function.
- Extensibility: Being open-source and library-based, it is more "hackable" than a closed API.
- Stateless Infrastructure: Better Auth's paid add-ons are largely stateless and uninvolved in the session management path.
The "Roll Your Own" Debate
The migration sparked a wider debate among engineers regarding the age-old mantra: "Never roll your own auth."
While the consensus used to be absolute, many experienced developers now argue that for basic needs—bcrypt passwords, magic links, and session tables in Postgres—the risk of building a simple, internal system is lower than the risk of depending on a complex, obfuscated third-party blob. As one contributor noted, the "happy path" of managed services is great until you deviate from it, at which point the complexity of the provider's internal abstractions becomes a hindrance.
Executing a Zero-Downtime Migration
Moving authentication providers is one of the most high-stakes operations a team can perform. Val Town utilized a transitional period to ensure a smooth handover:
- Parallel Support: For two weeks, every authentication endpoint accepted cookies from both Clerk and Better Auth.
- Gradual Migration: Users were migrated as they signed in, with the sign-in page issuing Better Auth sessions.
- Handwritten Finality: While LLMs helped with the initial boilerplate of the transitional code, the final security-critical implementation was handwritten and rigorously tested to avoid vulnerabilities.
Final Thoughts
The journey from Supabase to Clerk to Better Auth serves as a reminder that the reliability of a complex system is defined by its weakest link. While managed services are excellent for simple, frontend-heavy apps without social components, they can become a liability for platforms that require high availability and deep integration with user data. The most delightful kind of engineering is often the "boring" territory: owning your data, controlling your sessions, and minimizing the number of critical third-party dependencies in your request path.