Parameter Scopes & Overrides
Some parameters decide where a resource is created rather than what it looks like: the cloud account, the tenant, the project, the region. These are resolved through a chain of scopes, so the same Fractal can be deployed into a different subscription or region without editing the component that declares the resource.
The rule is the same everywhere:
Component parameters override LiveSystem parameters, which override the environment.
The nearest scope that carries a value wins. Nothing further down the chain is consulted once one does.
The three scopes
| Scope | Where it is authored | Use it when |
|---|---|---|
| Component | parameters on a single component | One resource belongs somewhere else — a shared bucket in a central account, a replica in another region. |
| LiveSystem | parameters on the Live System | Everything in this deployment belongs somewhere other than the environment default. |
| Environment | The cloud Agent registered on the Environment | The normal case. Set once per environment; every Live System inherits it. |
The environment scope is not a parameter you write on a Live System — it comes from the Agent the environment was initialized with. Agents carry the account / tenant / project / region identifiers for the cloud they manage.
Which parameters follow the chain
| Parameter | Clouds | Notes |
|---|---|---|
region | all | Legacy aliases accepted: location and awsRegion (AWS), azureRegion (Azure). |
subscriptionId | Azure | |
tenantId | Azure | |
projectId | GCP | |
organizationId | GCP | Needed by VPCs, GCS buckets, and anything resolving org-level policy. |
accountId | AWS |
The key name is identical at the component and LiveSystem scopes — there is no separate LiveSystem spelling.
Aliases resolve within a scope, not across scopes
The scope is decided first, the alias second. A legacy alias on a component still beats the canonical key on the Live System, because the component is the nearer scope:
// component: { location: 'eu-west-1' } ← wins
// LiveSystem: { region: 'us-east-1' }
Prefer the canonical region; the aliases exist for back-compatibility.
What the environment scope falls back to
When no scope declares a value, each cloud resolves its environment tier slightly differently, because the consequences differ.
| Cloud | Identifier | Environment tier, in order |
|---|---|---|
| Azure | tenantId, subscriptionId | Agent → legacy agents[] entry in environment parameters → top-level environment parameter → the management environment's value |
| GCP | projectId, organizationId | Agent → legacy agents[] entry → error |
| AWS | accountId | Agent → the agent's configured account |
| all | region | Agent → the agent's configured region → cloud default |
GCP deliberately fails rather than guessing: a project-scoped resource created in the wrong project is not fixed by editing a parameter afterwards. Azure and AWS fall back to management-environment values, which is what pre-Agent environments relied on.
Region defaults, used only when nothing else supplies one:
| Cloud | Default region |
|---|---|
| AWS | eu-central-1 |
| Azure | westeurope |
| GCP | europe-west1 |
Worked example
An environment whose Agent targets project shared-management-1 in us-west3:
// Inherits project and region from the environment Agent.
const net = GcpVpc({ id: 'eval-net', cidrBlock: '10.20.0.0/16' });
// This Live System deploys everything in europe-west4 instead …
liveSystem.withParameters({ region: 'europe-west4' });
// … except this bucket, which must sit in a different project entirely.
const archive = GcpGcsBucket({
id: 'archive',
projectId: 'shared-archive-7',
region: 'europe-west1',
});
net lands in us-west3 (environment), the rest of the Live System in europe-west4 (LiveSystem), and archive in project shared-archive-7 / europe-west1 (component).
DNS zones
A DNS zone declared in environment parameters carries its own parameter map, and that map is its nearest scope: zone parameters → environment Agent → environment parameters → management value. This matters when zones live in a different subscription than the workloads publishing records into them.
These are not secrets
Account, tenant, project, organization, and region identifiers are plain configuration — they are written to component output fields and appear in logs. Do not wrap them in secretRef. Anything that must not be logged (API keys, connection strings, client secrets) belongs in the environment secret store instead; see referencing environment secrets.
Auditing an existing deployment
Because the nearest scope silently wins, a stray identifier parameter moves resources without producing an error. When taking over an unfamiliar deployment, grep component and Live System definitions for the six keys above — a leftover subscriptionId on one component is the usual explanation for "why is this one resource in the wrong place".
Per-component parameter tables, including which components accept a region, are in the component reference.