Skip to main content
This document contains release notes for each version of Astro Private Cloud (APC). Version 2.0 is the latest long-term support (LTS) version of Astro Private Cloud. To upgrade to version 2.0, see Upgrade Astro Private Cloud. For more information about APC support periods, see Release and lifecycle policies. To read release notes specifically for the Astro CLI, see Astro CLI release notes.
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 1.1.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.
​
August 10, 2026
Astro Private Cloud 2.1.0 adds control plane reliability, custom roles and permission audit, Airflow Operator mode, and per-deployment migration, and significantly expands data plane failover.Before you upgrade, review Breaking changes for the changes to default behavior in this release.

​
New features

  • Control plane reliability: You can now run two or more control planes that share one database and serve one customer-facing domain. Within a region they serve traffic together, and an unhealthy control plane drops out of rotation automatically. Across regions, you can stand up control planes in a standby region and fail the platform over to it during an outage or a planned migration. Two new admin pages, Regions and Control Planes, manage this system. See Control plane reliability, Configure control plane reliability, Manage a control plane reliability group, and the Control plane reliability reference.
  • Custom roles and permission audit: You can now define custom roles from a catalog of granular permissions that spans both platform and Airflow permissions, scope them to the system, a Workspace, or a Deployment, and assign them to users, teams, and service accounts. Custom roles are additive and don’t change the built-in Viewer, Editor, and Admin roles. They’re disabled by default until a System Admin enables them for the platform. A new Permission Audit page shows who has access to a given system, Workspace, or Deployment, and what any single user, team, or service account can do. See Custom roles, Permission audit, and the Role and permission reference.
  • Airflow Operator mode and Deployment adoption (Preview): You can now run a Deployment as an Airflow custom resource managed by the Airflow Kubernetes Operator instead of as a Helm release. If you already run Airflow with the operator, you can register that cluster as an APC data plane and adopt its existing Deployments without recreating them or interrupting Airflow, bringing their environment variables, users, registry, logs, and metrics under APC. Unadopt a Deployment to hand control back. Adopt and unadopt from the APC UI or with astro deployment adopt and astro deployment unadopt. Operator support is disabled by default and enabled per data plane. See Airflow Operator mode, Adopt Astro Runtime Operator managed Deployments, and Move the operator under APC.
  • Per-deployment migration: You can now migrate individual Deployments to another data plane cluster, rather than failing over an entire data plane. Use it to shift a busy or unhealthy Deployment onto a neighboring cluster, or to let one team test failover on their own Deployment. Requires data plane failover to be enabled on your clusters. See Configure per-deployment migration, Manage and observe migration, and the Per-deployment migration reference.
  • LDAP authentication: You can now authenticate users directly against an LDAP or LDAPS directory, such as Active Directory or OpenLDAP, with no OIDC bridge in between. You can also import LDAP groups as teams and map LDAP groups to system roles. See Configure LDAP authentication.
  • Failover upgrade for existing Deployments: You can now retrofit Deployments created before data plane failover was enabled, so they get the inactive database connection failover requires. Upgrade Deployments one at a time or in bulk, and use the indicator on the Deployments list to see which Deployments are ready for failover and which still need the upgrade. See Run a failover upgrade.
  • HashiCorp Vault for data plane failover: You can now use Vault as the ClusterSecretStore backend that the External Secrets Operator uses to replicate Deployment secrets between failover clusters, using Vault’s Kubernetes auth method. See Configure Vault for data plane failover.
  • git-sync over HTTPS: You can now authenticate git-sync to a private repository over HTTPS with a personal access token, in addition to SSH. Credentials are validated when you save the configuration rather than at first sync. git-sync-relay now also trusts the bundles named in global.privateCaCerts, so clones against a Git host behind a private certificate authority succeed, and a Deployment’s status indicator reflects git-sync health, so a failing sync is visible without opening the Logs tab. See Deploy Dags with git-sync.

​
Breaking changes

  • Soft delete is removed. Deleting a Deployment now removes it and its Airflow database immediately, the Hard delete checkbox is gone from the APC UI, and the hardDeleteDeployment flag is deprecated in the Astro CLI. The hardDeleteDeployment configuration key no longer gates anything and is retained only so existing configuration overrides continue to validate. Confirm that your delete workflows and any automation that relied on recovering a soft-deleted Deployment account for the new behavior before you upgrade.
  • The default USER role no longer includes the system.workspace.create permission, so authenticated users can no longer create a Workspace — and therefore Deployments in it — without an explicit grant. Every authenticated user previously held this permission, which let them create a Workspace, inherit Workspace Admin on it, and create Deployments there. If your teams create their own Workspaces, grant system.workspace.create through a custom role or a system role assignment before you upgrade. See Manage platform users and User permissions.
  • Default container security contexts now comply with the Kubernetes Pod Security Standards Restricted profile (PSS Restricted enforcement itself isn’t enabled by default). The platform chart and the APC API’s injected container contexts now set allowPrivilegeEscalation: false, capabilities.drop: [ALL], runAsNonRoot, and seccompProfile.type: RuntimeDefault, and force readOnlyRootFilesystem regardless of overrides. If you set a component’s securityContext, provide the entire block — other than readOnlyRootFilesystem, values aren’t deep-merged with the defaults. See Configure security contexts.
  • global.acme is removed. Remove this deprecated flag from your values.yaml before you upgrade, because the strict schema validator rejects unknown keys.
  • Cluster Admin permissions are folded into System Admin. SYSTEM_ADMIN now inherits the CLUSTER_ADMIN permission set, and both roles gain the new cordon, region, control plane registry, adoption, and custom role permissions. Review any automation that asserts an exact permission set.
  • The Airflow Operator sub-chart condition changed. The sub-chart is now gated on airflow-operator.enabled first and global.airflowOperator.enabled second. If your cluster already runs a standalone Airflow Kubernetes Operator, set airflow-operator.enabled: false to avoid installing a second one, and keep global.airflowOperator.enabled: true.

​
Security enhancements

  • Patched the Critical and High severity CVEs identified against Astro Private Cloud 2.0.1. See the Resolved CVE list.
  • Environment variables marked isSecret are now masked in Pod stdout logs.
  • Platform Kubernetes service accounts now set automountServiceAccountToken explicitly, so a Pod that doesn’t need the API server no longer receives a mounted token.
  • Removed the default Workspace-create grant from the USER role. See Breaking Changes.

​
Additional improvements

  • Postgres 18 support: APC is now compatible with Postgres 18 and later.
  • Migrate from unified mode to split mode: Installations running the control plane and data plane in one cluster can now migrate to split control plane and data plane mode without Airflow downtime or data loss.
  • Cluster maintenance mode: You can now put a whole cluster into maintenance mode while you work on it, which blocks Deployment changes on that cluster while leaving Airflow and read access untouched. In 2.1, the cluster-level control is available through the APC API only. You can cordon individual Deployments from the Deployment Actions menu in the APC UI. See Cordon and uncordon a Deployment.
  • Kubernetes security policy compatibility: The defaults that APC ships now conform to Pod Security Standards Restricted. See Configure security contexts.
  • Private CA trust for git-sync HTTPS: A new cluster-scoped setting, astronomer.houston.config.deployments.privateCaCertSecretNames, names the Secrets holding the private certificate authority bundles that git-sync HTTPS clones should trust. See Deploy Dags with git-sync.
  • More component resources configurable per Deployment: PgBouncer and StatsD CPU and memory can now be set from the Deployment settings page, and the API server now honors over-provisioning factors. On Deployments using the Celery executor, Redis can be set the same way. Component defaults, minimums, and limits are also listed in the APC API configuration, so you can see the current values before you override them. See Configure component size limits.
  • ClusterIP ingress: For clusters whose policy forbids LoadBalancer and NodePort Services, you can now set nginx.serviceType: ClusterIP and front the Service with your own load balancer. The default remains LoadBalancer. See Network configuration.
  • Node exporter tolerations documented: The toleration that lets prometheus-node-exporter run on every node is now listed in the Helm configuration reference, so you can find and override it if your cluster policy restricts tolerations. The toleration and its default are unchanged. See Helm configuration reference.
  • Dag server backup annotations: The Dag server now accepts annotations and podAnnotations, so its persistent volume can be included in Velero backup policies.
  • APC UI performance and polish: The initial page load is significantly faster — the Monaco editor is slimmed down, heavy routes are lazy-loaded, and responses are gzipped. Deployment actions are consolidated into a single Actions menu in the Deployment header. The configuration editors gain an Expand All control so search reaches collapsed YAML, a confirmation step before Update Cluster, and guidance in place of a blank Workspace override editor. The Airflow environment variable list in the Deployment UI now reflects Airflow 3. References to “Houston” are replaced with “APC API”, and the System Admin tab is now System.
  • Duplicate Workspace label pre-upgrade check: The upgrade now checks for duplicate Workspace labels before it runs, instead of failing partway through the database migration.
  • SSHRemoteJobOperator: A new deferrable operator in the SSH provider runs a command on a remote host as a detached job and streams its log back into the Airflow task log. The job keeps running if the SSH connection drops or the worker restarts, and it doesn’t hold a worker slot while it waits. Use it instead of SSHOperator for long-running remote jobs.

​
Bug fixes

  • Fixed an issue where the Deployment detail page in the APC UI rendered blank, with no loading indicator, while the Deployment query was still pending.
  • Fixed an issue where Deployment historical metrics rendered blank in the APC UI.
  • Fixed an issue where PgBouncer extra configuration was appended to the defaults instead of overriding them.
  • Fixed an issue where apiServer resource requests were silently overwritten with the limit values through upsertDeployment on Airflow 3 Deployments.
  • Fixed an issue where the NO_PROXY matcher did not normalize trailing-dot fully-qualified domain names, so requests to matching internal hosts were still routed through the corporate proxy.
  • Fixed an issue where the Pilot component used a hardcoded Helm release name, blocking control plane and data plane failover on installations that use a different release name.
  • Fixed an issue where failover validation timed out on Deployments with the auth sidecar enabled.
  • Fixed an issue where the upgrade-deployments script published a near-empty NATS payload, dropping globalDeploymentsConfig from the Deployments it updated.
  • Fixed an issue where the System Admin sidebar tab was visible to every system role, including SYSTEM_VIEWER and SYSTEM_EDITOR.
  • Fixed an issue where the cluster configuration page’s Learn more link pointed to a broken URL, because the APC API had no configGovernance documentation URL in its defaults.
  • Fixed an issue where the Cluster Deployments Configuration section heading in the APC UI did not describe the settings it contained.
  • Fixed an issue where the failure messages for team_system_role_binding.create and team_system_role_binding.delete were grammatically incorrect.
  • Fixed an issue where PgBouncer resource customizations set through platform Helm values were not applied to Deployments.
  • Fixed an issue where hard-deleting a Deployment left its Airflow metadata database, database users, and namespace pool slot orphaned, even though the operation reported success.
  • Fixed an issue where secondary database users were not cleaned up when a Deployment was deleted.
  • Fixed an issue where a Deployment reported a status other than HEALTHY while all of its Pods were Running, because the Pod phase check read only the first result of a multi-Pod query.
  • Fixed an issue where the Deployment page returned a 404 error when a gRPC call to the data plane failed, instead of loading the page and surfacing the error.
  • Fixed an issue where the APC API worker was not restarted after a platform upgrade.
  • Fixed an issue where an upgrade from Astronomer Software 0.37 on Azure Red Hat OpenShift failed when a Deployment switched deployment types.
  • Fixed an issue where permission denials from the APC API surfaced as INTERNAL_SERVER_ERROR rather than FORBIDDEN, and where a global error handler redirected the entire APC UI, presenting a per-resource permission error as a logout.
  • Fixed an issue where a deploy rollback failed with an error pulling the Docker manifest for the target image.
  • Fixed an issue where Elasticsearch and registry naming overrides were not applied.
  • Fixed an issue where OpenShift installations could not set podSecurityContext independently of the OpenShift flag.
  • Fixed an issue where the data plane metadata ConfigMap was mangled into a quoted string by trailing whitespace, and where the metadata endpoint inferred the protocol instead of returning the full URL.
  • Fixed an issue where a cleanup job failed for Airflow 3 Deployments.
  • Fixed an issue where enabling external Elastic search via global.customLogging.enabled=true created a duplicate Ingress for the same host by also rendering the in-cluster Elasticsearch ingress.
  • Fixed an issue where Prometheus proxy targets were incorrectly generated for unified-mode clusters after the default data plane cluster name changed to default.
  • Fixed an issue where DR incorrectly deleted namespaces for namespace pools.
  • Fixed an issue where databases were not cleaned up properly when using manualReleaseName.
  • Fixed an issue where the Helm chart included an incorrect Grafana config map mapping.
  • Fixed an issue where the data plane failover network policy referred to the wrong port when the auth sidecar was enabled.
  • Fixed an issue where the data plane failover network policy used a hardcoded release name instead of the installation’s release name.
  • Fixed an issue where StatsD did not reload after a change to its mapping configuration.

​
Known issues

  • The chart version shown in the APC UI is stale after a helm rollback under control plane reliability. The Control Planes page keeps showing the pre-rollback version, and that stale value also feeds the version-eligibility gate. As a workaround, revert with helm upgrade to the target version rather than helm rollback. The reported version corrects itself within one heartbeat interval.
  • Per-deployment migration has no rollback. A migration removes the Deployment from the source cluster before creating it on the destination, so a destination failure leaves it installed on neither. No data is lost, but the Deployment is down until you re-run the migration. As a workaround, verify destination capacity and image availability first, and migrate a single Deployment before you move a batch.
  • Adopting a Deployment rewrites a digest-pinned image to a tag reference. If an Airflow custom resource references its image by digest, adoption rewrites it to a tag built from the Deployment’s Astro Runtime version on the first apply. As a workaround, re-tag the image and reference it by tag before you adopt.
  • Some changes to an adopted Deployment are ignored. Worker count, worker resources, and KEDA autoscaling changes made through APC don’t take effect, because the operator still owns those fields. Change them on the Airflow custom resource instead.
  • Data plane failover can stall if Commander is unavailable for several minutes during a failover. This is carried forward from 2.0. As a workaround, restart the Pilot Deployment in the affected cluster and the failover resumes.
  • Switching a Deployment to Dag-only deployment mode fails on Azure Red Hat OpenShift, because the security context constraint rejects the configured runAsUser.
  • Changes to roles made on the Workspace or Deployments (for Users, Teams, or ServiceAccounts) details pages are applied successfully, but the UI does not update immediately. Refresh the page to see the latest role assignment.
  • When a large number of custom roles are configured, some roles might not be visible by default on the Roles and Permissions page. As a workaround, use the Scope dropdown to filter by the appropriate scope. For example, select Scope: Workspace to view all custom Workspace roles.
  • Newly assigned roles might not appear in the Show all view on the Roles and Permissions page until you refresh the page or toggle the Hide others button. The assignment is saved; only the display is stale.

​
Resolved CVE list

​
Product lifecycle, support, and compatibility matrix

​
July 7, 2026
Astro Private Cloud 2.0.1 is a security patch release that also resolves a number of platform, logging, and deployment bugs.

​
Security enhancements

  • Patched the Critical and High severity CVEs identified against Astro Private Cloud 2.0.0. See the Resolved CVE list.

​
Bug fixes

  • Fixed an issue where the dagOnlyDeployment Dag-server Pod crashed with Permission denied while 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 Deployment config override updates were rejected when overProvisioningFactorCPU or overProvisioningFactorMem were set to fractional values such as 0.5, because the generated schema typed these fields as integers.
  • Fixed an issue where the Vector DaemonSet entered CrashLoopBackOff on install because the Vector configuration retained a graphql field that was removed in Vector v0.55.0.
  • Fixed an issue where logs from tasks in a task group (with prefix_group_id=True, the default) did not appear in the Airflow UI or ship to Elasticsearch when using the Kubernetes executor with Vector sidecar or daemonset logging, because the Vector log-path pattern did not account for dots in dag_id and task_id values.
  • Fixed an issue where AIRFLOW__LOGGING__REMOTE_BASE_LOG_FOLDER was silently overridden with an empty value on all Astro Runtime 3.x Deployments, ignoring values set through the Deployment environment variables, the Dockerfile, or mounted secrets.
  • Fixed an issue where Airflow workers scheduled into a different namespace than their Deployment could not reach the execution API, because the execution API URL used a relative service name instead of a fully-qualified domain name.
  • Fixed an issue where Celery worker liveness and readiness probes failed on container images without the hostname binary, such as UBI-based Astro Runtime images, causing Kubernetes to restart healthy workers. The probe now resolves the hostname through Python.
  • Fixed an issue where the APC API routed requests to internal hosts through the corporate proxy despite matching NO_PROXY entries, because the matcher did not handle bare hostnames, *.host wildcards, single-label hostnames, or trailing-dot fully-qualified domain names.
  • Fixed an issue where git-sync-relay Pods failed to schedule on OpenShift because hardcoded fsGroup and runAsUser values fell outside the namespace-allocated UID and GID range enforced by the restricted-v2 security context constraint.
  • Fixed an issue where the APC API database migration that adds a unique constraint on Workspace labels failed with error P3009 when duplicate Workspace labels existed, blocking all later migrations and preventing the APC API from starting. The migration now resolves duplicate labels before it creates the constraint.
  • Fixed an issue where a failed APC API database migration surfaced raw Prisma error messages that pointed operators to tooling not available in APC. Migration errors now include APC-specific guidance and links to Astronomer documentation and support.
  • Fixed an issue where the platform-labeller pre-install Job did not include imagePullSecrets, causing ErrImagePull on installations that use a private registry.
  • Fixed an issue where setting astroUI.volumeMounts produced invalid YAML in the Astro UI deployment template, causing the Helm release to fail to render.
  • Fixed an issue where the Astro UI built log queries using an incorrect internal Elasticsearch proxy service name, causing log retrieval to fail with a DNS resolution error.
  • Fixed an issue where the data plane metadata endpoint returned an empty registry.version instead of the registry image tag.
  • Fixed an issue where the data plane internal API that the APC API interacts with silently ignored an unparseable COMMANDER_DATAPLANE_DATABASE_URL and returned an empty database type, leaving operators with no signal about the cause. It now logs a warning, with database credentials redacted, when the URL can’t be parsed.
  • Fixed an issue where failover-related error messages in the APC API were logged as [object Object] instead of readable text.
  • Fixed an issue where the private CA trust script for containerd 2.x removed the GKE Docker Hub pull-through mirror. The script now preserves the mirror configuration.
  • Fixed an issue where the git-sync configuration form rejected valid SSH repository URLs that use a non-standard username, such as a service account, instead of git.
  • Fixed an issue where NFS-backed DAG deployments created a persistent volume claim whose name did not match the claim referenced by the dag-processor, triggerer, and API server components, so those Pods failed to mount the DAGs volume.
  • Fixed an issue where a custom COMMANDER_HOUSTON_JWKS_ENDPOINT override for the data plane internal API was reset to its default on every Helm upgrade, causing connection timeouts until it was manually patched.
  • Fixed an issue where registering a data plane failed with a misleading metadata error when the base domain URL included a trailing slash, because the resulting request path contained a double slash.
  • Fixed an issue where an executor disabled by a cluster-level configuration override, such as the local executor, still appeared as an option when creating a Deployment, because the Deployment configuration query did not apply cluster-level overrides.
  • Fixed an issue in the cluster Deployment configuration override where the resource slider could permit values that the save action then rejected, and where wrapping the override in an extra deployments key silently produced an inert configuration. The override now rejects double-wrapped input and returns a clearer out-of-range error.
  • Fixed an issue where the Deployment resource configuration UI did not respect the cluster’s configured default and maximum values for component resources, including scheduler CPU and memory, because the UI did not pass the cluster context to the Deployment configuration query.
  • Fixed an issue where the Vector logging pipeline could silently drop logs from Deployments in namespaces that did not match standard Kubernetes naming, such as those created through manual namespace pools, because a namespace regex filter returned no match instead of checking for a valid namespace.
  • Fixed an issue where a fresh install could hang because the Prometheus filesd-reloader crash-looped when it queried the APC API database before the database migration had created the required tables. The reloader now retries until the tables are available.
  • Fixed an issue where large Airflow 3 environments running many Deployments produced repetitive Dag processor manager logging. Operators can tune how often Dag bundles are checked for changes through bundle_refresh_check_interval.
  • Fixed an issue where Airflow 2 Dag processor manager logs were noisily sent to stdout in containerized Deployments. Operators can control this behavior through dag_processor_manager_log_stdout.

​
Resolved CVE list

​
May 1, 2026
Astro Private Cloud 2.0 introduces three key new capabilities: Data Plane Disaster Recovery for business continuity across clusters, Config Governance for fine-grained control of APC and Airflow configuration, and Control Plane Audit Logging for compliance-grade activity tracking.

​
New features

  • Data Plane Disaster Recovery: Astro Private Cloud now offers cross-cluster and cross-region data plane disaster recovery. You can now trigger a failover of all Airflow Deployments in a data plane from a source cluster to a destination cluster. A failover is triggered via a single action through the Astro Private Cloud API or GUI. Two modes are supported: Controlled, which drains in-flight tasks before promoting the destination (for planned maintenance or migrations), and Forced, which promotes the destination immediately when the source is unreachable (for outages). Data Plane DR helps to enable business continuity and meet regulatory requirements (DORA, OCC, MAS, APRA) that mandate a recovery path for production workloads, and replaces lengthy manual rebuilds with an automated platform operation. See Data plane failover.
  • Config Governance: You can now turn APC and Airflow features on or off at each level of the APC data model: platform, data plane, Workspace, and Airflow Deployment. Platform administrators set defaults at the platform level, and have the option to allow Workspace and Deployment owners to override settings without impacting other Workspaces or Deployments. Config Governance addresses the problem of different teams, use cases, and workloads requiring different feature sets, configurations, and guardrails. With Config Governance, a single Astro Private Cloud installation can manage use cases from a locked-down regulated workload to a permissive experimental deployment, and let Deployment owners fine-tune within the bounds their administrator has set.
  • Control Plane Audit Logging: The Control Plane now emits structured audit events for authentication, authorization, and Airflow Deployment lifecycle actions, including login and logout, permission and role changes, service account creation and revocation, and Deployment create, update, and delete operations. Events are written to the platform log stream alongside existing Control Plane logs, so they can be exported to your existing SIEM or log aggregation tool. Audit logging is a baseline requirement for SOC 2, ISO 27001, PCI-DSS, and the internal controls that banking and insurance customers use. Control Plane audit logs, in addition to the already-available Airflow Deployment audit logs, give compliance and security teams a single, structured source of truth for who did what, when.

​
Additional improvements

  • Cluster-level metric collection: Node exporter and cAdvisor can now be enabled through built-in Helm flags (global.nodeExporter.enabled, global.cadvisor.enabled), both disabled by default. When enabled, four additional panels appear on the Metrics tab for each Deployment in the APC UI: CPU Usage, Memory Usage, Network Rx, and Network Tx. Cluster-level metric collection requires ClusterRole. The feature is disabled by default so the default Astro Private Cloud configuration does not require ClusterRole. See Deployment metrics.
  • Git-sync relay operational metrics: Deployments that use the git-sync relay for DAG deployment can now emit StatsD metrics for sync operations, repository size, and sync performance, giving visibility into git-sync throughput and latency per Deployment. This feature is disabled by default. See Git-sync relay metrics.
  • Data Plane metadata includes custom logging state: The dataPlane metadata response now includes the state of customLogging.enabled, making it visible whether custom logging is active for a given Data Plane without requiring a separate configuration lookup.
  • Strict schema validation for Helm configuration: APC 2.0 introduces a strict schema validator that rejects unknown or misspelled keys in values.yaml before they reach the cluster, replacing the previous silent-ignore behavior. This catches configuration mistakes at install or upgrade time instead of surfacing them as runtime failures. The validator can be temporarily disabled per-Deployment where a newer feature hasn’t yet been added to the schema (for example, git-sync relay metrics in the initial 2.0 release).
  • Direct upgrade path from Astronomer Software 0.37 to APC 2.0: Customers still running Astronomer Software 0.37 can now upgrade directly to APC 2.0 without the intermediate hop through APC 1.0. See Upgrade 0.37 to 2.0.
  • Configurable Prometheus scrape interval and timeout for federated data planes: The scrape_interval for the federated-dataplanes job is now configurable, and a new scrape_timeout setting has been added. This reduces Prometheus load in Control Plane/Data Plane deployments running a large number of Deployments, which previously hit a fixed 5s scrape interval.
  • All images available in Azure Container Registry, as well as Quay and Docker Hub: The APC image set is now mirrored to Azure Container Registry (ACR) alongside Quay and Docker Hub, simplifying installs in Azure-restricted environments.
  • Containerd 2.0 is now supported: The DaemonSet that manages self-signed cert trust for containerd has been updated for GKE 1.33+ (containerd 2.0), and the private CA install instructions are now functional on the latest GKE versions.

​
Bug fixes

  • 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 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 git-sync Deployments failed to become healthy because the git-sync container used deprecated environment variable names.
  • 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 the UI version tooltip displayed an incorrect version after a Helm upgrade due to a version mismatch between the root and sub-chart Chart.yaml files.
  • Fixed an issue where each Airflow task log line appeared twice in the UI when using KubernetesExecutor with Elasticsearch logging via Vector, caused by both log pipelines consuming the same source and writing to the same sink.
  • Fixed an issue where the Elasticsearch host configuration was not automatically generated from data plane metadata, causing the Airflow chart-level property to incorrectly override the Astronomer-owned logging configuration.
  • Fixed an issue where documentation links in the APC UI pointed to a broken URL.
  • 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 errored KubernetesExecutor worker Pods were not automatically cleaned up, causing 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 dag_processor_manager and DAG parsing logs from the scheduler were not exported to Elasticsearch, preventing operators from filtering these logs in Kibana for root cause analysis.
  • Fixed an issue where the dag server did not support mounting private CA certificates, causing deploy revision updates to fail with certificate errors in environments with private CAs enabled.
  • Fixed an issue where git-sync sidecars in DaemonSet logging Deployments emitted JSON logs with numeric level fields, causing Elasticsearch document_parsing_exception errors and breaking task log retrieval in the Airflow UI.
  • Fixed an issue where the APC API update-runtime-check job did not honor HTTP/HTTPS proxy environment variables, preventing the job from reaching the runtime updates endpoint in proxy-configured environments.
  • Fixed an issue where expected error messages in the APC API were logged at the ERROR level, creating confusion during incident triage.
  • Fixed an issue where the Airflow UI redirected to an incorrect OAuth URL after SSO authentication when accessed directly via the Deployment URL, appending the Airflow URL to the OAuth callback path.
  • Fixed an issue where Prometheus recording rules for container CPU and memory metrics silently failed due to kube_pod_info emitting duplicate node labels during Pod scheduling transitions, causing data gaps in Grafana dashboards.
  • Fixed an issue where the deployment configuration UI accepted Scheduler and Worker CPU values that were not multiples of 100 mCPU, which are invalid for Kubernetes-backed deployments. The UI now displays a banner prompting users to enter CPU resources in multiples of 100 mCPU.

​
Breaking Changes

  • Config Governance schema change: The schema used to enable and disable features in values.yaml has changed to support the new Platform → Data Plane → Workspace → Deployment hierarchy. In-place upgrades from APC 1.x and 0.37 are supported through migration scripts that translate existing configurations to the new schema. Review the migration guide before upgrading.
  • astroRuntimeEnabled flag removed: Astro Runtime is now the only supported runtime for Airflow deployments (Astronomer Certified has been deprecated). The astroRuntimeEnabled flag has been removed from houston-api, the APC UI, and the APC Helm charts. Any deployment configs, automation, or GitOps workflows that explicitly set astroRuntimeEnabled must remove that field before upgrading.
  • Default cluster name simplified: Clusters auto-created during a 1.x install or upgrade are now named default instead of default-populated-by-db-bootstrapper. Existing clusters aren’t renamed, but any scripts, IaC, or external tooling that reference the previous name should be updated prior to upgrading.

​
Known Issues

  • Data plane failover may stall if Commander is unavailable for an extended period during a failover: If the Commander component in the Data Plane Kubernetes cluster becomes unavailable for approximately 4–5 minutes during an in-progress failover, the failover can enter a stalled state even after Commander recovers. In this state, some Deployments may not progress, either failing to clean up on the source cluster or failing to come up on the destination cluster. This issue is only observed when Commander itself is unavailable; it does not occur when the entire Data Plane Kubernetes cluster is down. Workaround: Restart the Pilot Deployment in the cluster where Commander was unavailable (either the source or destination cluster, depending on which side experienced the Commander outage). The failover will then resume and complete, marking itself as either successful or failed.

​
Resolved CVE list

​
Product lifecycle, support, and compatibility matrix