Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data

Hey, Bereket from Better Auth here. I started Better Auth to solve this exact issue for myself, and it later turned into a company. It always give me joy to just see others getting the same value from it :) There is a lot to work on, would love to know what we can improve

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth.

Knowing every single line of code involved allowed me to add some location-based functionality for one client, provide tailored logging to meet the needs of another client, and my favorite was winning a deal against much bigger competitors by being able to integrate with an absolutely ancient legacy system.

Just like “Goto considered harmful”, DRY, YAGNI, etc - they’re great at making you slow down and think. But they’re not inviolable.

I enjoyed the Supabase migration article from a while ago (https://blog.val.town/blog/migrating-from-supabase) as well. There's a shortage of good, honest writing on long-term engineering decisions, please keep up the blog!

> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.

It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.

That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.

Notable that in each step, there’s an added abstraction; specifically, an authentication abstraction is the hardest one to reverse.

Using a passwordless login from scratch (magic link + Google OAuth2, sessions stored in Postgres without an external auth vendor) gets us around that altogether. The fears about why one would avoid it are generally not justified. Deliverability is the only true problem. Address that, with a proper provider for transactions, and we’re in boring territory – which is the most delightful kind.

To move from Clerk to Better Auth is logical if the choice is between sovereignty and convenience. It’s the core problem that any group doesn’t want to confront right away: “How much of this am I truly willing to own?”

The auth migration cycle is the startup version of moving apartments. You swear each time will be the last, you lose stuff in the transition, and somehow the new place has the exact same problems as the old one but in different rooms.

This is why I'm so thankful I went with Lucia early. They sort of sunset their library and replaced it with documentation (and some small utilities) for how to manage and host authentication for yourself. It's always presented as some big, scary thing you can't manage yourself, but I found that taking the week to learn how security and basic salting works, I was able to feel more confident about how everything worked.

I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."

> And reluctantly I have to hand it to the LLMs here: with the augmentation of the robots, we were able to take the more complex route of supporting both Better Auth and Clerk for a transitional period of two weeks. Every endpoint that handled authentication would accept either kind of cookie, and users slowly moved over to Better Auth because that was the kind of session that the sign-in page provided. Like anything related to security, close reading, rewriting, and testing of all of the code was necessary to make sure we didn't self-own, and the eventual pure-Better Auth auth was handwritten entirely.

just beautiful. nothing to add, clap clap

Feels like auth is either “this took 2 hours” or “this consumed half the company for 3 years”, with basically no middle ground.

Better Auth has been a huge time saver for me. Clerk's pricing got a bit out of hand for side projects.

This sounds like moving the problem, not solving it. I've been doing server based systems since forever and sso is this big complicated topic where people seem to bias to using either really complicated and convoluted enterprise solutions or some walled garden with lots of limitations.

In both cases you are buying into somebody else's solution. That complex framework is complex because the company behind it threw everything and the kitchen sink at it. You don't actually need most of what it needs. And that company makes money by adding more crap to it, via certification, training and consulting. It's complex by design. You can't just sit down and use it. You have to study it first. Become an expert in using it. If you've ever used Keycloak, Spring Security, or similarly convoluted solutions, you know what I'm talking about.

And then that walled garden thing (auth0 or whatever is in fashion these days) is super simple to use. Just do magic steps 1 2 and 3 and you are good to go. But don't deviate from the happy path! There is a happy path. Either you are a perfect match for it or you aren't.

The middle ground is realizing that a users table with a bcrypt encrypted password column and a few other bits and bobs isn't all that hard. Building some sane flows around resetting passwords, 2FA, emailing login links, etc. Easy.

You can actually vibe code most of this stuff these days. And I've done all this manually in the past as well. I've implemented SSO, Oauth (1 & 2), OpenID Connect, etc. I've implemented API call counting, rate limiting, 2FA, etc. I use some frameworks for most of the heavy lifting and dealing with hashing, JWTs, and all the rest. Most of the rest is just simple API plumbing. Most of these flows aren't all that complex. You need good tests and a good understanding of what the system is supposed to do. But that's a constant in this space. Trying to use somebody else's really complicated solution without that is not going to be easier, better, or faster.

You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.

Had a similar journey recently. Started with Stack Auth, found it unusable in production due to extremely hard rate limits and bad performance even when not rate limited. Switched to WorkOS AuthKit, which works much better and supports useful enterprise features. But inclined to BetterAuth for new projects.

- Syncing external auth provider state with your user state is a bug center. It helps to keep as little state as possible in the auth provider, but there is still some. - Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth. - WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it.

Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.

I've recently switched from Clerk to BetterAuth as well and it's really good and definitely would recommend to anyone. It supports more things I need, it's more reliable, and much cheaper.

The reason why it work for me is that it's finally a open-source solution that is on par or better with commercial. When I've selected Clerk originally the reason was that there wasn't open-source alternative, and I won't roll my own auth, I'm not suicidal. But now? I really don't see a single reason why I would pick Clerk, Auth0, Kinde, ...

> There is no val associated with this domain

Using Clerk, quite unhappy with it. No proper RBAC (roles are tied to organizations, not stored on user itself, so you cannot have a concept of global admin or something like that, unless you use metadata for storing arbitrary key value paris), and more than once in the past weeks/months it had a downtime causing the whole app to fail.

Would think twice before using it in the future.

Tom's articles are always a good read.

Anyone remember Auth0 and passportjs?

The churn of auth services is never ending, but I suppose so are the standards.

> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.

More like "its failures are the total of its critical components' failures" when you've got two nines on your least reliable component so most likely any critical component failure will be exclusive.

Super validating, as someone who was recently tempted to use Supabase for a project and decided to give Better Auth a shot instead. It's really made things super simple so far to the point I was semi-worried I'd missed a crucial step. But nope, they just thought of everything.

what do you get from Better Auth btw? When I used it last year, I still found it lacking and it seemed to be run by one guy.

Better auth is great! I love how it's way more hackable than using a something like Clerk. We were able to add a plugin to allow auth via iframe postMessage (embedded in a CRM) and everything worked seamlessly.

Does Better Auth still have the weird design to be everything “request header based”? I remember running admin scripts and tests to be very hacky due to it cause if you skipped that plugins wouldn’t run

My biggest question, that I didn’t see answered, is how the transition comes to an end. If creds aren’t in your system, how well do they transfer? Does it require user involvement? What if they don’t fast enough? What about complex integrations like SSO, SCIM, and passkeys (which are domain scoped)?

If anything I feel like Clerk adoption is becoming the norm in recent years. I started using it about a year ago and found it to have troublesome reliability.

I've been through the exact same migration path and I'm so incredibly happy with Better Auth. Good reminder that I should contribute: https://better-auth.com/docs/reference/contributing

I've had good experience with authelia. Simple and light to self host.

I can never imagine putting my user table on a vendor locked cloud provider. And we use Open Iddict.

Recently went with a vendor of an agentic observability and evaluation product built on Supabase and Clerk. The number of vulnerabilities and CVE’s and outright… I don’t even know the words, coming from this stack is staggering.

Be very very wary of any vendor selling something built on this Supabase + Clerk stack. That alone is a very strong indicator they do not understand basic security or data protection.

> Some important context is that Clerk is a major success. They just raised 50 million dollars and they have lots of satisfied users.

And even more users who are looking to escape. Clerk is just a mess. They are trying to cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering the browser inspectors for being slow to load.

Every time when we upgraded React, Clerk libraries were the biggest pain with their transitive dependencies. We had issues with Stripe libraries with conflicting versions, etc.

And forget about debugging it. The libraries are obfuscated, and the TS code is impenetrable mess of abstractions to support "isomorphic" code that can run transparently on the frontend and backend.

And their platform itself is lacking important functionality, like freaking audit logs and versioning. Somebody (probably) accidentally changed a setting in their console, and we couldn't trace back when it happened or who did it.

Edit: oh yeah, and don't forget their unreliability. I had to wake up on Sunday to deal with Clerk failing the API calls for token refreshes last week.

When is the Better Auth to WorkOS to Vanilla Auth post coming

in rails I just authentication-zero.

no need for 3rd party provider.

Has anyone used Keycloak for actual production? I have often thought about it but I stick to Auth0 just because I don't know if Keycloak has a good track record?

If you're in Elixir-land, I've put together a few packages to help migrating from Supabase (or other stacks):

- https://github.com/agoodway/introspex (generate Ecto Schemas from postgres tables)

- https://github.com/agoodway/pgrest (Supabase/PostgREST compatible query engine)

I also found this helpful in the migration: https://github.com/supabase-community/supabase-ex

Nothing for auth, I basically did a one-off script for that. Phoenix auth stuff that comes out of the box is great.

I've just stuck with Auth0 for years now.

Easy to use and high reliability. Some of these other providers are not the best at reliability.

[dead]

[flagged]

[dead]

[dead]

The homepage of val.town says "Zapier for know-code engineers".. Is KNOW-code engineer a term?

Never outsource your auth no matter what unless you're vibe coding and it doesn't matter. If that's the case, don't put auth in at all because it's just you anyway or just use vibe coded password lookups from database at that point.

Lastly - here's the law of mother nature:

Software funded by VCs will milk you and will milk you dry. Not now, not tomorrow maybe decade or two later when the hot potato being passed around reaches to the last party holding the bag that now needs its money back with all that others had their 10x returns already taken from them by soldng them at an inflated price to the last party holding the bag.

Clerk's pricing should be evidence enough.