One project, every environment
Environments, keys, redirects and promotions — the operational layer that decides whether identity is something you ship confidently or something you touch carefully
Environments
Every environment is a full copy of the project, with its own data.
Environments
Not a flag on a row. A full copy of the project — its own users, sessions, providers, templates and keys
Compare environments
What would change if you promoted development to production.
The diff you review before promoting. Nothing moves until you say it does
Isolated data
A test user can never appear in production, because it is a different store
Created on demand
Spin one up for a release or an experiment, and delete it when done
Own URL
Each environment answers on its own issuer, so tokens never cross over
Own keys
Publishable and secret keys are issued per environment, never shared
Promotion
Moving configuration forward is a reviewed, recorded action instead of a checklist someone remembers
Compare
A line-by-line diff of two environments before anything moves
Deployments
Every promotion recorded, with who did it and what changed
Applied changes
Each merge keeps the before and after of every field it wrote
Audit trail
Setting changes land in the same log as everything else
Deployment
A promotion between environments, recorded step by step.
3 steps
Applied changes
Authentication
Communications
A promotion is a recorded merge: origin, destination, each step timed, and every field that changed
Who is in the organization
Above the project sits the organization: the people who can reach it, and what each of them is allowed to touch
Members
Who is in the organization, and what they can reach.
| Member | Role | Projects | Last active |
|---|---|---|---|
| ALAda Lovelace[email protected] | Owner | All projects | 2 minutes ago |
| GHGrace Hopper[email protected] | Admin | acme-web, acme-api | 18 minutes ago |
| ATAlan Turing[email protected] | Developer | acme-web | 3 hours ago |
| KJKatherine Johnsoninvited[email protected] | Billing | — | never |
| RPRadia Perlman[email protected] | Viewer | acme-api | 9 days ago |
Members hold roles above the project — separate from the roles inside your product
Organization roles
Owner, admin and billing, separate from the roles inside your product
Project access
Which projects a member reaches, and what they can do there
Invitations
Invite by email; the seat is only taken once they accept
Removal
Pull a member and every session and key they held stops working
Every change, on the record
Configuration is not supposed to change quietly. Every action anyone takes lands in one trail you can filter and export
Action and actor
What was done and by whom, down to the individual setting
Categories
Security, environments, permissions, auth and settings
Filters
By member, by project, and across any date range
Retention
Keep the trail as long as your compliance story needs it
Audit logs
Who changed what, in which environment, and when.
| Action | Actor | Category | When | Target |
|---|---|---|---|---|
| Rotated secret key | AdAda Lovelace[email protected] | security | yesterday at 14:02 | api_keysk-a91c07d5 |
| Promoted development to production | AdAda Lovelace[email protected] | environments | yesterday at 11:41 | environmentmain |
| Granted role admin | GrGrace Hopper[email protected] | permissions | 2 days ago | userusr_9de2b710 |
| Enabled provider apple | AlAlan Turing[email protected] | auth | 3 days ago | projectacme-web |
| Deleted environment preview/checkout | AlAlan Turing[email protected] | environments | 4 days ago | environmentpreview-checkout |
| Added redirect URL | GrGrace Hopper[email protected] | settings | 6 days ago | projectacme-web |
Action, actor, category and target — filterable by member, project and date
The same code, a different environment
Only the key changes. Your code never learns which environment it is in, because nothing about the API differs between them.
const { data: verified } = await nulvless.auth.verify({
resource: "proj_16tbwq34",
roles: ["owner", "admin"],
});Development and production are the same project
Every setting on this page exists per environment. Change it in development, compare the diff, promote it to production — no second project, no copied config, no drift you find out about on a Friday
Compare environments
What would change if you promoted development to production.
Isolated data
Users, sessions, keys and templates never cross an environment boundary
Compare
A line-by-line diff of two environments before anything is promoted
Deployments
Every promotion is a recorded deployment, timed step by step
One platform, from your first user
Focus on your product. We handle identity infrastructure
What you would have built
Six areas, every one of them a project of its own.
- Authenticationpasswords, providers, MFA, sessions
- AuthorizationRBAC, scopes, per-resource grants
- OAuth serverOIDC discovery, JWKS, PKCE
- Edge functionsDeno runtime, deploys, rollback
- Notificationstemplates, providers, delivery logs
- Observabilitymonitoring, audit trail, query