Astro Private Cloud (APC) 2.x uses four customer-facing configuration layers:
values.yaml, which you apply with Helm.Use this document to decide which layer to change and what to expect after you apply the change.
Use values.yaml when you want to change:
auth.Use cluster configuration when you want to change:
deployments.* setting for every Deployment in one data plane cluster.Use a Workspace override when you want to change:
deployments.* setting for every Deployment in one Workspace.Use a Deployment override when you want to change:
deployments.* setting for one Deployment only.If your goal is “change this everywhere,” use values.yaml. If your goal is “change this for one cluster, one workspace, or one Deployment,” use the most specific override that matches the scope you want.
When you update values.yaml and run a Helm upgrade:
astronomer.houston.config.deployments change.If a cluster, Workspace, or Deployment already has its own saved value for the same deployments.* key, that saved value stays in effect until you update that specific override through Astro Private Cloud API or UI.
APC 2.x chooses the final value in this order:
Treat the preceding list as priority from top to bottom. If the same setting is set in more than one place, the lower line (closer to a single Deployment) is usually what applies. A few settings can be changed only in values.yaml or only at the cluster; for those rules, see Config governance.
Use the Astro UI when you aren’t using the APC API or your own automation:
On a data plane cluster, you edit in Configuration Override and you read Current Configuration as read-only (defaults, or after you save, a read-only, git-style view of what was added or modified), as in Data plane overrides. In Workspace and Deployment settings, the Configuration Overrides editor is different: it shows the override stored for that workspace or that Deployment. In every case, the platform still combines the four layers in the order above. Who can open and edit these pages depends on your role and permissions. Platform administrators can change role permissions in values.yaml.
Use values.yaml for examples like these:
Use cluster configuration for examples like these:
prod-us-east data plane.Use a Workspace override for examples like these:
Use a Deployment override for examples like these:
Assume you want to control whether Deployment rollbacks are enabled.
values.yaml:prod-us-east cluster overrides the same key to true.finance Workspace overrides the same key back to false.finance Workspace overrides the same key to true.Result:
true.finance Workspace use false.prod-us-east use true.false.If you run another Helm upgrade and leave the cluster, Workspace, or Deployment override in place, those more specific saved values still win.
To keep configuration manageable:
values.yaml for shared defaults.Not every key under the platform deployments tree can be set in every override tier, and some keys are blocklisted at the Workspace or Deployment level. The Astro UI and API reject those writes.
authSideCar, logging can’t be set.authSideCar, logging, and namespaceManagement can’t be set.Rationale, API errors, DELETE_KEY, and strictSchemaCheck are covered starting at Blocklisted keys in Config governance.
To create or change overrides with automation, use the updateCluster, updateWorkspaceDeploymentsConfig, and updateDeploymentConfig GraphQL mutations, which are described in the same Config governance page.
APC can refresh some data plane metadata separately from a Helm upgrade. For example, it can sync values such as data plane chart version or namespace pool metadata back into the cluster record.
This isn’t the same as replacing saved cluster, Workspace, or Deployment overrides. If you want to change a saved value under the platform deployments tree, update the specific override at the scope where it is stored.