Organisation configuration can be exported as a portable bundle and applied to another organisation. You’ll find it under Settings → Data → Export settings.
This is useful in three scenarios: setting up a second organisation that should match an existing one, moving a configuration from a trial workspace to a live one, and keeping a record of how a workspace is configured for future reference.
What is included
The bundle covers organisation-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 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 is excluded
Secrets never leave the original workspace. Provider keys, tokens and credentials are exported as placeholders. The bundle records that a key exists and what uses it, never its value — you’ll need to re-enter secrets after importing. that a key exists and what uses it, never its value — you re-enter secrets after importing.
Also excluded: anything that relates to workspace identity rather than configuration — such as the organisation name, its members, its billing relationship — and operational history like tasks, runs and audit events.
The rule is that a bundle describes how a workspace is configured configured, not what has happened 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 carefully. needsRebind is the most important — 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 truly equivalent.
Keeping bundles in version control
An exported bundle is a file, so it can be stored in a repository, diffed and reviewed. For teams treating configuration as code, this is valuable: a change to organisation policy becomes a reviewable diff rather than a manual click.
Since secrets are placeholders, a bundle is safe to commit — but check for any identifying details in your own configuration before making one public.