Auth
Email and password, Google sign-in, verification, and password reset — running inside your own backend, storing users in your own database.
The problem
Every app needs auth, and nobody wants to build it. Hosted options are quick to start and hard to leave: your users live in someone else's database, and the bill grows with every sign-up.
What Bones does
Auth runs on Better Auth, a library embedded in the backend. There's no second service to run.
- Email and password, with length and complexity rules checked on the server.
- Google sign-in, which works in the browser and the desktop app.
- Email verification before a session exists, with a resend on sign-in.
- Password reset by email.
- Per-method switches. Admins turn email or Google sign-in on and off from Site Settings.
- Terms acceptance. When terms are active, a signed-in user accepts them before any permission-checked call goes through.
- Deactivation. An admin can switch an account off without deleting it.
The first account ever created becomes the owner. Everyone after that starts as demo, a read-only role that can look around the admin area.
How it compares
| Option | Trade-off |
|---|---|
| Clerk, Auth0 | Polished, but usage-priced, and your users live with the vendor |
| Firebase Auth | Generous free tier, but it pulls you into Google's ecosystem and doesn't pair naturally with Postgres |
| Keycloak, Authentik, Zitadel | Self-hosted with a full admin UI, but a separate service to run and patch |
| Auth.js | Self-hosted like Better Auth, but no first-class Fastify integration |
Bones takes the library route: no vendor, no extra service, and your users table sits in your Postgres next to everything else.
Go deeper
- Better Auth — why it was chosen.
- Sessions and auth — reading the session and adding session fields.