Clone & promote: one tenant becomes two

IdPVault can now apply any snapshot into a different tenant of the same provider. Pick a source tenant, pick a target, choose config, Users & Access, or both, and clone. It ships in the current release for Authentik, Okta, and Auth0 on Business and MSP plans, and the Clone page appears in the sidebar as soon as two of your tenants share a provider.

What it is for

• Promote staging to production - build and test your flows, policies, and app configs in a staging instance, then apply exactly that state to prod, with a read-only preview of every object first.
• Seed a warm standby - keep a second instance one clone away from current.
• Disaster recovery - stand up a fresh instance and clone your latest snapshot into it.

The hard part: ids do not travel

Cloning between instances is harder than restoring into the same tenant, and the reason is subtle: internal ids from two different instances never correspond. Some providers use sequential integer ids for certain object types, which means the id your snapshot carries for one object can point at a completely unrelated object in the target. A naive clone that trusts ids will quietly rewire or overwrite the wrong things.

IdPVault clones pair objects strictly by natural key - name or slug - and rewire every reference to the target’s own copies. A cloned application points at the target’s copy of its provider, a policy binding points at the target’s copy of its policy, and nothing is ever matched, probed, or written by a source id. Same-tenant restores keep the smarter hybrid matching (where ids are meaningful and let a renamed object match itself); clones never touch them.

Honest reporting, all the way down

A clone into a real instance rarely applies 100% of objects, and we think the report should tell you exactly why, per object:

• Some object types are license-gated in the target (for example, certain Authentik provider types require Enterprise). Those fail with the provider’s own error.
• If an object fails to create, everything that depends on it fails honestly: “references provider X which failed to be created earlier in this run” - not a cryptic validation error three steps downstream.
• Bindings that were already orphaned in the source are called out as exactly that.
• A same-named object of a different type in the target is refused with instructions, never overwritten.

Re-running a clone is always safe: it converges, reporting already-matching objects as identical and writing only what differs.

Guardrails

Writing one tenant’s state into another deserves friction. Every clone starts with a dry-run preview, and the apply requires a justification and your password, with the confirmation spelling out the write direction. Applies run as background jobs with real 0-100% progress, the completion line shows applied / failed / ignored per part, and the full per-object report lands in the target’s restore history. Clones also get their own alert category, so your inbox or webhook gets one clean summary - the application list by name, per-type counts, the justification, and a link to the report.

And as always: secrets are never cloned. Identity providers do not export secret material, so recreated apps and providers come back with new client secrets and signing keys (the report lists exactly which), and cloned users arrive without passwords or MFA.

How we tested it

We cloned our own production Authentik - 395 objects across 14 types - into a second instance, repeatedly, until the report reached its honest floor: every remaining line item was either a license-gated provider type or a binding that was already orphaned in the source, each with a plain-English explanation. That is the bar we hold restores to, and clones now meet it.

Clone & promote is available now on Business and MSP plans. See pricing or read the docs.