Going live: promote test to production

Import your users, promote apps, webhooks and settings from test to prod, swap in the prod client ids and secrets, and optionally add a custom domain.

Test and production are separate environments with their own issuers, keys, users and secrets. Going live copies your configuration across, with the users you imported, and switches your apps' environment.

1. Bring your users

Import into Test first: Users → Import reads the export of Auth0, Clerk, Firebase, Supabase, Cognito or Keycloak (converted in your browser; only the rows are uploaded), an Anchr.ing export, or a JSON list of your own (check first, then import). Sign in as a few of them in test; promoting (step 2) then moves the imported users to production. Each row of your own list: email, email_verified (or verified), optional name, password_hash (bcrypt, argon2, PBKDF2 or Firebase scrypt) and metadata:

[
  { "email": "ada@acme.example", "email_verified": true, "name": "Ada", "password_hash": "$2b$10$…" },
  { "email": "bob@acme.example", "verified": true }
]

Existing emails are skipped, so a rerun is safe. Imported hashes are rehashed on first sign-in; users without a hash sign in once by email code. Imports emit no webhooks. What carries over from each provider, and the steps to export from it, are in the MCP server's migration_plan and check_import_file tools.

From another provider, pick it under Users → Import. Passwords carry over where the provider exports the hashes; where it doesn't, you email every user a link to set a new one, from the dashboard (the import's Email everyone a link to set a password).

2. Promote to production

Promote to production in the dashboard copies apps (with their audiences and claims templates), webhooks, social connections, settings and branding, the logo and the metadata schema. Prod apps get new prod_ client ids, and each prod webhook gets its own signing secret, shown once in the result. Webhook URLs are copied as they are: replace an http://localhost receiver with the real one in prod.

3. Switch the environment

AUTH_ENV=prod
VITE_AUTH_CLIENT_ID=prod_…          # the prod ids the promote created
ACME_CLI_CLIENT_ID=prod_…
ANCHRING_WEBHOOK_SECRET=…           # the prod webhook's own secret, shown once in the promote result

Audiences (acme-api, and so pat.audience) stay the same.

4. Check

Sign in, call the API, run your CLI's login, and watch events arrive in the webhook log.

A custom domain

A custom domain such as auth.acme.example for prod is the passkey domain of that host, so add it before any user registers a passkey. Custom domains are not self-service on Anchr.ing yet. Once one is set up, pass the issuer to the SDK:

createAuth({ project: 'acme', env: 'prod', issuer: 'https://auth.acme.example', clientId: 'prod_…' });

Every option, error and token type: the SDK README.