Better Auth is joining Vercel
better-auth.com
better-auth.com
Most complex open source projects like Linux for example have a lot of contributions by corporations. The GPL kind of forces them to participate in open source, instead of just creating internal forks.
GPL and even LGPL are tricky for libraries though.
Also all the "commercial open source" or COSS seems to lean into that, its a valid strategy to monetize open source, but should be done transparently and being very upfront about its bait-y nature to businesses or enterprises imho
I don't see companies using open source lining up to support the developers. Good for developers to come up with some monetization strategies to keep their software alive.
Talk: https://ben3d.ca/blog/passwordless-login-system
Live Demo: https://passwordless.ben3d.ca
Demo Code: https://github.com/bhouston/passwordless
If you are building a user system with a database already, adding passwordless auth is easy.
But you need something as a backup to passkeys so I choose emailed OTP, but it isn't meant to be the primary way to log in.
https://news.ycombinator.com/item?id=45393382
https://news.ycombinator.com/item?id=45398577
I've said before:
> Vercel is not a problem. Pumping millions of dollars into the JS ecosystem through sponsorships and events to define the development landscape in terms of what helps your bottom line... that's bad.
> What Rauch is doing is the developer equivalent of private equity squeezing, and what's insane is how well it's working.
the team at Vercel has been my biggest inspiration and always reflected many of the reasons we started working on Better Auth. This would allow us to focus more on what made better-auth great in the first place It hasn't even been 2 years since we started but thank you everyone from the open-source community for helping us make an impact in short amount of time. There is a lot to do to improve on open source auth and im really excited to be back focusing full time on building
Congratulations on the acquisition!
We are building auth for developing markets (secure MFA for users without smartphones).
Would love to get your thoughts on the auth landscape.
I'm +254-seven-zero-seven-144992 on WhatsApp.
Cheers!
https://www.cncf.io/blog/2023/04/11/keycloak-joins-cncf-as-a...
(some of those features are enterprise only)
The self-hosted space is another headache. I wasted so much time trying to make smaller self-hosted auth solutions work, since Keycloak has a reputation for being heavyweight.
I looked into the Ory stack extensively trying to actually use it as advertised for self-hosted / open-source auth. It's aggressively gimped and its SSO features are emphatically _not_ open-source and are gated behind licensing, with no way to find out until you're actually running it.
It's also just unfinished. Their "stack" is a lot of cobbled-together Go mixed with incompletely rebranded acquisitions like SAML Jackson (now "Polis"), which they managed to gut so completely it went from a best-in-class OSS library to unusable.
Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".
For Ory, B2B login is a good value differentiator, because it's required by companies selling to other companies meaning they can spend some money on licenses to further develop software.
Ory powers the largest technology providers, and super small solo projects. It's robust, stable, Apache2 licensed. It's the best CIAM tech out there that's free (!!).
In the end, everyone is entitled to their opinion but the "open source can't make money" train is honestly a bottom tier opinion and I'm tired of reading it on HN, probably written by people making $100K+ a year for writing software and using open source daily (without paying a dime).
It's like the people complaining that Wikipedia is collecting too many donations, while they cheer on Apple or Anthropic or whoever raking in billions of dollars.
Somehow, only if it's open source / non profit it's bad to make money. If it's proprietary nobody gives a damn. Says a lot about society.
There is software that is cutting edge and always changing, and those types of products need to be paid for much more than software that is stable.
With a stable product like Auth (which requires only security fixes and minor features), the 'pay per MAU' model employed across Auth companies is unreasonable
A combination of the people and companies using the product for free or selling its support (like RedHat and IBM for KeyCloak) along with an open license allowing it to be offered as a cloud service should be sufficient?
If you want to pay per monthly active user for the rest of your life, up to you.
Vercel have raised multiple rounds, last one was in 2025 and $300m. So we don't know what the VC's are going to demand for revenue targets. https://en.wikipedia.org/wiki/Vercel
I can’t speak for Vercel‘s goals or pricing - but Ory is evidently still open source while many others went other routes!
even the items i mentioned only change every 5 years or so, in my experience. i accept that there will be a lot of work preventing attackers from gaining unauthorized access, but again this feels partially solved by just rejigging the authn flow (rather than username -> password -> totp (leads to password sprays), just do username -> totp -> password)
It's Apache 2.0 and a CNCF incubating project.
Just before I hurl myself at this for several days/weeks -- where were the pain points? I'm usually wary of new projects in this space but OpenFGA looks pretty mature already
(1) The need to write relationships and keep them updated in the permissions database. Often, this requires writing to both the application database and the permissions database, at the same time. On the SpiceDB side, we provide a Postgres FDW [1] to make this easy IF your application data lives in Postgres
(2) Representing complex permissions in ReBAC schema can be a challenge (at first) if you're coming from an ABAC system - you need a slightly different mental model for ReBAC, where (as its name implies), permissions are reachable via the relationships between objects, rather than attributes on objects.
(3) ACL-aware searching: this is a very hard problem in authz in general and gets slightly harder with ReBAC. The separation of the search index and the permissions database makes it harder to integrate and computing permissions, at scale, is incredibly complex. For SpiceDB, we have Materialize to help solve this problem [2].
[1] https://github.com/authzed/spicedb/tree/e9d636d2b58dd9e92c44...
[2] https://authzed.com/docs/authzed/concepts/authzed-materializ...
Disclaimer: I'm CTO and cofounder of AuthZed and we build SpiceDB (https://spicedb.io), the most scalable OSS implementation of Zanzibar
It also really shows its age, imo. The interface is clunky, roles and groups having overlapping responsibilities is confusing, making custom UIs for it makes me feel ancient, etc.
I really can't complain though. There is simply no alternative that's as open atm. It's also not easy to make one ( I tried :( ).
i really loved better-auth’s DX but the nature of their database adapters means it’s relatively easy to switch over to another provider/library
Better Auth is the go-to solution for many people using Nextjs, so it makes sense that Vercel puts some effort in maintaining it.
I have never had issues running Nextjs in regular containers, it is just a good open source solution, I don't see why it would be any different with Better Auth.
Anything that makes it easier for developers to build secure applications is a win!
Best of luck over there!
Glad I decided to roll my own auth rather then using some library. I had a feeling that eventually they will join Vercel.
but to me that’s less risk than our auth getting bought by somebody whose business goals don’t necessarily align with mine.
With current AI your agents probably still will be better with maintaining a fork. Auth libs have pretty limited API surfaces comparing to e.g. ui frameworks.
The choice between rolling your own and third party is already a trade-off. The future uncertainty around third party services without a clear business just tips the scales, it’s not the whole justification.
That goes for protocols as well.
And security-related "build vs. buy" decisions should always include an element of battle-testing. If you have the option to pick an off-the-shelf TLS library rather than implementing your own, both are gonna be full of bugs but at least the former will have already had CVEs filed and fixed. (That's not, btw, an assumption that one likes to write buggy code, but rather, a choice to operate under the assumption that one can always be surprised. Schneier's Law and all).
That said, there comes a point to model your own problem domain, and make sure that your product includes features and components that allow it to meet your information security goals.
I think software engineering has done itself a bit of a disservice by making security seem "scary" (and therefore, something to avoid at all costs) rather than a necessary and boring component of any computer system.
P.S. If anybody wants resources, I'm a big fan of the way that FIPS-199 -> FIPS-200 -> SP 800-53 breaks down security goals, impact levels, and appropriate control measures. You can pick a goal, assess your impact level, and pick something off-the-shelf pretty quickly.
I work in the auth space (for FusionAuth) and we run into plenty of folks that started out rolling auth themselves. Just username and password right? A bit of hashing, salting and leveraging a built-in crypto library.
But then you need to add account recovery. And then MFA. And then registration. And then progressive registration. And then webhook integration. And then passkeys. And then SAML integration. And the delegated SAML setup. And then and then and then.
You're distracted from your core application by feature requests for your login system.
You have lots of options nowadays. Use a library provided by your framework (Rails, Spring, and Django have them), use a tool like Better Auth, use a third party system like FusionAuth or Auth0. But don't build undifferentiated functionality that impacts your user experience.
PS Of course, where I stand depends on where I sit, but I firmly believe that you should not build an auth system the same way you should not build a database.
For an MVP or a prototype, I think it's okay to use an off-the-shelf tool. For something serious that will have long-term legs, I would do it myself. I hear all of your concerns and arguments and agree there are a lot of footguns. But again, having spent the better part of my adult life using and interfacing with these tools, I have an innate understanding of how to model auth correctly (separate it from the user, separate users from an 'org' or 'team' entity, etc).
You said it though, 'it depends' is really the right answer here.
I've heard plenty of stories of folks moving from homegrown auth to a off-the-shelf solution, but that's because I'm in the off-the-shelf auth space.
It'd be super interesting to hear stories of folks who went the other way, and outgrew their service provider's auth.
This is why a lot of SaaS you use these days will come with a "default project" or "default team" that might just be 1:1 with your own person. But injecting that abstraction layer makes it super easy down to the road to allow other individuals to join or participate in the management of those entities.
But the truth is, if you scale up as a company, it will end up costing you more in engineering salaries to re-create and maintain all the auth features you will need to support like @mooreds mentioned above than just using an auth library/vendor in the first place. And if you don't scale up, you are unlikely to push outside of the cheap or free tiers of any auth vendor you do go with, so it's a wash. Every reputable auth vendor has a pretty generous free tier.
It feels scary to go this direction because what happens if you blow up and then it becomes ultra expensive and now you're "locked in". All the time I see developers put hundreds of thousands, or millions of MAU into an auth vendor's pricing calc then gawk over the projected monthly bill and decide to roll their own. But the reality is that this doesn't happen. By the time you have that many MAU, you're typically paying out many multiples of that in engineer salaries alone, and paying an auth vendor a fraction of a single engineer's salary to handle your auth is substantially better value than hiring a team to build and maintain your own from scratch.
We have churned our fair share of large company customers over the years, as has every other auth vendor. They have all been because they needed feature we didn't have, not because the price was too high.
And it's funny this same argument can be said since Sonnet 3.7. But the issues still pop up.