Know who is calling, everywhere.
Magic link, Google, Apple, and passwords run inside your project's runtime, with users and sessions in its own replicated auth.db; every request is verified there — locally, no round trip — before your function sees the user.
Real identity, locally too
A built-in dev account signs you in with no provider set up and no email sent.
Verification costs nothing
Sessions are signed tokens the runtime checks itself, with no round trip per request.
Access is reviewable
Auth mode, capabilities, and which functions may read a secret are all declared in files.
Auth, running
local developmentSign-in and verification both run in your runtime
Your project's users, password hashes, sessions and signing keys live in an auth.db the runtime owns and replicates beside its database. Sign-in creates the session there and verification checks it there — a local signature and row check on every request — so revoking a session takes effect on its next call. The portal only relays the email.
- Magic link, Google, Apple, and email/password out of the box
- Verification adds no network round trip to a request
- Refresh and revocation stay central, so access can be withdrawn
[auth]
redirect_urls = ["https://myapp.example.com/welcome"]
[[auth.providers]]
name = "apple"
client_id = "com.example.app.signin"
secret_name = "APPLE_SIGNIN_KEY"Three layers of access, all in files
A function's auth mode decides who gets in, its capabilities decide what the code can reach, and the query it writes decides which rows this caller may touch. Secrets follow the same discipline: the name is committed, the value never is.
- public, optional, or required — checked before your code runs
- A secret can name exactly which functions may read it
- Row-level rules are ordinary SQL, written where the query is
[[secrets]]
name = "STRIPE_SECRET_KEY"
functions = ["checkout"] # and nothing else
[[functions]]
name = "checkout"
auth = "required"
capabilities = ["db", "auth", "secrets"]Built for apps people actually use
What you build with Auth.
Passwordless from day one
Magic link is on by default, so a new project has real sign-in before any provider is registered — and it doubles as the password reset flow later.
Sign in with Apple on iOS
Native apps present an identity token directly, so the user never leaves the app, and the same session verifies inside your functions.
Shared workspaces
Access that follows membership rather than ownership is a join in the function's own query — no separate policy engine to keep in step.
Identity proves who someone is; your functions decide what that person may do.
Why SnoozeStack →