Override data plane cluster configurations

Cluster overrides let you customize Deployment configuration for one data plane cluster. They don’t change platform-level control plane settings. Use Configure Astro Private Cloud if you need to decide whether a setting belongs in platform config, a cluster override, a Workspace override, or a Deployment override. Astro Private Cloud (APC) has two types of Deployment configurations that you can set at the data plane cluster level.

Default configuration: The base, system-provided configuration. You can override default values. In APC 2.1 and earlier, you can’t delete default keys. Starting in APC 2.2, you can remove some of them. See Remove a setting.
Custom configuration: Your own additional keys and values. You can add, modify, or delete these keys.

A cluster save merges the keys you send into the stored cluster override. Keys that you leave out keep their stored values.

Prerequisites

An APC control plane is installed and reachable.
You have System Admin permissions in the APC UI or access to the APC API.
The data plane cluster is healthy and accessible from the control plane.

Update the cluster configuration in APC 2.2

Astro Private Cloud 2.2This feature was introduced in Astro Private Cloud 2.2. To access this feature, upgrade your Astro Private Cloud installation to 2.2 or later.

Starting in APC 2.2, the cluster page in the APC UI has the following sections:

Cluster Information: The cluster name, assigned region, and cloud provider.
Derived configuration: Whether the cluster derives its configuration from the current platform defaults. See Derive cluster configuration from platform defaults.
Removed settings: The settings that the cluster override removes.
Cluster Deployments Configuration: An editor that starts from the cluster’s resolved configuration (the snapshot, or the current platform defaults if the cluster derives, with the cluster override applied) and highlights your edits against it inline. Recorded removals don’t appear in it as DELETE_KEY.

Change or remove a setting

Open the cluster

In the APC UI, go to Clusters and select the cluster.

Edit the configuration

Turn on Edit. In Cluster Deployments Configuration, change the values you need, add keys, or delete a key to remove it.Deleting a key sends a removal, so you don’t enter DELETE_KEY yourself. What a removal does depends on the key:

Under helm, the Airflow Helm chart’s own default applies, except for a few protected keys.
A key with a platform default goes back to that default. On a cluster that doesn’t derive its configuration, the key keeps its current value until the cluster derives.

See Remove a setting for the full rules.

Review and save

Click Update Cluster. The confirmation dialog lists each change with its old and new value, and marks deletions. It also warns about edits that it doesn’t save:

A value that still holds <redacted>, so that APC never records a scrubbed credential.
A change at a path that the data plane supplies. See Values the data plane supplies.

Click Confirm update to save.

Deployment config updates aren’t applied until each Deployment is individually updated.

Restore a removed setting

Turn off Edit. You can’t restore a setting while Edit is on.
In Removed settings, turn on Show removed keys. The count next to the switch shows how many settings the cluster removes.
Click Restore next to the setting, then confirm.

Restoring a setting puts back the platform default, or leaves the key unset where there is no platform default. Restore only works on a setting that the cluster removes. To stop overriding a helm key that the cluster sets to a value, delete the key in the editor, click Update Cluster, then restore it. To restore a setting with the APC API, pass the path to clearConfigOverridePaths in updateCluster. See Update a cluster with the APC API.

Update the cluster configuration in APC 2.1 and earlier

The cluster page in APC 2.1 has the same Cluster Information and Cluster Deployments Configuration sections as APC 2.2, without Derived configuration and Removed settings.

Update your cluster

You can define cluster configurations when you first register a cluster or later by updating the cluster through the UI or APC API.

Registration: The form includes an optional Deployments Config Override field. You can supply initial overrides when registering.
Edit: Turn on Edit on the cluster page to change the cluster. The page has two sections:
- Cluster Information: The cluster’s details. In APC 2.1, you can edit the name, cloud provider, and assigned region. In APC 2.0, you can edit only the name.
- Cluster Deployments Configuration: A YAML editor that starts from the cluster’s stored configuration and highlights your edits against it inline.
APC API: If you automate cluster management, use the APC API to update cluster metadata and connection secrets. Refer to your internal API client or see platform API docs.

Update cluster information

In APC 2.1, you can edit the Name, Cloud Provider, and Assigned Region in the Cluster Information section. In APC 2.0, only the Name is editable. To change Deployment configurations, edit Cluster Deployments Configuration.

Override base configuration

Add your own keys and values to tailor behavior per cluster. You can’t delete default keys, but you can override their values to make custom configurations.

Select cluster

In the Clusters page, select the cluster where you want to override a configuration.

Find configuration to review

Search for the configuration that you want to edit in Cluster Deployments Configuration.

Use ctrl+F or cmd+F on Mac to search for the config.

Edit configuration override

Turn on Edit to unlock Cluster Deployments Configuration. You can now make override edits.

Add new key and value

Add your new key and value in Cluster Deployments Configuration.In the Astro UI, make updates in the YAML editor in Cluster Deployments Configuration. The UI sends the correct values to the APC API when you save, including when you clear an override for a key. Click inside the YAML editor to focus it, then use Ctrl+F (Windows and Linux) or Cmd+F (Mac) to open the in-editor find control and search within the configuration (this is separate from the browser’s page-wide find).

Cluster Deployments Configuration YAML editor focused, with the in-editor find control used to search the YAML.

APC API updateCluster (GraphQL): To remove a key from the stored deployments override, pass a deploymentsConfigOverride object and set that key’s value to the string "DELETE_KEY". See Config governance.
Base configuration keys can only have their values overridden, not removed from the underlying defaults, and you can’t use "DELETE_KEY" on paths that are required in the platform’s default deployments object.
Schema validation: When the APC API has strictSchemaCheck.enabled set to true (from astronomer.houston.strictSchemaCheck in the control plane’s values.yaml, true by default in 2.0), unknown keys or bad types in deployments overrides are rejected. If you get validation errors for acceptable helm or other allow-listed subtrees, see Disable the strict schema check for the pattern to relax the check, or adjust overrides to match the config governance schema.

Carefully check your configuration updates before you update your cluster, as these configuration changes can impact all cluster users.

Apply changes

Click Update Cluster to apply your changes.

Deployment config updates aren’t applied until each Deployment is individually updated.

Verify changes

Confirm cluster status is Healthy on the Clusters page in the Astro UI.
For Airflow Deployments in your updated cluster, trigger a small change and confirm the deployment orchestrator applies it as expected.
In Prometheus on the control plane, verify the cluster appears in federated targets.

Example: set per-component storage classes

If different Airflow Deployment components need to use different storage classes, set them in the cluster override. The following example points Redis and Dag deploy at separate storage classes:

helm:
  airflow:
    redis:
      persistence:
        storageClassName: <redis-storage-class>
dagDeploy:
  persistence:
    storageClass: <dag-deploy-storage-class>

helm.airflow.redis.persistence.storageClassName controls the Redis persistent volume created by the Airflow chart, and dagDeploy.persistence.storageClass controls the shared volume used by the Dag deploy service. Each Deployment in the cluster picks up the new storage classes the next time it is updated. You can also scope these overrides further with Workspace or Deployment overrides if a single Deployment needs different storage classes than the rest of the cluster. To set storage classes cluster-wide instead of per-cluster override, configure the equivalent keys under astronomer.houston.config.deployments.helm in your control plane values.yaml. See Install the Astro Private Cloud Control Plane for the platform-level storage class settings.

Additional notes

Cluster overrides apply to deployments.* values for the selected data plane cluster.
In APC 2.x, Workspace and Deployment overrides can further override eligible deployments.* values after the cluster layer.
Settings outside deployments.* stay in values.yaml, typically under astronomer.houston.config, and require a Helm upgrade.
Use Apply a config change for platform-level values and Configure Astro Private Cloud for the full hierarchy.

Best practices

Keep overrides minimal. Prefer Base Config unless a cluster truly deviates.
Use consistent naming and comments for custom keys.
Review the highlighted changes in Cluster Deployments Configuration to validate the final effective settings before you click Update Cluster.