Helm configuration reference
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
External PostgreSQL (recommended)
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: