Config restore
Selective restore with dry-run previews and per-object reports.
How restore works
Restore compares a snapshot against the live tenant and builds a plan: each object is create (missing live), update (differs), or identical. You always run a read-only preview first; nothing is written until you click Apply and confirm.
- Pick and choose - every actionable row has a checkbox; restore all changes or just the ones you select.
- Additive by design - restore creates and updates objects; it never deletes anything from the live tenant.
- Smart matching - same-tenant restores match objects by internal id first (so renames are updates), then by natural key (slug/name/label), so an object that was deleted and recreated is recognized instead of duplicated. Clones match by natural key only, since ids from a different instance never correspond. References follow either way: a restored policy binding points at the recreated app's new id automatically.
- Converges - run the same restore twice and the second pass reports "identical, nothing to do".
Per-provider coverage
| Provider | Restorable | Not auto-restored (visible in plan) |
|---|---|---|
| Authentik | Applications, providers, flows, sources, stages, policies, bindings, groups, mappings, certificates, brands | Blueprints, managed objects (Authentik-owned) |
| Okta | Apps, groups, network zones, all policy types, identity providers, event/inline hooks | Authorization servers, schemas (user/app), profile mappings (auto-regenerated with the app) |
| Auth0 | Clients, connections, resource servers, roles, rules | Tenant settings, branding, custom domains, actions |
Objects that can't be auto-restored still show in the plan when they differ, marked unsupported, so a deletion is never invisible.
Credentials on recreated apps
IdPs never export secret material, so a recreated app comes back with a new client secret / signing certificate. The report marks these created_new_credentials: update the integration on the far end.
Clone / promote
Cloning into a different tenant of the same provider has its own page and its own doc: see Clone & promote for how matching works across instances, the safety rails, how to read the report, and clone alerts.
Applies run in the background
Applying a restore or clone runs as a background job: large applies can take minutes, and the job survives even if you close the dialog or the browser. Progress (live API call count) shows in the dialog and in the Activity area, and the full report lands in the target tenant's restore history when it completes.