Way 2 — self-hosted

Your deployment mints the sessions. You fork the repo into a Convex deployment of your own, and from then on there is no third party in the chain at all: your database, your provider credentials, your domain, your uptime.

This is the path when the lazy one stops fitting — when you want a sign-in method AussieAuth doesn't offer, an OAuth consent screen that says your company's name instead of mine, users in a database you can query, or simply no dependency on someone else's deployment.

Moving here from hosted is one file

Nothing about your app changes: same card, same provider, same ctx.auth.getUserIdentity(). What changes is the issuer in convex/auth.config.ts, and aussieauth init --self-hosted rewrites it for you. That's deliberate — the lazy path is meant to be a starting point, not a trap.

What you end up with

A Convex deployment you own, holding your users and sessions.
All fifteen methods available, each switched on the moment you set its credentials — and invisible until then.
A site (the landing, docs, /setup/* walkthroughs, /admin) you can deploy to your own domain, or delete entirely if you only want the backend.

Steps

1. Fork and clone.

gh repo fork aussieljk/aussieauth --clone
cd aussieauth
bun install

2. Create your own Convex deployment.

bunx convex dev

This creates a fresh project under your Convex account and writes its URL to .env.local. Nothing is shared with the upstream deployment.

3. Set the one required secret.

bunx convex env set BETTER_AUTH_SECRET "$(openssl rand -base64 32)"
bunx convex env set SITE_URL https://aussieauth.localhost

Every other secret is optional — see the table in the Quickstart. A method whose credentials are missing is simply a method your deployment doesn't offer.

4. Run it.

bun dev

Every method that needs no third party works immediately: email/password, username, passkeys, Solana, anonymous, account numbers, demo, and agent keys. Magic links and OTP codes work too — the link or code is written to the Convex logs until you set RESEND_API_KEY.

Pointing an app at it

In the app — a different project from the fork — the same three commands as the lazy path, with one flag:

bun add @aussieljk/auth
bunx aussieauth init --self-hosted
bunx convex dev

--self-hosted reads the app's own CONVEX_DEPLOYMENT and treats that deployment as the issuer, which is right when the app is the fork. When the fork is a separate deployment — the usual arrangement, one auth backend behind several apps — name it instead, and init will register the app against it:

bunx aussieauth init --url https://your-deployment.convex.site

--url implies self-hosted; it's how you say "my AussieAuth, over there".

Making it yours

Name and branding. The package publishes as @aussieljk/auth; rename it in packages/react/package.json if you'll publish your own. The site's copy lives in src/site/ and docs/.
Third-party methods. Google and Apple each have a guided walkthrough in the app at /setup/google and /setup/apple that fills in your deployment's real callback URLs. See Google and Apple.
Only want the backend? Delete src/routes/ and deploy just the Convex functions. Your apps talk to it over HTTP — see Using it from another app.

Deploying your fork

The site deploys to Vercel; the backend stays on Convex. A push to master auto-deploys the site once three repository secrets are set — VERCEL_TOKEN, VERCEL_ORG_ID, VERCEL_PROJECT_ID. Full details in Deploying.

Keep the Convex push manual (bunx convex dev --once): a schema change wants a human watching it.