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.
In APC 0.x, you set most application configuration in values.yaml and applied it with Helm. In APC 1.x, configuration that varies per data plane cluster moves out of values.yaml and into the platform database, where you manage it as cluster configuration through the Astro UI or the Houston API.
The reason for the change is that APC 1.x supports multiple data planes from one control plane. A single values.yaml on the control plane can’t express different Deployment defaults for different data plane clusters, so APC 1.x stores per-cluster deployments.* values in the database instead. The control plane reads cluster configuration from the database and pushes it down to each data plane.
For an upgraded environment, your existing values.yaml still sets platform defaults. Per-cluster deployments.* values are seeded into the database the first time you register or update each data plane cluster. After that, you change them through cluster configuration, not by editing values.yaml.
To edit cluster configuration in the Astro UI or automate it with the Houston updateCluster mutation, see Data plane overrides. This page only covers where each setting lives; the editing steps and the example mutation are on that page.
Use this matrix to find where to change a setting in APC 1.x.
values.yaml always covers control-plane platform settings. Cluster configuration always covers per-cluster deployments.* values. Data plane infrastructure values stay in the data plane values.yaml. See Helm configuration reference for the full list of values.yaml keys.
values.yaml, run helm get values <release> -n <namespace> on the control plane or data plane. This shows what you applied through Helm.deployments.* key the cluster has saved. Everywhere else, the values.yaml value applies.Use values.yaml when you want to change:
auth.values.yaml sets its own ingress endpoints for Commander, Elasticsearch proxy, Prometheus, registry, and Deployment ingresses).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.