# 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](/docs/lazy) 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.**

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

**2. Create your own Convex deployment.**

```sh
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.**

```sh
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](/docs/quickstart). A method whose credentials are missing is simply
a method your deployment doesn't offer.

**4. Run it.**

```sh
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:

```sh
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:

```sh
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](/docs/setup/google) and [Apple](/docs/setup/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](/docs/embedding).

## 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](/docs/deploying).

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