Platform administration

Configure Astro Private Cloud

Astro Private Cloud (APC) 1.x uses two customer-facing configuration layers:

  • values.yaml, which you apply with Helm.
  • Cluster configuration, which you set for a specific data plane cluster.

Use this document to decide which knob to change and what to expect after you apply the change.

Use the right configuration knob

Use values.yaml when you want to change:

  • Sign-in configuration, such as auth.
  • Platform services, such as registry, ingress, email, and cleanup jobs.
  • The default value for a Deployment setting across the platform.

Use cluster configuration when you want to change:

  • A deployments.* setting for one data plane cluster only.
  • The behavior of Deployments in one cluster without changing the platform default for other clusters.

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.

What happens when you run Helm

When you update values.yaml and run a Helm upgrade:

  • Platform-level settings change after the Helm upgrade finishes.
  • Platform defaults under astronomer.houston.config.deployments change.
  • Saved cluster configuration doesn’t change just because you ran Helm.

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.

In the Astro UI (1.x)

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.

Decide where to change a setting

Use values.yaml for examples like these:

  • Enable or disable an identity provider.
  • Change a cleanup schedule.
  • Change the default Deployment behavior for all clusters.

Use cluster configuration for examples like these:

  • Enable a deployment feature only for the prod-us-east data plane.
  • Keep one regulated cluster on a different Deployment setting than the rest of the platform.
  • Override a platform default you had set in values.yaml.

Example: Helm upgrade versus cluster configuration

Assume you want to control whether Deployment rollbacks are enabled.

  1. You set the platform default in values.yaml:
1astronomer:
2  houston:
3    config:
4      deployments:
5        deploymentLifecycle:
6          deployRollback:
7            enabled: false
  1. You run a Helm upgrade.
  2. The platform default changes to false.
  3. Clusters without a saved cluster value for deployments.deploymentLifecycle.deployRollback.enabled now use false.
  4. Your prod-us-east cluster still uses true because its cluster configuration already stores that key in the database.

Result:

  • Helm changed the platform default.
  • The cluster-specific value still won for prod-us-east.
  • To change prod-us-east, you must update the cluster configuration, not just rerun Helm.

What APC can update separately

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.

Summary

  • Use values.yaml for platform-wide settings and platform-wide deployment defaults.
  • Use cluster configuration for deployments.* settings that should differ for one data plane cluster.
  • If both layers set the same deployments.* key, the cluster value wins in APC 1.x.