Answer first: Better Auth plus D1, wired up for you #
Better Auth is the authentication framework BYOB pairs with Cloudflare D1 through a Drizzle adapter, with users, sessions, and accounts mapped to D1 and migrations run automatically. BYOB adds a managed Google broker for instant sign-in, project-owned credentials for production, passwordless magic links through its email broker, and forwarded-host handling for preview domains. Scope: SvelteKit apps on D1. Constraint: session lifetimes and consent-screen branding still need per-project decisions.
Authentication is notoriously difficult to get right, especially on edge runtimes. In BYOB, the standard is Better Auth, paired with Cloudflare D1 to deliver secure, frictionless sign in out of the box. Better Auth documents itself as a framework with plugins, adapters, and social providers you compose per app (https://www.better-auth.com/docs).
Concretely, that means three things you never wire yourself: a D1 compatible Better Auth adapter, passwordless magic links through the BYOB email broker, and Google sign in that works on local, preview, and production domains without OAuth mismatch errors. When you initialize auth in a BYOB project, the necessary D1 migrations run automatically.
Auth is the bouncer with the guest list. Get the list wrong and the wrong people walk in, or the right people wait in the rain. Most teams underestimate this job until the night it fails.
Try it: JWT Decoder — so you can try this on your own site now.
What is Better Auth in a BYOB app? #
Better Auth is the authentication layer that owns users, sessions, and accounts. The hard part on Cloudflare D1 is not the idea. It is the adapter. Standard ORM setups often struggle with edge compatibility and D1's unique row shapes. Cloudflare documents D1 as its serverless SQL database with its own API and access patterns (https://developers.cloudflare.com/d1/).
BYOB solves this with a Drizzle adapter over the sqlite proxy shape. The Better Auth schema for users, sessions, and accounts maps cleanly to D1. You never write a custom adapter, normalize row shapes, or sequence migrations by hand.
The generated project stays a real SvelteKit app. Auth lives where SvelteKit developers expect it, in the auth API route, with the Better Auth handler receiving requests after BYOB's domain handling runs. You get edge ready sessions without giving up the normal SvelteKit mental model: routes, components, and a real database behind them.
// src/lib/auth.ts, the shape of a Better Auth setup
import { betterAuth } from 'better-auth';
export const auth = betterAuth({
session: {
expiresIn: 60 * 60 * 24 * 7, // 7 days
updateAge: 60 * 60 * 24 // refresh daily on activity
}
});Better Auth documents session knobs like expiry and update age as first class concepts (https://www.better-auth.com/docs/concepts/session-management). Short version: expiry bounds the damage of a stolen session, update age keeps active users signed in without endless re logins. The OWASP session guidance says the same thing in stricter language, with inactivity timeouts and absolute lifetimes as baseline controls (https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html).
How do magic links compare to passwords for sign in? #
Choose magic links in BYOB for passwordless day-one onboarding and keep passwords only where policy demands them. Magic links sidestep storage, reset, rotation, and breach handling by making the inbox the credential, delivered through the BYOB email broker with no extra provider setup. Constraint: links expire, serve one purpose, and must resolve to the environment the user started from. Passwords create an entire category of work: secure storage, reset flows, rotation, breach handling, and support tickets when users forget them. Magic links sidestep most of that by making the inbox the credential. The user asks to sign in, receives a secure link, clicks it, and the session starts.
Alongside social login, passwordless magic links are a staple of modern apps in BYOB. The operational detail that matters is delivery. BYOB provides an email broker integration. You avoid signing up for a dedicated provider immediately. BYOB handles SMTP delivery of secure, time boxed magic links so you can focus on features.
Time boxed matters. These links are not permanent passwords sent over email. They expire, they serve one purpose, and the verify URL must resolve to the environment the user actually started from. That last point is why preview domain handling below belongs to the auth story, not some deployment footnote.
If you later outgrow the broker or need a dedicated sender reputation, bring your own provider then. For getting users into your app on day one, the default removes a whole setup step.
How does managed Google sign in compare to project owned OAuth? #
BYOB offers two modes for Google OAuth, designed as a progression rather than a fork. Better Auth documents Google as a standard social provider with client credentials per project (https://www.better-auth.com/docs/authentication/google).
BYOB managed broker mode means immediate onboarding with zero configuration. BYOB handles the OAuth credentials through its centralized broker, getting your users into your app instantly. This is the fastest way to test onboarding, share a preview with real users, or validate that social login fits your flow before touching any cloud console.
Project owned mode means production. You plug in your own Google client ID and secret to fully white label the consent screen. The user facing difference is trust: instead of a shared broker name on the consent screen, users see your project. The code path stays Better Auth. Only the credential owner and provider configuration change.
// Project owned Google credentials, production shape
socialProviders: {
google: {
clientId: process.env.GOOGLE_CLIENT_ID!,
clientSecret: process.env.GOOGLE_CLIENT_SECRET!
}
}Start managed, ship, then switch to project owned when the consent screen becomes part of your brand. You never rewrite auth to graduate to production.
| Choice | Setup | Control | Use when |
|---|---|---|---|
| BYOB managed Google broker | Toggle on | Shared consent name | Validate quickly on preview |
| Project owned OAuth | Client ID plus secret | Your brand on consent | Production trust |
| Magic link via broker | No provider signup | Time boxed link | Passwordless day one |
| Email via own provider | Provider config | Sender reputation | Scale plus policy control |
How do you beat the multi domain OAuth trap? #
Beat the multi-domain OAuth trap in BYOB in 2 steps: test sign-in on each host (local, preview, production) and confirm redirect and verify URLs resolve per environment. Prerequisite: a BYOB project with auth initialized so D1 migrations exist. Constraint: each environment resolves to its own correct host, so duplicate sign-in URLs across preview domains stay out of search and users complete sign-in where they started.
One of the hardest parts of preview deployments is OAuth redirect URIs. If your app expects your production domain but runs on a preview URL, OAuth providers throw mismatch errors. The same class of bug breaks magic link verify URLs that point at the wrong host.
BYOB's generated SvelteKit code parses forwarded host headers in the auth API route before passing the request to the Better Auth handler. Whether you test locally, on a preview branch, or in production, OAuth redirect URIs and magic link verify URLs resolve to the correct environment.
That same architecture explains why auth endpoints behave as private infrastructure, not public content. The catch all handler is an API surface for sign in callbacks, session exchange, and verification. No indexable article lives there. Sign in pages generally stay out of search results because they are per user, session gated entry points, and duplicate sign in URLs across every preview domain would only create noise. Each environment resolves to its own correct host, users complete sign in where they started, and crawlers find nothing static worth indexing.
By marrying Better Auth with Cloudflare D1, BYOB removes the boilerplate and edge cases from modern authentication. Wire it once, test the magic link on a preview URL today, and onboard real users tomorrow.
What are the trade-offs? #
The post recommends Better Auth plus D1 through the Drizzle adapter, magic links through the BYOB email broker, managed Google sign in to start with project owned credentials in production, and forwarded host handling for preview domains. That follows the Better Auth docs plus session plus Google provider pages, D1 docs, and OWASP session guidance cited above.
| Where the recommended path wins | Where it loses |
|---|---|
| Managed Google broker gives instant onboarding with no console work | BYOB callback sits in the loop until the team migrates to owned creds |
| Magic links ship with no extra provider setup on day one | Links expire and bind to the starting environment, which complicates cross device flows |
| Forwarded host handling keeps OAuth URLs correct on every domain | Multi domain OAuth still needs registered URIs per host |
Pick project owned credentials from day one when the login screen must show your brand domain, or compliance requires direct ownership of the OAuth client.
Who this is for (and who should skip it) #
BYOB auth wiring fits SvelteKit builders who want passwordless plus Google sign-in on Cloudflare D1 without hand-wiring adapters and migrations. Skip it if you already own a custom identity stack or standardize on Supabase auth. Limit: managed Google stays on a shared consent name, so production trust needs project-owned client ID and secret.
This guide helps SvelteKit builders who want passwordless plus Google sign in without hand wiring adapters and migrations. If you run on Cloudflare D1 and you want a toggle for Google plus magic links through an email broker, Better Auth plus D1 as wired in BYOB fits.
Skip BYOB auth wiring if you already own a custom identity stack or you standardize on Supabase auth for everything. BYOB still supports Supabase auth as a separate path, so pick the adapter that matches the database you already run.
One limit to know. Managed Google stays on a shared consent name, so production trust needs project owned client ID and secret. Magic links also fail if verify URLs point at the wrong host, so test preview and prod hosts separately.
- Best for developers adding magic links and Google sign-in on D1 without wiring adapters.
- Best for startups shipping auth that survives local, preview, and production domains.
- Best for freelancers delivering client logins without password handling headaches.
What we learned building this #
Signing in with Google in BYOB works behind a single toggle that provisions secure credentials for you, with the option to bring your own credentials for production branding. The auth layer maps users, sessions, and accounts to the database and runs setup automatically on project start, including reliable handling for every preview domain.
