Imagine shipping a critical update to production, only to find out an untested script in your staging environment just wiped out a live database connection. In complex enterprise workflows, a single shared space is an active liability.
Using multiple environments solves this by transforming your account into isolated, enterprise-grade workspaces for development, QA, and staging. By decoupling your integrations, flows, connections, and scripts, you can build and test with absolute freedom—knowing a critical failure in dev will never touch your live data.
What editions is this available on? Professional and Enterprise editions
Who has access? Production account owners and admins
Production and non-production environments
Every account starts with one environment: Production. Production is created automatically when the account is set up, it's enabled by default, and it can't be renamed or disabled. Every environment you add afterward is an environment that you can name, enable, and disable to fit your workflow.
Multi-environment entitlements
You can create up to 100 environments in total. Environments share your account's license rather than carrying their own separate costs. They inherit the exact same entitlements as your production account. Your available flows, endpoints, trading partners, and agents match production automatically. Learn more about entitlements.
If you have more environments than licenses (for example, five environments but only three licenses), you can upgrade your account (see Manage your Celigo subscription) or disable an active environment and enable a different one at any time.
You can also reduce your environment count at any time. If you exceed your environment limit, the system will automatically disable your oldest non-production environments first. Disabling an environment never deletes its contents; your flows, connections, and resources are simply paused and will become fully accessible again when the environment is re-enabled.
How do I know if my account has migrated to the multi-environment structure?
If you see the following Production and Sandbox option in integrator.io, your account has not yet migrated to the multi-environment structure. To migrate your account, see Migrate to a multi-environment structure.
Resource isolation
Resources you create in an environment (for example, on-premise agents, imports, exports, connections, scripts, API tokens), exist only in that environment. A flow built in a Development environment doesn't appear in Production, and a connection created in Production isn't available in a QA environment. This isolation is what keeps in-progress development work from affecting live integrations.
Note: In legacy Production and Sandbox accounts, a change in one environment affects both, because the two environments share the same underlying resources. Resources like API tokens, on-premise agents, stacks, and iClients that you create, edit, or delete in one are immediately reflected in the other. This behavior doesn't apply to accounts in the multi-environment structure, where each environment keeps its own isolated resources.
A few things are shared across all of your environments:
- Integration apps migrated to the multi-environment structure are available in every environment.
- Marketplace templates are available in every environment.
To reuse a resource in another environment, clone it. See Create and manage multiple environments.
Learn more about:
Some account-level settings are managed in your Production environment and then apply to your non-production environments automatically, so your environments stay consistent without separate configuration. These include the account time zone, the data retention period, and error management settings. Security requirements such as single sign-on (SSO) and multifactor authentication (MFA) are also set in Production and cascade to your other environments.