Skip to main content
This reference is for the platform values.yaml you apply with Helm: chart-level settings (global, tags, nginx, prometheus, and other subcharts) and the APC API application block astronomer.houston.config, including deployments.* defaults used with Config governance (platform defaults in this file, then optional cluster, workspace, and deployment overrides). Tabular sections use the same path prefix you use in your install values.

Values file structure

The APC Helm chart uses a hierarchical structure:

Required configuration

Configure the following required values:

Helm chart parameter tables

Selected defaults from the APC umbrella chart (values.yaml). Parameter paths are relative to the root of your install values file.

Tags

Global settings

Astronomer platform images

Astronomer workload defaults

Resource defaults for core platform Deployments often ship in the umbrella chart—override requests / limits per component: For nginx, Prometheus, Elasticsearch, Grafana, NATS workload tables, follow the same pattern in your values.yaml; defaults ship alongside those keys in the umbrella chart.

APC API configuration

Set these keys under astronomer.houston.config in your platform values.yaml. Published defaults mirror the APC API config/default.yaml. The subtree deployments.* participates in layered overrides (platform → cluster → workspace → deployment); see Config governance. Override APIs may use the string DELETE_KEY at mergeable leaves where the schema allows (see Config governance).

Outside the deployments subtree

These keys configure the APC API, workers, auth, UI metadata, and integrations. They are not subject to the four deployment override tiers unless documented elsewhere. For keys not listed here (full auth providers, workers.*, prisma, nats, Helm runtime templating helm.*), refer to config/default.yaml and Configuration Flag Migration (2.x) in the APC API repository.

The APC API deployment defaults

The following tables list defaults under astronomer.houston.config.deployments.*. Keys in this subtree participate in the platform → cluster → workspace → deployment override chain described in Config governance.

Operational and platform defaults

Runtime management

Logging

Vector sidecar and optional Elasticsearch client settings for deployment workloads. Logging blocklists for workspace/deployment overrides are described in Config governance.

Dag deploy

Defaults for Dag-only deployment when that mechanism is enabled under deployMechanisms.

Deploy mechanisms

Feature gates for Dag deploy, NFS, git-sync, and git-sync relay defaults.

Airflow components

Auth sidecar

Auth sidecar for routing/auth integration (often cluster-scoped).

Resource management

Cluster sizing, executor availability, Astro Units, and capacity ceilings.

Namespace management

namespaceManagement is blocklisted for deployment-level overrides (immutable after create); see Config governance.

Deployment lifecycle

Database management

Image registry

Metrics reporting

Pagination maxTake limits under metricsReporting.pagination.* follow defaults in config/default.yaml (typically 101 per collection).

Orchestration mode

Deployment orchestration mode (Helm vs operator). Operator probes and detailed probe specs are defined under deployments.mode.operator in default.yaml.

Deployments Helm defaults

The deployments.helm subtree supplies defaults merged into Airflow Helm chart values for each deployment (scheduler resources, PgBouncer sidecars, ingress, runtime images, Elasticsearch hooks, etc.). It is large and nested; defaults are authoritative in config/default.yaml under deployments.helm. For merge and validation rules at override layers, rely on deployments-config-override.schema.json and Config governance.

Mock webhook (test only)

Test-only mock webhook settings for development scenarios.

Global configuration

Base domain and TLS

Plane mode (control, data, unified)

Astro Private Cloud 2.0 supports split control plane and data plane deployments:

Network policies

RBAC and cluster roles

Node selection

Separate platform Pods from Airflow Pods:

Private registry

Use a private container registry:

Namespace pools

Pre-provision namespaces for Airflow Deployments:

Storage class

Specify a storage class for all persistent volumes:

OpenShift support

Astronomer platform components

APC API

The APC API is the core internal API that powers the platform:

APC API configuration (houston.config)

The APC API accepts extensive configuration via houston.config:

Authentication

Deployment defaults (deployments)

APC 2.0 groups deployment-related settings under domains (for example deployMechanisms, deploymentLifecycle, runtimeManagement) using nested objects and feature.enabled toggles—not flat keys such as dagOnlyDeployment or hardDeleteDeployment. For tables of defaults, allowed values, and override semantics, see APC API configuration earlier on this page. For how cluster, workspace, and deployment layers merge, see Config governance. Example shape (abbreviated):
Airflow Helm value defaults merged per deployment live under deployments.helm in the APC API’s config/default.yaml; see Deployments Helm defaults earlier on this page.

Email configuration

Prometheus integration

Deployment orchestrator

The deployment orchestrator manages Kubernetes resources for Deployments:

Registry

Container registry for deployment images:

Astro UI

NGINX ingress

Prometheus (monitoring)

Grafana

Elasticsearch (logging)

Vector (log collection)

External logging

Forward logs to external Elasticsearch:

NATS (messaging)

Database configuration

Database SSL

PgBouncer (connection pooling)

Auth sidecar (OpenShift)

global.authSidecar configures the chart-level platform auth proxy used for OpenShift and similar environments. This is separate from astronomer.houston.config.deployments.authSideCar, which controls the per-Deployment auth sidecar injected by the APC API (default tag 1.29.2).

Logging sidecar

Add Vector sidecar to Airflow Pods:

Dag-only deployments

Airflow operator

Enable Kubernetes operator-based deployments:

Extra objects

Add custom Kubernetes resources:

Complete example

Here’s an example configuration:

Validate configuration

After creating your values file, validate it:

Upgrade configuration

(Optional) When updating your values file, you can use the helm diff plugin, and then run the following command to see a diff of your changes: