Container image reference

Astro Private Cloud (APC) installs a fixed set of container images through its Helm charts. This page describes what each packaged image is for. For the exact tag and SHA256 digest of every image in a specific release, see that release’s bill of materials (BOM) at https://updates.astronomer.io/astronomer-software/releases/astronomer-<version>.json (for example, astronomer-1.0.1.json). For what changed between versions, see release notes.

When a release introduces a new image, it’s called out in that release’s release notes entry and added to this page. If you’re comparing a BOM against this page and see an image that isn’t listed here, check whether it’s a new addition that hasn’t been documented yet.

Airflow chart images

These images are installed per Airflow Deployment by the airflow chart.

Image	Purpose
`ap-statsd-exporter`	Converts Airflow’s internal StatsD metrics into Prometheus format.
`ap-redis`	Message broker for the Celery executor. Queues tasks between the scheduler and workers.
`ap-pgbouncer`	Lightweight connection pooler placed in front of the Airflow metadata database to reduce direct connection load from the scheduler, webserver, workers, dag-processor, triggerer, and API server.
`ap-pgbouncer-exporter`	Exposes PgBouncer connection pool metrics in Prometheus format.
`ap-git-sync`	Sidecar that periodically pulls a Dag repository from Git for Git-sync based Dag deploys.
`ap-certgenerator`	Generates the TLS certificate used for PgBouncer’s client connections when `sslmode: require` is set. Runs once per Helm install or upgrade; it doesn’t rotate certificates on a schedule.
`ap-git-daemon`	Serves a read-only Git protocol endpoint so Airflow Pods can fetch Git-sync based Dag code from within the Kubernetes namespace.
`ap-git-sync-relay`	Pulls upstream Git-sync Dags so they can be hosted within the Kubernetes namespace by `ap-git-daemon`.
`ap-init`	General-purpose, lightweight utility image. Used as the XCom sidecar injected into `KubernetesPodOperator` task Pods when XCom push is requested, and to initialize Pod state for several platform components.

Platform (astronomer) chart images

These images support the shared APC platform: the control plane, observability stack, and supporting infrastructure.

Core platform

Image	Purpose
`ap-commander`	The deployment orchestrator. Applies Helm releases for each Airflow Deployment on behalf of the control plane and reports status back to the APC API.
`ap-houston-api`	The APC control-plane API (Houston). Handles authentication, workspace, user, and team management, and orchestrates Commander.
`ap-astro-ui`	The Astro UI web application that administrators and users use to manage workspaces, Deployments, and settings.
`ap-registry`	The integrated container registry that stores customer-built Airflow and Runtime images pushed with `astro deploy`.
`ap-db-bootstrapper`	Init job that initializes a component’s Postgres schema and maintains the Kubernetes secret used to access it. Used by Houston, Grafana, NATS, and Commander.
`ap-dag-deploy`	Serves Dag code over HTTP for Dag-only deploy Deployments, decoupling Dag delivery from image builds.
`ap-auth-sidecar`	Sidecar that enforces authentication and authorization on internal endpoints that don’t have native auth, such as Grafana, Prometheus, and Alertmanager. Also deployed by the `airflow` chart itself, for the dag-server and git-sync-relay sidecars.

Observability and logging

Image	Purpose
`ap-alertmanager`	Routes and deduplicates alerts fired by Prometheus alerting rules to configured notification channels, such as Slack, email, or PagerDuty.
`ap-prometheus`	Metrics store that scrapes and stores platform and Deployment metrics, and federates metrics from data planes.
`ap-configmap-reloader`	Watches the Prometheus ConfigMap and triggers a reload when configuration changes, without restarting the Pod.
`ap-kuiper-reloader`	Polls the control-plane database on an interval and regenerates Prometheus file-based service discovery targets from the Deployments and Clusters tables. A control-plane database outage can wedge this component and stop data-plane metrics from federating to the control plane.
`ap-postgres-exporter`	Exposes PostgreSQL database metrics in Prometheus format.
`ap-grafana`	Dashboards for visualizing platform and Deployment metrics collected by Prometheus.
`ap-kube-state`	kube-state-metrics. Exposes Kubernetes object state, such as Pods and deployments, as Prometheus metrics for cluster-level dashboards and alerts.
`ap-vector`	Log-shipping agent that collects Airflow task and platform component logs and forwards them to Elasticsearch or an external log destination. Used both as a per-Pod sidecar and as a standalone logging component. Also deployed by the `airflow` chart itself, for the dag-server and git-sync-relay sidecars.
`ap-elasticsearch`	Log storage backend that indexes shipped Airflow task and component logs for search in the Astro UI.
`ap-base`	General-purpose minimal base image that most other `ap-*` images build from. Also used, with a `runAsUser: 0` override, as the Elasticsearch init container that applies the `vm.max_map_count` sysctl change.
`ap-curator`	Scheduled job that prunes old log indices from Elasticsearch according to the configured retention period.
`ap-elasticsearch-exporter`	Exposes Elasticsearch cluster and index health metrics in Prometheus format.
`ap-nginx-es`	Reverse proxy in front of Elasticsearch that applies auth and multi-tenant scoping to log queries from the Astro UI.
`ap-openresty`	Proxy layer used both in front of an externally managed Elasticsearch/OpenSearch endpoint and in front of Prometheus, handling internal auth and request routing.
`ap-awsesproxy`	Signs and forwards log requests to an AWS-managed OpenSearch endpoint using SigV4 signing, for platforms using an external AWS log store.
`ap-nats-server`	NATS JetStream server. The internal event bus between Houston API and Houston Worker.
`ap-nats-exporter`	Exposes NATS server metrics in Prometheus format.

Networking and data

Image	Purpose
`ap-nginx`	Primary ingress controller and reverse proxy. Routes external traffic to the Astro UI and API, and fronts per-Deployment Airflow ingress such as the webserver, Flower, and API server. In split control-plane/data-plane installs, a second, data-plane instance handles only Airflow Deployment ingress.
`ap-default-backend`	Default backend nginx serves when an incoming request doesn’t match any configured ingress route.
`ap-postgresql`	Optional embedded PostgreSQL database for the platform and Airflow metadata store. Astronomer recommends using an external database in production.

The ap-pgbouncer image above is distinct from the platform (astronomer) chart’s own disabled-by-default pgbouncer subchart, which uses a different image, ap-pgbouncer-krb, and is gated by global.pgbouncer.enabled: false.

Overview

Architecture

Upgrade to Astro Private Cloud

Install Astro Private Cloud

Develop Dags

Airflow administration

Airflow 3

Deploy Dags

Manage Deployments

Platform administration

Manage Platform resources

Security and compliance

Houston API

Platform Observability

Release notes

Version compatibility

Reference

Container image reference

Airflow chart images

Platform (astronomer) chart images

Core platform

Observability and logging

Networking and data

​Airflow chart images

​Platform (astronomer) chart images

​Core platform

​Observability and logging

​Networking and data

Airflow chart images

Platform (astronomer) chart images

Core platform

Observability and logging

Networking and data