Astro Private Cloud (APC) separates responsibilities between a control plane cluster and one or more data plane clusters. The control plane hosts the shared management experience while delegating Airflow execution to attached data planes. This document summarizes the components that run inside a control plane, how they interact with data planes, and what infrastructure operators must provide. For the runtime side of the platform, see Data Plane Architecture, or review Unified Architecture if you run both roles in a single cluster.
A control plane cluster focuses on:
app.<base-domain>, houston.<base-domain>, etc.) for users and the Astro CLI, and it keeps secure connections open to each data plane’s deployment orchestrator (Commander) and metrics gateway so configuration and telemetry stay in sync.The control plane never hosts user Airflow workloads. Instead, it maintains references to external Kubernetes clusters (data planes) and coordinates their lifecycle.
APC enables the following components when global.plane.mode is set to control (or unified):
charts/astronomer/templates/astro-ui/*): Provides the web application for administrators and users. Runs only on the control plane.charts/astronomer/templates/houston/**/*): Manages platform metadata, user auth, workspace creation, registry tokens, and periodic tasks (cleanup jobs, metrics aggregation).charts/nats/templates/*): Event bus used by Houston and deployment orchestrator (Commander) to coordinate deployments.charts/alertmanager/templates/*): Consolidates alerts sent by Prometheus.charts/prometheus/templates/prometheus-statefulset.yaml) runs in all modes, but its federation jobs, ingress, and auth proxy are tailored to aggregate data plane metrics when running as a control plane.charts/nginx/templates/controlplane/*): Exposes the Control Plane UI and API endpoints for users and the Astro CLI.charts/postgresql, charts/pgbouncer): Most Deployments use an external database, but if global.postgresqlEnabled=true, the embedded database is deployed regardless of plane mode. In a split Deployment this chart is typically disabled. Astronomer recommends only using embedded Postgres for testing or development environments.These services rely on a handful of Kubernetes constructs such as ClusterRoles, service accounts, network policies, and ingress controllers that the chart generates automatically when mode=control or mode=unified.
Control plane ingress endpoints typically include:
app.<base-domain>: APC web interface (UI) for administrators and workspace users.houston.<base-domain>: API traffic for the UI, Astro CLI, and deployment orchestrator (Commander) callbacks.alertmanager.<base-domain> and prometheus.<base-domain>: Optional if those dashboards are exposed.registry.<base-domain>: When hosting the integrated container registry on the control plane. In a split deployment the registry generally lives on data planes; expose or disable depending on your design.Control plane pods also reach out to data planes using deployment orchestrator (Commander) and Prometheus federation endpoints sharing tokens that Houston issues.
Each data plane is registered with the control plane through Houston. After registration:
deployment orchestrator (Commander) in data planes receives payloads from the Control Plane Houston for desired state, applies Helm releases for each Airflow deployment, and posts status updates.Secret distribution job (Config Syncer) (data plane cronjob) pushes tokens into Airflow namespaces; Houston maintains them.Setting global.plane.mode to unified deploys both control plane and data plane components into the same cluster. That configuration is helpful for testing or small environments but loses the strict separation and isolation you gain with split deployments. For a detailed comparison, see the accompanying Unified Architecture page.