Astro Private Cloud (APC) 1.x uses two customer-facing configuration layers:
values.yaml, which you apply with Helm.Use this document to decide which knob 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 one data plane cluster only.If your goal is to change a setting for one data plane, use cluster configuration. If your goal is to change it everywhere, use values.yaml and Helm.
When you update values.yaml and run a Helm upgrade:
astronomer.houston.config.deployments change.If a cluster already has its own saved value for the same deployments.* key, that cluster keeps its saved value until you update the cluster configuration through Astro Private Cloud.
This is the source of the most common confusion in APC 1.x: customers run a Helm upgrade, expect one data plane cluster to change, and then don’t see the result because that cluster still has its own override for the same deployments.* key.
In APC 1.x, cluster configuration is the final layer for deployments.*.
Every Deployment is registered to a data plane cluster. The platform default for those deployment settings is what you set in values.yaml. If you save a value in a cluster’s Configuration Override, that value applies to the cluster and to all Deployments on that cluster for that key instead of the matching default from values.yaml alone. If you don’t set a key in the cluster override, the value from values.yaml still applies.
For a data plane cluster, open Clusters, select the cluster, then use Configuration Override (as in Data plane overrides). In APC 1.x you only use Helm (values.yaml) and the cluster; there are no separate workspace or deployment configuration screens like in 2.0.
On a cluster, you make changes in Configuration Override and you review Current Configuration as read-only (defaults, or after you save, a read-only, git-style view of what was added or modified). See the UI sections in Data plane overrides. A Deployment on that cluster still uses the values.yaml default for a key the cluster hasn’t set, and the value from the cluster override when it is set, as described earlier on this page.
Use values.yaml for examples like these:
Use cluster configuration for examples like these:
prod-us-east data plane.values.yaml.Assume you want to control whether Deployment rollbacks are enabled.
values.yaml:false.deployments.deploymentLifecycle.deployRollback.enabled now use false.prod-us-east cluster still uses true because its cluster configuration already stores that key in the database.Result:
prod-us-east.prod-us-east, you must update the cluster configuration, not just rerun Helm.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 your saved cluster override. If you want to change a saved deployments.* value for a cluster, update the cluster configuration directly.
values.yaml for platform-wide settings and platform-wide deployment defaults.deployments.* settings that should differ for one data plane cluster.deployments.* key, the cluster value wins in APC 1.x.