For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Because Astronomer has separate maintenance life cycles for each minor version of APC, the same change can be introduced multiple times across minor versions, resulting in multiple identical release notes. When a new minor version releases, such as version 0.33.0, all changes from previously released versions are included in the new minor version.
If you’re upgrading to receive a specific change, ensure the release note for the change appears either:
Within your target minor version.
In a patch version that was released before the first release of your target minor version. For example, a change in 0.32.5, which released 12/8/2023, is not guaranteed to appear in the 0.33 series, which released 9/8/2023, unless there is a release note for it in an 0.33 patch. However, all changes in 0.32.1, which released June 12, 2023, are guaranteed to be in the 0.33 series, because 0.32.1 was released before 0.33.0.
1.1.3
Release date: May 21, 2026
Additional improvements
Added export of dag_processor_manager and Dag parsing logs from the scheduler to Elasticsearch, so operators can filter these logs.
Improved Commander logging so that an invalid or unsupported COMMANDER_DATAPLANE_DATABASE_URL scheme (for example db+postgresql:// or psql://) surfaces a clear parse error instead of silently returning an empty dbType.
Restored the Docs, Guides, Support, and Grafana links on the Settings page, including for System Admins.
Security enhancements
Patched the CVEs identified against Astro Private Cloud 1.1.2. See the Resolved CVE list below.
Bug fixes
Fixed an issue in NATS worker state after platform upgrades, so the houston worker picks up a fresh NATS connection instead of processing queued messages against a stale state.
Fixed an issue in the Dag-only deploy feature, so deploy revision updates succeed in environments with privateCA enabled, on par with other Airflow components.
Fixed an issue where the dagOnlyDeployment Dag-server Pod crashed with Permission denied writing to its PVC because fsGroup was not set on the Pod securityContext. The Pod securityContext now includes fsGroup: 50000 so the mounted volume is group-writable.
Fixed an issue where the Elasticsearch internal proxy URL construction in PINF produced an incorrect service name (for example <release>-es-proxy instead of <release>-external-es-proxy), breaking log lookups from the Astronomer UI.
Fixed an issue where deployments with customLogging enabled and in-cluster Elasticsearch configured could incorrectly point ingress hosts to the in-cluster Elasticsearch endpoint. This update corrects host resolution behavior and ensures Airflow logging hosts are automatically recalculated and updated during cluster reconciliation and when running the sync cluster operation in the UI or via the API
Fixed an issue where the isGitUrl() validation function in houston-api and apc-ui hardcoded git@ as the only valid SSH username prefix, causing the UI to reject valid SSH git URLs from enterprise servers that use service-account usernames.
Fixed an issue where the astronomer-platform-labeller pre-install/pre-upgrade Job omitted imagePullSecrets, causing installs against private registries to fail when pulling its image.
Fixed an issue where the deployment-upserted-for-update NATS worker logged a noisy Prisma P2025ERROR whenever a Deployment was deleted before the queued message was processed, treating a benign race as a real error.
Fixed an issue where the yarn upgrade-deployments script sent a stripped-down NATS payload missing globalDeploymentsConfig, causing the worker to run with undefined and silently propagate empty values into updateChartVersion.
Fixed an issue on OpenShift and Azure Red Hat OpenShift (ARO) clusters where the chart-rendered Git Sync security context values (fsGroup: 65533, runAsUser: 50000) violated the restricted-v2 Security Context Constraint (SCC), preventing git-sync-relay Pods from scheduling.
Fixed an issue where Houston named the NFS-backed Dags PV/PVC as ${releaseName}-dags-${md5(nfsLocation)} while the Airflow chart expected ${Release.Name}-dags, breaking claimName lookups. The MD5 suffix is no longer applied.
Fixed an issue where Houston’s cluster configuration caches were only invalidated on the local Pod, allowing up to 120 seconds of stale configuration to be served by other replicas.
Fixed an issue where the LocalExecutor option still appeared in the Deployment creation UI even when LocalExecutor was disabled at the cluster level.
Fixed an issue with the COMMANDER_HOUSTON_JWKS_ENDPOINT configuration where the generated JWKS endpoint was missing the svc.cluster.local suffix, which could cause connectivity issues in some environments.
Fixed an issue where Houston’s NO_PROXY matcher failed to honor properly configured bare hostnames and wildcard entries (for example *.internal), routing internal traffic through the corporate proxy and returning 503 errors.
Fixed an issue where hard-deleted Deployments could leave behind related records that continued running in the background, causing inconsistencies during cleanup and recovery workflows. This update ensures associated records, including namespace pool records, are cleaned up correctly and allows Deployments recreated with the same namespace and release name to be provisioned successfully.
Fixed an issue where entering a base domain URL with a trailing slash during data plane registration produced a misleading Commander Metadata service unavailable error. URLs are now normalized before registration.
Fixed an issue in Airflow 3 deployments where errored KubernetesExecutor worker Pods were not automatically cleaned up, causing failed worker Pods to accumulate in the namespace. Errored worker Pods are now cleaned up by default, with the option to override this behavior through Deployment-level variables.
Fixed an issue where the scheduler and triggerer were not scaled down during an Airflow version downgrade, allowing core components to continue running while the database migration was triggered.
Fixed an issue where the Houston update-runtime-check job did not honor HTTP_PROXY, HTTPS_PROXY, or NO_PROXY environment variables, preventing the job from reaching updates.astronomer.io in control plane and data plane same-cluster installs.
Fixed an issue where ap-db-bootstrapper wrote the postgresql:// scheme into derived secrets, causing Grafana to fail to start because Grafana only recognizes the postgres:// scheme. The bootstrapper now normalizes postgresql:// to postgres://.
Fixed an issue where each Airflow task log line appeared twice in the UI on APC 1.1.1 with Runtime 12.2.0, KubernetesExecutor, and Elasticsearch via Vector, caused by a duplicate Airflow 3 file log source in the Airflow chart 1.1.1 Vector configmap.
Fixed an issue where the in-product Docs link pointed to the broken astronomer.io/docs/software URL. The link now points to astronomer.io/docs/astro-private-cloud.
Fixed an issue where the Grafana plugin failed to initialize because the root filesystem was read-only and dashboard YAML files were missing from the image.
Fixed an issue where Workspace users could create new Workspaces through the UI despite the UI displaying a permission denied error.
Fixed an issue where a logged out user navigating directly to an Airflow UI URL and logs in with SSO caused the OAuth callback to append the original Airflow URL to itself, producing a malformed redirect.
Fixed an issue where navigating directly to a Deployment URL appended the entire URL to the end of the path, resulting in a broken redirect. The Airflow UI is now accessible when using Deployment URLs directly.
Fixed an issue where the paginatedDeployRevisions GraphQL query returned an INTERNAL_SERVER_ERROR on the Deploy History page, and the release name appeared as null.
Fixed an issue where hard-deleting a Deployment did not clean up the associated Airflow database and roles in Postgres, blocking the recreation of a Deployment with the same release name.
Fixed an issue where the APC version was not correctly displayed in UI.
Fixed an issue on data planes where the containerd CA update DaemonSet copied the private CA into the wrong /etc/containerd/certs.d/ directory, causing image pulls from the data-plane registry to fail with x509: certificate signed by unknown authority
Added Airflow apiserver cloud role support for improved cloud provider integration.
Removed registry and events denial from Houston ingress configuration in unified mode, enabling conversion of unified mode clusters to control plane/data plane architecture by allowing registry and events to connect from data plane clusters.
Daemonset logging is now supported in Airflow 3, so you no longer need to enable sidecar logging for Airflow 3 deployments of APC.
Security enhancements
Migrated ap-nginx to Chainguard hardened base images, reducing the container attack surface and improving vulnerability remediation timelines.
Bug fixes
Fixed an issue where Houston crashed with a null pointer exception when accessing Deployment status for failed Deployments, causing the platform to become unusable.
Fixed an issue where git-sync Deployments failed when readOnlyRootFilesystem was enabled.
Fixed an issue where Commander Pod auth-proxy container encountered permission denied errors for dataplane in openshift clusters.
Fixed an issue where disabling logging with external Elasticsearch caused an invalid pod spec.
Fixed an issue where the migrations job was missing an init container, breaking the include/ secrets backend.
Fixed an issue where preAirflowExtraInitContainers was not referenced in migrateDatabaseJob.
Fixed a spelling typo in database operation logs.
Known issue
Broken links on the Airflow 2 Dag Runs page (Airflow 13.15.1, APC 1.1.1)
In Airflow 2 Deployments running Airflow version 13.15.1 with APC 1.1.1 and Airflow Chart Version 1, the Dag ID and Run ID fields on the Dag Runs page don’t render as clickable links. Affected users may see broken navigation, incorrect redirects, or raw HTML anchor tags displayed in the UI instead of proper hyperlinks. This issue affects the Dag Runs grid view and prevents navigation to Dag detail or run detail pages.
You can now roll back Deployments from Airflow 3 to Airflow 2 and between Airflow 3 versions. Previously, only Airflow 2 to Airflow 2 rollbacks were supported, leaving you without a recovery path if you encountered issues after upgrading to Airflow 3. This enhancement provides a critical recovery path and reduces upgrade risk for production workloads.
Rollbacks are supported for:
Airflow 3 to Airflow 3: Both source and target must be Astro Runtime 3.1.0 or later
Airflow 3 to Airflow 2: From Astro Runtime 3.0-11 or later to Runtime 12.x or 13.x (Airflow 2.10 or 2.11)
Airflow 2 to Airflow 2: Astro Runtime 2.3.0 and later
Astro Runtime versions 3.0.0 through 3.0.10 are not supported for automated rollbacks. See Roll back a deploy for details.
Optimized database cleanup for scale
The Airflow database cleanup job (airflow-db-cleanup) includes the following enhancements to improve performance and observability at scale:
CSV export feature flag: A new enableExport flag controls whether cleaned-up records are exported as CSV to external bucket storage. Set to true to enable export, or false to skip it. Default is false. Admins must explicitly enable export. Disabling export improves I/O performance in environments where storing cleanup logs is not required. A new batchSize parameter also allows you to configure the number of rows deleted per batch operation (default: 500,000).
Sidecar logging support: Cleanup metadata task Pods now support sidecar logging in addition to DaemonSet logging. This allows cleanup Pod logs to be shipped to Elasticsearch and viewed in the Astro UI for easier debugging.
Record count display: A new showRecordCount flag displays the count of records that will be cleaned up during both dry runs and actual runs.
Custom Airflow metrics export to Prometheus
You can now override the default StatsD metric mappings to export additional Airflow metrics to Prometheus. By default, the StatsD exporter filters out most Airflow metrics and only emits a selected set. With override mappings, you can define custom rules that convert incoming StatsD metrics into properly labeled Prometheus metrics, giving you visibility into Dag processing, scheduler, executor, pool, trigger, and task-level metrics.
To configure custom mappings, add overrideMappings to your Deployment Helm configuration:
1
deployments:
2
helm:
3
airflow:
4
statsd:
5
overrideMappings:
6
- match: airflow.operator_successes_(.*)
7
match_type: regex
8
name: "airflow_operator_successes"
9
labels:
10
operator: "Value"
11
12
- match: airflow.operator_failures_(.*)
13
match_type: regex
14
name: "airflow_operator_failures"
15
labels:
16
operator: "Value"
High-cardinality metrics can significantly increase memory usage in the StatsD Pod.
Added Vector caching support to improve platform stability during high-throughput log ingestion.
Added Airflow backfill permissions for Airflow 3.x Deployments. Deployment Admins and Editors can create and manage backfill runs, while Viewers have read-only access.
Added hostAliases support for Houston, Commander, and Prometheus Pods. You can now configure static DNS mappings in your values.yaml to resolve hostnames to specific IP addresses within Pods, which is useful in environments where internal and external DNS resolution differs.
PgBouncer connection pool sizing now accounts for Airflow 3 components. The airflowStratV2 calculation strategy correctly sizes max_client_conn and pool_size based on scheduler replica count for both Airflow 2 and Airflow 3 Deployments.
Security enhancements
Hardened Houston permission checks to prevent overexposure of service account keys. Only keys at or below the caller’s permissions are returned, and the system key is never exposed without explicit system-level authorization.
Added support for Kubernetes Pod Security Admission (PSA) configuration via namespace labels. You can now apply the baseline Pod Security Standard to Deployment namespaces to prevent privileged pod creation. See Configure Pod Security Admission.
Astro Private Cloud platform images are now built on Chainguard hardened base images, reducing the container attack surface and improving vulnerability remediation timelines.
Added support for Kerberos (GSSAPI) authentication for PgBouncer used by Airflow, enabling passwordless database authentication. See Kerberos database setup guide.
Bug fixes
Fixed an issue where Deployment Helm values from previous configurations persisted after updates, causing removed or changed settings to be incorrectly retained.
Fixed an issue where changing a Deployment’s executor from Celery to Kubernetes using the Astro CLI failed with a Minimum Extra CPU not met error.
Fixed an issue where Redis PersistentVolumeClaims were not cleaned up when switching a Deployment from CeleryExecutor to KubernetesExecutor, causing unnecessary storage consumption.
Fixed an issue where the Flower UI was inaccessible for Deployments using the CeleryExecutor.
Fixed an issue where Airflow 3 runtime versions were not loaded in airgapped mode when using a custom release JSON file.
Fixed an issue where in-cluster Registry provisioning failed due to a secret naming mismatch between the control plane and data plane.
Fixed an issue where the dag-downloader process silently timed out during long-running operations, preventing the platform from downloading newly deployed dags.
Fixed an issue where dag-downloader containers emitted excessive log output before the first deploy, generating thousands of log lines per second.
Fixed an issue where Houston rejected valid PostgreSQL connection strings containing query parameters such as ?sslmode=enable.
Fixed an issue where Houston database connections using Knex failed when connecting to a PostgreSQL instance with a self-signed SSL certificate.
Fixed an issue where cluster metadata reconciliation failed behind an HTTP/HTTPS proxy because the Axios client did not honor proxy environment variables.
Fixed an issue where Deployment creation could be blocked by a database resource leak in the bootstrapper that held a lock on the template1 database.
Fixed an issue where the Deploy History page did not display the updated image version after upgrading an image.
Fixed an issue where custom Pod labels were not applied to dag-server and git-sync relay Pods.
Fixed an issue where the data plane cluster sync job remained stuck due to missing network policies for Commander and Registry connectivity.
Fixed an issue where hard-deleting a Deployment took excessive time due to Pod termination grace periods.
Fixed an issue where the extra capacity slider in the Deployment settings UI could not be moved.
Fixed an issue where some Deployments were inaccessible in the UI due to network errors.
Fixed an issue where minimum resource enforcement was not applied when creating or upgrading KubernetesExecutor Deployments, which could lead to instability after upgrades.
1.0.1
Release date: November 17, 2025
Security enhancements
The dockerize utility has been removed from Astro Private Cloud base images due to frequent CVE exposure, reducing the attack surface of container images.
Added readOnlyRootFilesystem security context to the Sidecar Log Consumer container for enhanced container isolation and security compliance.
Kubernetes version support
Kubernetes versions below 1.31 are no longer tested by default. Customers requiring older Kubernetes versions can use the --set force-incompatible-kubernetes=true flag during installation.
Astro Private Cloud 1.0.1 now supports Kubernetes 1.34.
Bug fixes
Fixed an issue where Airflow 3 task logs failed to display error logs in the UI.
Fixed a UI bug where the Deployments screen displayed "No matches for "" when no Deployments were available.
Fixed an issue where the Elasticsearch host configuration did not automatically reflect in data plane cluster configuration.
Fixed a bug where the Prometheus filesd reloader caused frequent pool exceed errors.
Fixed In-cluster Registry provisioning failures caused by incorrect secret synchronization between control plane and data plane.
Fixed a bug where the Registry failed to start when a data plane was installed with a custom Helm release name.
Fixed an issue where Houston database migrations used an outdated ConfigMap during Helm upgrades.
Fixed a bug where airflowLocalSettings required manual updates before upgrading from 1.0.0.
Fixed a bug where the Dag downloader container repeatedly threw kubernetes.client.exceptions.ApiException: (410) errors.
Fixed Commander permission errors on mkdir /.cache that caused deployment creation failures.
Fixed deployment creation failures with 535 authentication errors on OpenShift clusters in Unified mode.
Fixed container status color consistency in the GUI for improved visual clarity.
Patch astronomer-bootstrap connection string before upgrade to APC 1.0.1
If your installation fails to connect to Postgres after upgrade, ensure the connection value in the astronomer-bootstrap secret includes a database name suffix. For example, /main on AWS RDS or /postgres on AKS. Verify the actual database name by logging in to your database, then patch the secret and run a Helm upgrade.
The secret is in the astronomer namespace (or the namespace where you install APC).
In CP/DP mode, patch the secret in both the control plane and data plane clusters.
For example:
$
# Namespace where APC is installed
$
NAMESPACE=astronomer
$
# Database name suffix; for AWS the default database is usually "main", for AKS "postgres"
$
DB_NAME=main
$
$
# Read current connection string, append database name, and update the secret
Astro Private Cloud 1.0 introduces architectural and component changes to enable cross-cluster Airflow management, improve security and scalability, and provide access to the most up to date Airflow 3 features.
New features
Separation of the Control Plane and Data Planes: Previously, all product and Airflow components were required to run in the same Kubernetes cluster. In Astro Private Cloud 1.0, you can run the Astro Private Cloud components in one cluster, the Control Plane and Airflow components in a separate cluster, a Data Plane. This enables you to manage Airflow deployments across multiple clusters, regions, or cloud providers from one installation of Astro Private Cloud. As part of this capability, Astro Private Cloud 1.0 introduces a suite of Data Plane management features to help manage Airflow deployments across multiple Data Planes.
Airflow 3 support: Astro Private Cloud 1.0 introduces support for Airflow 3, via support for the Astro Runtime version 3.1-2 and later. You can now leverage the last Airflow 3 features in Astro Private Cloud 1.0. Astro Private Cloud 1.0 also introduces a supported upgrade path from Airflow 2 to Airflow 3.
New GUI: Astro Private Cloud 1.0 introduces an entirely new user interface, intended to provide a modern and intuitive experience for monitoring and managing many Airflow deployments across teams.
Security Enhancements
CVE mitigation strategy: To minimize CVE exposure, some container images that make up the Astro Private Cloud platform have been migrated to Chainguard’s hardened images.
Read-only root filesystem: Astro Private Cloud 1.0 introduces the ability to run containers with a fully read-only root filesystem, for customers with security restrictions that prevent higher-level permissions.
Disabled running as root: Root permissions were removed from all images.
Labels can be added to pods: Labels can now be specified in the Astro Private Cloud Helm chart using global.podLabels and propagated to all platform pods, including Houston, Commander, NATS, PgBouncer, Grafana, Vector, and Elasticsearch. To add labels to Airflow Deployment Pods, configure deployments.helm.airflow.labels separately through the Houston deployment configuration.
Scoped Service Account updates: Updates to Service Accounts can now be more tightly scoped to either system, Workspace, or Deployment level.
Removal of ClusterRole requirements from Unified installation modes: When Astro Private Cloud 1.0 is installed in Unified mode, it does not require cluster-scoped permissions (ClusterRole).
Breaking changes
A complete list of breaking changes and migration steps can be found in the product documentation.
Control plane ingress rename provisions a new LoadBalancer (0.x → 1.0) - During upgrades from 0.x to 1.0, the control plane ingress Service name changes from astronomer-nginx to astronomer-cp-nginx. This triggers Kubernetes to create a new external LoadBalancer with a new public IP/hostname. Update DNS and firewall/allowlists accordingly and re-issue TLS/SSL certificates if they reference the previous LoadBalancer hostname. See the upgrade guide.
Removal of Prometheus Exporters (nodeExporterEnabled, blackboxExporterEnabled) - These exporters generated large volumes of metrics that were often unused, increasing Prometheus data size and impacting performance. To improve efficiency, they are no longer provisioned by default.
Replaced NATS Streaming (STAN) with JetStream - The default messaging backend has been migrated from NATS Streaming (STAN) to NATS JetStream, since STAN is now deprecated and no longer actively maintained. JetStream is the recommended replacement, providing improved scalability, reliability, and native support in the NATS ecosystem.
Removal of SingleNamespace Mode - SingleNamespace mode was a proposed feature that allowed multiple Airflow deployments to run in the same namespace as platform components. The proposed feature is now deprecated.
Removal of Astronomer Units (AU) - The AU (Astronomer Unit) abstraction for resource configuration has been removed. Resource management for Airflow components is now standardized using granular CPU and memory settings.
Replacement of Create/Update Deployment Mutations - The createDeployment and updateDeployment GraphQL mutations have been removed. These mutations have been replaced with a single upsertDeployment mutation.
Replacement of Fluentd with Vector for DaemonSet-based Logging - The default logging DaemonSet has been migrated from Fluentd to Vector. This provides improvements in performance (lower CPU/memory footprint), reliability, and a simpler configuration model.
Removal of enableHoustonInternalAuthorization Flag - The enableHoustonInternalAuthorization flag has been removed. Authentication and authorization are now gated by installation mode.
Removal of sysAdminScalabilityImprovementsEnabled flag - This flag enabled a series of internal optimizations to improve scalability and API performance in environments with a large number of users and deployments. The underlying improvements are now part of the platform’s core logic and no longer require feature gating. This simplifies configuration and ensures consistent performance across all environments.
Removal of unsupported Runtime Allowance (enableSystemAdminCanUseNonSupportedRuntime) - This flag allowed system administrators to deploy Airflow runtimes that were not officially supported by Astronomer. To ensure reliability, maintainability, and supportability, the platform now strictly enforces supported runtime versions.
Removal of updateServiceAccount GraphQL Mutation - the legacy GraphQL mutation updateServiceAccount is removed. You can now use one of the following mutations, depending on the scope of the service account you want to update. Scoped mutations improve security and make it clearer which service account you are targeting for updates.
updateSystemServiceAccount (for system-level service accounts)
updateWorkspaceServiceAccount (for Workspace-level service accounts)
updateDeploymentServiceAccount (for Deployment-level service accounts)
Known issues
The Flower web interface is inaccessible. For deployments using the Celery executor, this is usually accessed via the Open Celery button in the APC UI.
Daemonset logging is not supported in Airflow 3, so sidecar logging must be enabled for Airflow 3 deployments. See the install guide for how to enable sidecar logging.
If your control plane is not running on an Openshift cluster, running a data plane on an Openshift cluster is not supported. If your control plane is running on an Openshift cluster, data planes on Openshift cluster and any other Kubernetes distribution are supported. Control planes running on any non-Openshift Kubernetes cluster can manage data planes on any non-Openshift Kubernetes cluster.
Support changes
Extension of the standard support term from one year to two years.
Introduction of a Long-Term Support release channel for support extension to three years for the Astro Private Cloud image versions (not for Airflow or Astro Runtime versions).
The Astro Private Cloud 1.0 support lifecycle and compatibility with Kubernetes, Postgres, and Astro Runtime versions, can be found in the product documentation. See the Version Compatibility reference documentation.
