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
SkyPuncher 13 minutes ago [-]
It’s just a few fields until it’s not.
SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.
For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
therealpygon 41 minutes ago [-]
Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases.
To expand a bit more: if a business is faced with a choice to save some money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.
That’s the SaaS value proposition.
pietz 26 minutes ago [-]
This comment is more ridiculous than ever in 2026.
notatoad 31 minutes ago [-]
>that doesn’t mean it’s the best use of your time in all cases
Okay, so… what are those cases? I’m also curious.
elevation 54 seconds ago [-]
> Okay, so… what are those cases? I’m also curious.
If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.
If you're not threatened by per-user-per-month fees, you can delegate auth.
If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)
If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.
eddythompson80 48 minutes ago [-]
Don't you wanna level up your career to become an architect? You can draw a box, call it "User Management" and slap "Clerk" or some other SaaS on it, and assume it's managed for you. This allows you to shove whatever requirements you want in that magic blackbox as you feel "it doesn't bring value" for you to implement.
oompydoompy74 49 minutes ago [-]
BetterAuth is users in your own database. So you don’t have to!
normie3000 46 minutes ago [-]
AuthN is hard and generic, authZ is easy and specific. Offload authN, and keep your users table in your Hetzner.
mvkel 49 minutes ago [-]
Start any greenfield project, hand-coded auth takes up 50% of the development time of the entire MVP
awestroke 40 minutes ago [-]
It takes like an hour. So that's a quick mvp then
transitorykris 36 minutes ago [-]
Social logins, email logins, password resets, multi-tenant, organizations, many to many users to organizations, etc etc. Not necessary for MVP, but can definitely be painful hacking in later if the MVP hits.
koliber 27 minutes ago [-]
What you are talking about is in a large part authentication. You can do authentication using an external service and still have your user table locally. You can also do authorization locally with a local session table while leaving authentication to a SaaS.
RedShift1 17 minutes ago [-]
By the time you're so big you need all of that, there will be other people at the table to "hack that in".
SkyPuncher 13 minutes ago [-]
I strongly disagree. If you’re selling to other businesses, much of that is an expectation.
bekacru 2 hours ago [-]
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
behailu 2 minutes ago [-]
Hey hey! Qq: you guys plan to support Python backends or is there a way for us to do this?
rbbydotdev 2 hours ago [-]
Do you think the complexity of auth in the browser, is because browsers don't do enough?
pc86 12 minutes ago [-]
Not who you're replying to but browsers do way too much. Load the code you're given and don't do anything else.
bekacru 1 hours ago [-]
I think auth is complicated outside of browsers too. But browsers do make some things uniquely confusing, especially cookies and general security primitives are full of footguns
wxw 2 hours ago [-]
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!
BoppreH 44 minutes ago [-]
> 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.
snide 1 hours ago [-]
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 remember when they deprecated the library and instead made it a learning resource on implementing auth from scratch. Brilliant decision, much respect to the author.
WilcoKruijer 1 hours ago [-]
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.
elAhmo 59 minutes ago [-]
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.
manishsharan 4 minutes ago [-]
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?
rbbydotdev 2 hours ago [-]
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.
clintonb 2 hours ago [-]
OAuth 2.x and OIDC haven’t changed much. I still use Passport.js with Firebase.
melonpan7 1 hours ago [-]
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.
kandros 2 hours ago [-]
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
supermdguy 2 hours ago [-]
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.
zuzululu 2 hours ago [-]
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.
azyc 2 hours ago [-]
Lol wut? you get all of your auth data in your own db in 1 cli command. You are not tied to any on db provider. On top of that you get hundreds of auth features like oauth providers (I use it to allow users to log in via google, apple, github) and the best part it's free. Not saying Supabase and Clerk are bad, but they cost money. With better auth you pay exactly $0 for all of this.
giancarlostoro 2 hours ago [-]
Or I could use a web framework that offers that out of the box, and its free and lives in my database, wherever I want.
vevoe 9 minutes ago [-]
I use better auth for a side project i'm working on. It's open source, you can pay them to manage your user/auth tables if you want or you can run it all on your own db.
mchusma 2 hours ago [-]
I’ve looked at these auth providers many times over the years and I just don’t get the value. It takes me a couple of minutes to set up auth. Why would I want a dependency? It doesn’t help me with the hardest part which is configuring Google and Apple sign in stuff on Google and Apple. I just don’t get it.
rozap 2 hours ago [-]
this is sorta the obvious takeaway here. as a postgres/phoenix/elixir enjoyer i am blissfully unaware of all this sort of SaaS churn.
Scarbutt 2 hours ago [-]
What framework offers all those auth features OOTB?
ASP .NET Core, Ruby on Rails, Django, .... the list goes on and on... The ones that don't usually someone built a package that lets it happen.
skydhash 18 minutes ago [-]
I remember Laravel with Socialite [0]. Laravel is what I usually reach for Web SaaS MVP. You only need a VPS and a managed database for testing out the market and can scale a lot without increasing expenses that much..
It must have come a long way then -- I'm integrating it into a new product and it is absolutely fantastic. It just works.
volume_tech 2 hours ago [-]
[flagged]
cyberax 2 hours ago [-]
> 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.
notbekacru 1 hours ago [-]
> And even more users who are looking to escape.
Uhm, companies like Replit and several other large startups are actually adopting Clerk. I guess if your world mainly revolves around X (formerly Twitter), it can seem like everyone is moving away from Clerk.
Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.
dzonga 22 minutes ago [-]
in rails I just authentication-zero.
no need for 3rd party provider.
cpursley 2 hours ago [-]
If you're in Elixir-land, I've put together a few packages to help migrating from Supabase (or other stacks):
Easy to use and high reliability. Some of these other providers are not the best at reliability.
dakolli 1 hours ago [-]
The homepage of val.town says "Zapier for know-code engineers".. Is KNOW-code engineer a term?
CharlesW 1 hours ago [-]
It's just a play on the phrase "no code".
Maybe you can help me out: I still have no idea what val.town is. I guess it's an alternative to Cloudflare Workers?
dakolli 56 minutes ago [-]
That's a good question, I was having a hard time figuring that out myself. They call themselves the "zapier" for developers. In reality it seems kinda like a FaaS but idk. They have a code intelligence product that seems like a FIM autocomplete. Very confusing product suite.
1 hours ago [-]
2 hours ago [-]
anishksrini 2 hours ago [-]
[dead]
huflungdung 2 hours ago [-]
[dead]
Rendered at 20:25:33 GMT+0000 (Coordinated Universal Time) with Vercel.
SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.
For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
To expand a bit more: if a business is faced with a choice to save some money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.
That’s the SaaS value proposition.
Okay, so… what are those cases? I’m also curious.
If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.
If you're not threatened by per-user-per-month fees, you can delegate auth.
If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)
If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.
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.
I remember when they deprecated the library and instead made it a learning resource on implementing auth from scratch. Brilliant decision, much respect to the author.
Would think twice before using it in the future.
Anyone remember Auth0 and passportjs?
The churn of auth services is never ending, but I suppose so are the standards.
https://laravel.com/docs/13.x/authentication
https://laravel.com/docs/13.x/socialite
https://laravel.com/docs/13.x/sanctum
[0]: https://laravel.com/docs/13.x/socialite
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.
Uhm, companies like Replit and several other large startups are actually adopting Clerk. I guess if your world mainly revolves around X (formerly Twitter), it can seem like everyone is moving away from Clerk.
Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.
no need for 3rd party provider.
- 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.
Easy to use and high reliability. Some of these other providers are not the best at reliability.
Maybe you can help me out: I still have no idea what val.town is. I guess it's an alternative to Cloudflare Workers?