Environments
An Environment is a control-plane resource, not part of a Fractal blueprint: it is the governance scope a Live System is deployed into, and the place cloud credentials, secrets, CI/CD profiles and DNS zones live.
Environments come in two tiers:
| Tier | Purpose |
|---|---|
| Management | The central point of control. Declares each Cloud Agent with full identity (organization / tenant / tenancy plus account / subscription / project / compartment), and owns the operational environments beneath it. |
| Operational | Where workloads actually run. Declares only a cloud account per provider; the organization / tenant / tenancy is inherited from the matching management agent when the tree is resolved. |
The Fractal Cloud API still calls the owning scope a Resource Group. In SDK and documentation terms that concept is a Bounded Context — the API name is never surfaced to describe it.
Management Environment
Management Environments serve as the central point of control for your Fractal Cloud resources. They manage Cloud Agents, secrets, CI/CD profiles, DNS zones and tags that apply across the operational environments beneath them.
ref() returns a deployable reference to the management environment itself.
operational(shortName) looks up an attached operational environment and returns it with the
parent identity bound, so its own ref() resolves.
Operational Environment
Operational Environments represent the specific cloud environments where your applications and workloads are deployed. They configure region-specific details, including the cloud account per provider, secrets and CI/CD profiles.
An operational account inherits its organization / tenant / tenancy identity from the management
agent for the same provider. Declaring an account for a provider the management environment has no
agent for is rejected, with the provider named. Calling ref() on a standalone operational
environment throws — reach it through management.operational('prod').ref().
Secrets and CI/CD Profiles in Operational Environments
You can define secrets and CI/CD profiles directly within an Operational Environment. This lets you provide environment-specific configuration — different database credentials or API keys for staging and production, for example.
Secrets and CI/CD profiles must be defined on the environment that is used by your LiveSystem. This ensures that your workloads have access to the necessary credentials and deployment configurations. A secret defined only on the management environment is not visible to a workload running in an operational environment.
Any component parameter or link setting may reference an environment secret by short name instead of carrying the raw value — see environment-secret references.
Deploying an environment tree
The management environment is deployed first, because operational agents inherit its identity. Then each operational environment, their secrets and CI/CD profiles, then Cloud Agent initialization.
await cloud.environments.deploy(management, {
providerCredentials: {aws: {accessKeyId: ID, secretAccessKey: SECRET}},
agentInit: 'wait',
});
Environment initialization covers the cloud-side prerequisites per provider, and Cloud agent update covers upgrading an already-initialized agent.
Environment parameters that change behavior
| Parameter | Values | Effect |
|---|---|---|
networkTier | prod / nonprod | Marks the environment as production. Set on the management environment; operational environments inherit it. Drives availability defaults on managed services and the network tiering model. Unset means nonprod. The classification is deliberately never inferred from the environment's name. |