Instances and environments
Every application has two instances, development and production. An instance is a separate world: its own users, sessions, organizations, settings, keys, webhook endpoints, OAuth clients and signing keys. Nothing moves or is shared between the two, so a test sign-up never becomes a production user.
| Development | Production | |
|---|---|---|
| Host | Zautha’s, such as happy-otter-1.accounts.zautha.com; it cannot be changed |
A subdomain of your site, such as accounts.example.com (custom domain) |
| Ready | At once | Once the domain’s CNAME record is verified |
| Keys | pk_test_…, sk_test_… |
pk_live_…, sk_live_… |
| How the browser holds the session | No cookies on Zautha’s host: the SDK keeps the client credential itself and sends it in a header | An HttpOnly cookie on your Frontend API host |
| Allowed origins | localhost and 127.0.0.1, the instance’s host, and the origins you list |
Every https origin on your domain and its subdomains, and the origins you list |
| Test identities | +zautha_test addresses get no email and verify with 424242 |
None |
| Bot protection | None | Turnstile on sign-up and on sign-in after repeated failures |
| Users | Up to 100 | No instance limit; counted toward the plan |
The publishable key (pk_…) goes in your frontend: it is not a secret, it names the instance’s Frontend API host
(the SDK decodes it). The secret key (sk_…) goes only on your server: it calls the
Backend API for its instance. It is shown once, when you create it on the API keys page; create as
many as you need and revoke the ones you no longer use.
Test identities
Section titled “Test identities”On a development instance, an email address whose part before the @ ends in +zautha_test (for example
jane+zautha_test@example.com) receives no email; the code 424242 verifies it. Use them in automated tests. Such an
address verifies with a code only, never with an email link.
Settings
Section titled “Settings”Each instance has its own settings in the dashboard: Auth settings (sign-in options, required fields, password rules, session lifetime, allowed origins, social connections, enumeration protection, two-step verification), Branding, Organizations, OAuth clients and Webhooks. Set up production when you go live; the development instance’s settings are not copied.