Organization configuration can be exported as a portable bundle and applied to another organization. Find it under Settings → Data → Export settings.
This exists for three situations: standing up a second organization that should match an existing one, promoting a configuration from a trial workspace to a real one, and keeping a reviewable record of how a workspace is configured.
What travels
The bundle covers organization-level configuration:
| Area | Included |
|---|---|
| Policy and quality | Org policy, quality policies, project gates, lifecycle policies, review rules |
| Agents and models | AI profiles, provider key references |
| Automation | Hooks, schedules |
| Connections | Source control integrations, channel bridges, MCP servers |
| Access | Enterprise identity configuration, service accounts |
| Data | Retention settings, storage configuration, audit destinations |
What does not travel
Secrets never leave. Provider keys, tokens and credentials are exported as placeholders. The bundle records that a key exists and what uses it, never its value — you re-enter secrets after importing.
Also excluded: anything that is workspace identity rather than configuration — the organization name, its members, its billing relationship — and operational history such as tasks, runs and audit events.
The rule is that a bundle describes how a workspace is configured, not what has happened in it.
Preview before applying
Applying a bundle runs a preview first, showing what each section would do:
| Status | Meaning |
|---|---|
applied | The setting will be created or updated |
unchanged | Already matches; nothing to do |
needsRebind | Depends on something that must be re-pointed locally |
failed | Cannot be applied; the reason is given |
Read the preview properly. needsRebind is the one that matters most — it flags
settings referring to something that does not exist identically in the target,
typically a repository connection or a secret. Those need attention before the
configuration is actually equivalent.
Keeping bundles in version control
An exported bundle is a file, so it can live in a repository, be diffed and be reviewed. For teams treating configuration as code, that is the value: a change to organization policy becomes a reviewable diff rather than a click someone made.
Since secrets are placeholders, a bundle is safe to commit — but check for anything identifying in your own configuration before making one public.