Astro Private Cloud release notes

New features

• Worker queues: You can give an operator-based Deployment that uses the Celery executor more than one Celery worker queue. Each queue runs as its own Kubernetes worker Deployment with its own CPU, memory, ephemeral storage, worker count, and worker concurrency, and you can place each queue on a node pool. Create and edit queues in the Worker Queues section of Deployment settings, or pass workerQueues to upsertDeployment. Existing Celery Deployments get a default queue that reproduces their current worker configuration. Worker queues are off by default. Set deployments.workerQueues.enabled to make them available, and deployments.workerQueues.maxPerDeployment to change how many queues a Deployment can have. The default is 10. See Configure worker queues.
• Node pools: Administrators can declare named node pools for a cluster, each with a node selector, tolerations, and CPU and memory ceilings. Users then place a worker queue on a pool by name. When you edit a pool’s node selector or tolerations, the APC UI offers to upgrade the Deployments that use the pool. APC blocks a ceiling reduction that would leave an existing queue over the new limit. The built-in roles gain the cluster.nodePools.* and system.nodePools.* permissions, so add them to any custom role that needs node pool access.
• Per-queue logs and metrics: The Logs page filters worker logs by queue, and each queue card shows its CPU and memory use. CPU and memory metrics require cAdvisor. Without it, the cards show a no-data state.
• Worker autoscaling with KEDA: A worker queue’s size is now a range from minWorkerCount to maxWorkerCount, and KEDA scales the queue within it. Setting both to the same value turns scaling off for that queue. A minWorkerCount of 0 is allowed only where autoscaling is available. Autoscaling requires KEDA 2.20.0 or later and Laminar. APC doesn’t install KEDA, so install it first, then set global.keda.enabled to true and global.keda.namespace to the namespace where KEDA runs. The KEDA operator service account defaults to keda-operator, and global.keda.operatorServiceAccountName changes it. APC creates a service account and related resources in your KEDA namespace. Autoscaling is off by default. Set global.laminar.enabled and deployments.workerQueues.autoscaling.enabled to true to make it available. The scaling poll interval defaults to 30 seconds, and deployments.workerQueues.autoscaling.pollingIntervalSeconds changes it. Worker autoscaling needs the Airflow operator 1.7.0 that ships with this release, because earlier operators drop the scaling trigger without an error. See Configure worker autoscaling.
• Deployment hibernation: You can hibernate a Deployment that runs in Airflow Operator mode, which scales its components to zero, and wake it again later. Hibernation preserves the state of the Deployment. Hibernate and wake a Deployment from the APC UI, with the upsertDeployment mutation, or with the astro deployment hibernate and astro deployment wake commands. Hibernation is off by default. Set deployments.hibernation.enabled to true to make it available, then use config governance to control which clusters, Workspaces, and Deployments can use it. Hibernation requires Laminar and worker autoscaling. While a Deployment hibernates, deploys, configuration updates, and upgrades fail until you wake it. Turning hibernation off at the cluster, Workspace, or Deployment level removes stored hibernation configuration and wakes any hibernated Deployment. See Hibernate Deployments. [confirm: whether alerts pause for hibernated Deployments, APC-1905 is Done with no linked PR, so make no alert-pausing claim until its assignee answers]
• Laminar integration: Laminar is a new data plane component that provides autoscaling, hibernation, Deployment status, and Airflow investigation for operator-based Deployments. Set global.laminar.enabled to true to install it. Pulling the Laminar image from an Astronomer-managed registry requires authentication. If you pull from an Astronomer-managed registry, set laminar.imagePullSecrets to the token that Astronomer provides. By default, APC provisions the Laminar database in your Postgres instance. To use your own database, set laminar.databaseBootstrapper.backendSecretName to a secret that has a connection key. Set laminar.databaseBootstrapper.dbName to name the database independently of the Helm release name. Laminar Kubernetes objects carry a laminar- prefix, so they don’t collide with Airflow components. Existing Deployments use Laminar only after their next update. The data plane internal API authenticates to Laminar with a short-lived signed token, and a NetworkPolicy limits access to Laminar to the data plane internal API. APC also publishes its JWKS at v2/.well-known/jwks.json.
• APC MCP server: A new control plane component lets MCP clients and AI agents manage APC and troubleshoot Airflow Deployments. Set mcpServer.enabled to true to install it. Tools are grouped, and mcpServer.enabledGroups selects the groups. It defaults to platform_read and platform_write, and groups that contain destructive tools are off by default. mcpServer.disabledTools blocks individual tools, and mcpServer.skills.enabled adds the bundled Airflow skills. Requests authenticate with a Workspace service account API key, and APC authorizes each tool call against the caller’s role. The MCP server isn’t supported when global.authSidecar.enabled is true, which includes Istio gateway mode, and the chart fails to render if you enable both.
• Istio ingress: The APC Helm chart can render Istio VirtualService resources for the routes it exposes, so a cluster that uses an Istio gateway instead of NGINX no longer maintains those resources separately. The chart attaches the routes to an existing Gateway and supports control plane and data plane segregation. Set global.istio.gateway.enabled to true to use gateway mode, and set global.istio.gateway.name to the Gateway in <namespace>/<gateway> format. Gateway mode requires global.authSidecar.enabled: true, and the chart fails to render without it.
• CSI volume mount Dag delivery: You can now deliver Dags to a Deployment from cloud object storage that a CSI driver mounts read-only into Airflow. Install a CSI driver for GCS Fuse, S3 Mountpoint, or Azure Blob on the data plane cluster, set deployments.deployMechanisms.objectStorageMountDagDeployment.enabled to true, and select CSI Volume Mount as the Dag delivery option on the pages that create and update a Deployment. The option is off by default.
• Default alerts for Laminar and the Airflow operator: Prometheus now alerts when a Laminar API server or hypervisor container, or the Airflow operator’s manager container, isn’t ready for 5 minutes, and when the Laminar or Airflow operator Deployment has no available replicas for 10 minutes. Both alert groups are on by default. Set prometheus.defaultAlerts.laminar.enabled or prometheus.defaultAlerts.airflowOperator.enabled to false to turn one off, and add your own rules in prometheus.additionalAlerts.laminar and prometheus.additionalAlerts.airflowOperator.
• Secrets from mounted files (Preview): Platform components can now read their secrets from mounted files instead of secretKeyRef environment variables, for clusters that forbid secrets in environment variables. Set global.secretsFromFiles.enabled to true, and set global.dbBootstrapper.secretsFromFiles.enabled to true for the database bootstrapper, which doesn’t follow the global setting. Each component can override the global setting with its own secretsFromFiles.enabled. The feature is off by default and strict: helm upgrade refuses values that would also put one of those secrets in a component’s environment.
• Kubernetes 1.36 and 1.37: APC now supports Kubernetes 1.36 and 1.37. See Kubernetes version support.

Breaking changes

• A write to a Workspace or Deployment configuration override now replaces the stored override instead of merging into it. A key that you leave out of the payload returns to inheriting its value from the tier above. If you call updateWorkspaceDeploymentsConfig or updateDeploymentConfig with a partial override, send the complete override for the scope instead. An empty override is rejected, so use deleteWorkspaceDeploymentsConfig or deleteDeploymentConfig to clear one. Cluster overrides still merge: updateCluster merges the keys you send into the stored cluster override. See Config governance.
• null is no longer valid in cluster, Workspace, or Deployment configuration overrides, and saving one fails with an error that names the key. APC ignores null values already stored in an override, and the tier above applies instead. Before 2.2, a stored null in a Workspace or Deployment override was rendered into the Helm values. Use DELETE_KEY to remove a key, or at the Workspace and Deployment tiers, leave the key out.
• DELETE_KEY now removes keys under deployments.helm.* at every tier, even when a platform default exists, so the Airflow Helm chart’s own default applies. A few protected paths, such as helm.airflow.images and helm.airflow.postgresql, still only withdraw the override. A DELETE_KEY stored before the upgrade on one of these keys now removes it, which can switch a chart feature back on. To turn a feature off, set its value, for example enabled: false. Workspace and Deployment overrides now store DELETE_KEY, so they can remove a value they inherit. See Remove a setting.
• Workspace and Deployment overrides can no longer set helm.ingress.extraIngressAnnotations, helm.airflow.elasticsearch.connection.host, or helm.openshift.enabled, because the data plane supplies them. Workspace overrides also can no longer set namespaceManagement.preCreatedNamespaces, namespaceManagement.manualNamespaceNames.enabled, or namespaceManagement.namespaceFreeFormEntry.preDeploymentValidationHookAllowedHosts. APC ignores a value already stored at one of these paths, and the cluster or platform value applies. Saving the stored value again drops it from the override, and saving a new value fails. Ingress annotations that you added to a Deployment this way no longer reach its ingress after the Deployment’s next update. See Values the data plane supplies.
• A cluster override can no longer set a value that the data plane supplies, such as chart.version. updateCluster and the cluster configuration editor reject a new value, and APC ignores one already stored. Before 2.2, such an override applied until the next metadata update replaced it. To clean one up, set the key to DELETE_KEY in the cluster override.
• Log queries and log streaming, Deployment environment variable updates, Deployment deletion, and deploy revision cleanup now resolve configuration the same way as Deployment provisioning, including Workspace and Deployment overrides. Before 2.2 they read only the cluster configuration. Deploy revision cleanup now uses each Deployment’s own retention window. Check any override that sets a key these operations read.
• The APC API now checks each metadata document from a data plane and rejects the whole document if a field is invalid. A data plane internal API older than APC 2.2 reports namespace pools that are enabled with no namespace names as null. Until you upgrade that data plane, registering it fails and its metadata stops updating. Upgrade the data plane, or list the pool’s namespace names.
• On operator-based Deployments, Airflow parallelism now derives from the Deployment’s worker queues and no longer defaults to 32. A Deployment with one queue at concurrency 16 and one worker moves from 32 to 16, and the change restarts the components that read it. Set AIRFLOW__CORE__PARALLELISM on the Deployment to keep a fixed value.
• On operator-based Deployments, AIRFLOW__CELERY__WORKER_CONCURRENCY has never taken effect, and every worker runs with a concurrency of 16. Set the concurrency in the Worker Queues section instead, then remove the environment variable. A queue’s concurrency can’t exceed 15 per CPU. See Queue settings reference. [confirm: wording with PM and support, APC-1831]
• The APC API and DP-Link now limit their database connection pools to astronomer.houston.prismaConnectionLimit, which now defaults to 20. Previously the default was 5, and neither value applied: each pool sized itself from the node’s CPU count. Size your Postgres max_connections for the APC API replicas times 20, plus the DP-Link Pods. If you set houston.backendSecretName, or set houston.backendConnection without houston.backendSecretConnection: true, add connection_limit to your connection string.
• The Deployments list is now sorted by creation date, newest first, for the APC UI, the Astro CLI, and the APC API.
• The data plane internal API now rejects any request that sets the global airflowPodAnnotations.gke-gcsfuse/volumes annotation to "true", with an error, before it asks Helm to provision the Deployment. Before you upgrade, remove the global annotation from cluster, Workspace, and Deployment overrides, or the next deploy, update, or upgrade of an affected Deployment fails. Set the annotation per component in podAnnotations, or use the CSI volume mount Dag delivery option.
• The Laminar hypervisor now always runs one replica, because it doesn’t support high availability. The laminar.hypervisor.replicas value is removed, and the chart ignores it if you still set it. The Laminar API server’s replica count is unchanged.
• The bundled External Secrets Operator chart no longer processes ClusterExternalSecret and ClusterPushSecret resources by default. If you use them, set external-secrets.processClusterExternalSecret and external-secrets.processClusterPushSecret back to true.
• The houston-cleanup-airflow-db CronJob is removed. astronomer.houston.cleanupAirflowDb.enabled now only controls the cleanupAirflowDb API, and the schedule, olderThan, outputPath, dropArchives, dryRun, provider, bucketName, providerEnvSecretName, tables, readinessProbe, livenessProbe, and startupProbe values are removed, so APC ignores any you left in an override file. To clean up Airflow metadata, call the cleanupAirflowDb query on your own schedule. Pass perClusterConfig: true to clean up every cluster under its own configuration override, as the CronJob did.
• A Workspace-level preDeploymentValidationHook URL must now point to a host that deployments.namespaceManagement.namespaceFreeFormEntry.preDeploymentValidationHookAllowedHosts lists, or match the hook set at the platform or cluster tier. Otherwise, Deployment operations in that Workspace fail with a not on an allowed host error and APC doesn’t call the hook. Only the platform and cluster tiers can set the allowlist. The allowlist is empty by default.

Security enhancements

• Inactive Airflow metadata database credentials are no longer stored in a Deployment’s configuration, and existing records are purged, so the credentials are no longer readable through the APC API.
• Database connection credentials no longer appear in APC API logs.
• The APC API and the data plane internal API no longer write credentials, such as git-sync keys, registry credentials, and Airflow database passwords, to logs, audit events, or error responses. Upgrading doesn’t remove credentials already logged, so rotate any that might be exposed.
• The APC API no longer writes Git sync SSH keys, HTTPS tokens, or webhook secrets to logs or audit events. Rotate any Git sync credentials that might be logged.
• On installations with a separate control plane and data plane, the APC API stored its Airflow database creation credentials in each cluster’s configuration and could return them to any signed-in user. The APC API no longer stores or returns these credentials, and the upgrade removes them from existing records. After you upgrade, rotate the credentials in the secret named by houston.airflowBackendSecretName (by default, the APC API’s own database secret).
• Exporting environment variables to JSON in the APC UI no longer writes the values of secret variables to the file.
• Removed the unmaintained shortid dependency from the APC API. See CVE-2026-67213.
• Patched the CVEs identified against Astro Private Cloud 2.1.3. See the Resolved CVE list.

Additional improvements

• New images: APC 2.2 adds the ap-laminar image, installed by the laminar subchart, and the ap-apc-mcp-server image for the APC MCP server. Both are disabled by default. See Container image reference.
• Platform defaults can reach registered clusters: A cluster can now derive its deployments configuration from the platform defaults that the APC API runs with, so a change to the deployments defaults in your Helm values reaches clusters that are already registered. Derivation is off by default, and upgrading doesn’t turn it on. Set astronomer.houston.config.clusters.configDerive.mode to optIn and opt clusters in one at a time, or set it to on. A cluster that doesn’t derive keeps reading the snapshot of the defaults taken when you registered it. See Derive cluster configuration from platform defaults.
• Data plane metadata reaches the control plane sooner: A data plane now sends its metadata, such as its chart version, namespace pools, and Elasticsearch host, to the control plane over the existing data plane link. A data plane upgrade converges on the control plane without waiting for the scheduled poll, and the scheduled poll remains as a fallback.
• APC API performance: The APC API caches and batches per-request permission lookups, bounds the concurrency of cluster and Deployment batch jobs, and reduces subscription polling, which lowers database load and shortens response times on large installations.
• Grafana link: deployments.metricsReporting.grafana.enabled is no longer fixed to true, so you can hide the Grafana link in the APC UI on an installation that doesn’t use Grafana.
• Ingress objects: Set global.ingress.enabled to false to stop the APC Helm chart from rendering any Ingress objects, for example when you use Istio and run no NGINX controller. The default is true.
• NGINX ingress extraArgs: Set nginx.extraArgs to pass additional flags to the NGINX ingress controller, for example enable-metrics: true.
• Logging sidecar environment variables: loggingSidecar.extraEnv now also applies to the logging sidecar on git-sync and the Dag server, so you can pass secret-backed Elasticsearch credentials when you use customConfig: true.
• Cluster ID labels: APC now applies a clusterid label with the cluster ID to the resources of each Airflow component in Operator-based and Helm-based Deployments, including the Services that Prometheus scrapes. Airflow alerts that keep the Deployment’s labels, such as the scheduler heartbeat alert, show the cluster ID in the alert email. Existing Deployments get the label the next time APC updates them.
• Laminar private CA certificates: Laminar now trusts the private CA certificates listed in global.privateCaCerts, so it can fetch the APC API’s public keys when the APC API uses a private CA.
• Update and roll out together: Set applyToDeployment: true on updateDeploymentConfig to apply the saved configuration right away, so you no longer call upsertDeployment afterward. The default, false, only saves the configuration. Applying also requires permission to upsert the Deployment.
• Laminar metrics: Prometheus no longer stores these unused Laminar metrics: laminar_laminar_hypervisor_monitored_airflow_MonitoredAirflow_run_monitoring_timer_bucket, and the hypervisor metrics hypervisor_laminar_hypervisor_num_upcoming_dag_runs, _num_stuck_queued_dag_runs, _num_non_terminal_dag_runs, _num_monitored_airflow_deployments, _num_delayed_task_instances, _monitored_airflow_scaling_duration_seconds_{created,sum}, _monitored_airflow_run_count_created, _monitored_airflow_monitoring_scrape_duration_seconds_{count,created,sum}, _monitored_airflow_monitoring_duration_seconds_{created,sum}, and _db_scraper_query_duration_seconds_{count,created,sum}. Update any custom dashboards that use them.
• Deployment list sorting: You can sort the Deployments list by Created and Last Updated in the Workspace and System Admin views.
• Airflow operator images: APC no longer replaces the images that a Deployment specifies for PgBouncer, Redis, StatsD, and the exporters with the Airflow operator’s defaults.
• Read-only root filesystem on operator Pods: Airflow Pods and jobs on operator-based Deployments now set readOnlyRootFilesystem by default, which clears Kyverno read-only root filesystem policy warnings. It takes effect the next time APC applies a Deployment. To turn it off, set deployments.securityContext.container.readOnlyRootFilesystem to false at the platform, cluster, Workspace, or Deployment level. The same key also controls Helm-based Deployments. [confirm: whether the 2.2.0 upgrade re-applies Deployments and restarts their Pods, APC-2019]
• DP-Link replicas: The default number of DP-Link replicas, astronomer.dpLink.replicas, drops from 3 to 2.
• Resource defaults: The default worker ephemeral storage request and limit is now 2048Mi, and the minimum and maximum for the worker ephemeral storage component are 1024 and 102400. The built-in executor list moved into code, so deployments.resourceManagement.executors now defaults to an empty list, and your overrides still apply. Check that any override of that list still renders as you expect.
• Operator extraArgs: Set airflow-operator.extraArgs to a map of flags and values, and the chart renders each one as --flag=value, or as --flag when the value is empty.
• “Dag” in messages: The APC UI, APC API errors, and logs now say “Dag” instead of “DAG”. Update any alerts or log queries that match on the old text.

Bug fixes

• Fixed an issue where the usr-local-airflow-copier init container set no resource requests or limits, so Deployment creation failed on a cluster where a Kubernetes LimitRange requires them.
• Fixed an issue where the log index curator deleted the current month’s log index every day, when index naming was monthly and retention was set in days.
• Fixed an issue where the APC UI showed stale config governance values, such as the list of Astro Runtime versions, after a Helm change, until you refreshed the browser page.
• Fixed an issue where the APC UI platform lists, including Workspaces, Deployments, Users, and Teams, showed a spinner indefinitely when their query failed, instead of an error with a retry.
• Fixed an issue where a deploy rollback asked you to confirm twice.
• Fixed an issue where Deployments that pin their Astro Runtime image by digest failed to start with InvalidImageName when customImageSha was enabled.
• Fixed an issue where saving a custom role cloned from the built-in DEPLOYMENT_ADMIN or SYSTEM_ADMIN role failed with Unknown permission key(s). The role catalog now includes the missing permissions deployment.config.unadopt, system.controlPlanes.get, system.controlPlanes.register, system.controlPlanes.update, system.controlPlanes.deregister, and system.regions.update. See Clone a role.
• Fixed an issue where, with custom roles enabled, a custom role could override a user’s built-in role (System Admin, Op, User, or Viewer) in Airflow 2 and Airflow 3. A user’s effective Airflow access is now the most-permissive combination of all of their roles. See How multiple roles combine.
• Fixed an issue where the deploymentCapabilities field of the APC API reported false for Deployment actions that a user was allowed to perform, so the APC UI hid actions such as Delete Deployment, Unadopt Deployment, and Cordon Deployment. This affected System Admins who also held a Workspace Admin or Deployment Admin role when the matching permission, such as deployment.config.delete, was disabled for DEPLOYMENT_ADMIN, and users whose custom role grants the matching system.deployments permission.
• Fixed an issue where a Workspace Admin couldn’t see Unadopt Deployment in the APC UI when deployment.config.unadopt was disabled for DEPLOYMENT_ADMIN, even though the APC API allowed the action.
• Fixed an issue where the APC UI showed Delete Deployment and Unadopt Deployment to a user whose only system permission was system.airflow.admin, even though the APC API refused both actions.
• Fixed an issue where creating a Deployment with upsertDeployment silently replaced an extra_capacity CPU or memory value below the minimum for the Deployment’s executor with the default value, and reported success. The APC API now rejects the request with a Minimum Extra CPU not met or Minimum Extra Memory not met error.
• Fixed an issue where upsertDeployment accepted an extra_capacity CPU or memory value above the maximum set in deployments.resourceManagement.maxExtraCapacity. The APC API now rejects the request with a Maximum Extra CPU exceeded or Maximum Extra Memory exceeded error on both create and update. A Deployment that already exceeds the maximum isn’t affected, but it can’t raise its value above what it has now.
• Fixed an issue where the APC UI and the APC API showed stale values after you updated a Deployment’s environment variables. The APC API now writes the Kubernetes Secret immediately. If the Secret write fails, the update fails and no changes are saved.
• Fixed an issue where users with the deployment.airflow.op or system.airflow.op permission didn’t get the Airflow Op role. These permissions now map to Op on Airflow 2 Deployments and to Airflow User on Airflow 3, which has no Op role.
• Fixed an issue where deleting an operator-based Deployment dropped its Airflow database even when the database was external or you skipped database provisioning.
• Fixed an issue where the data plane internal API crashed during a Deployment rollback when the logging sidecar was enabled but the Deployment had no sidecar-log-consumer container.
• Fixed an issue where the Clusters, Regions, Control Planes, and Permission Audit pages showed bare red error text with no retry. They now show an error with a retry.
• Fixed an issue where the cluster Deployments Configuration editor dropped override keys with a null value, so saving without making any changes listed those keys as Removed.
• Fixed several issues where the APC API didn’t wait for asynchronous work to finish or didn’t handle its errors. Removing a user’s Team bindings and adding a Team to a Workspace now wait for all of their changes to finish. The metrics poller no longer fails when Prometheus is unavailable.
• Fixed an issue where updating a cluster configuration removed unrelated, untouched settings and then failed.
• Fixed an issue where saving a cluster configuration failed at random with Cluster was modified by another update, because data plane heartbeats changed the cluster’s updatedAt value.
• Fixed an issue where a Helm value removed under airflow.registry, airflow.elasticsearch, or airflow.postgresql stayed in an existing Helm-based Deployment after an update. Updates still keep the values that the APC API sets only when it creates a Deployment: airflow.fernetKey, the registry and Elasticsearch passwords, airflow.data, and airflow.airflowDbRef.
• Fixed an issue where enabling namespace pools without listing namespace names caused the APC API to reject every metadata document from the data plane.
• Fixed an issue where DP-Link Pods waited indefinitely for the data plane internal API when the NetworkPolicy ran in unified mode.
• Fixed an issue where a malformed metadata environment variable let the data plane internal API start and then panic on the first provisioning request. It now fails at startup and names the variable.
• Fixed an issue where the data plane internal API started with an empty database type when COMMANDER_DATAPLANE_DATABASE_URL couldn’t be parsed, which surfaced only as a data/dbType must be equal to one of the allowed values error at cluster registration. The data plane internal API now stops at startup and names the variable and the reason in its log, and it trims whitespace around the URL with a warning instead of stopping. Before you upgrade, correct any invalid URL.
• Fixed an issue where installation and database migration failed when the Houston database couldn’t use the hard-coded houston$default schema. Set global.houston.database.schemaName to the schema you want, and change it only on a fresh install.
• Fixed an issue where changing only a Deployment’s label, description, or alert emails restarted the Deployment. These updates no longer apply to the data plane.
• Fixed an issue where an explicit null for a component, label, or description in upsertDeployment overwrote the stored value.
• Fixed an issue where a Deployment that had a failing, crash-looping, or Pending worker queue showed Healthy.
• Fixed an issue where a worker queue couldn’t reach its configured maximum worker count because Airflow parallelism was fixed at 32.
• Fixed an issue where operator-based Celery Deployments couldn’t start a worker because the namespace ephemeral storage quota was smaller than the default worker queue’s request. Each namespace quota is now at least what the Deployment’s components and worker queues need at their maximum, and a configured quota can only raise it.
• Fixed an issue where the PgBouncer metrics-exporter container went into CrashLoopBackOff on operator-based Deployments.
• Fixed an issue where CPU, memory, and network metrics were missing for components with multi-word names, such as api-server and dag-processor, because the APC API relied on a Prometheus label that mis-parsed those names. The APC API now scopes these metrics by the Deployment’s namespace.
• Fixed an issue where the APC API didn’t clear the authentication cookie when it rejected a request with a FORBIDDEN error, so the browser kept sending a token the APC API no longer accepted.
• Fixed an issue where a node pool’s node selector and tolerations never reached the Deployments placed on that pool.
• Fixed an issue where, in unified installations, support images, such as Redis, PgBouncer, the PgBouncer exporter, StatsD, git-sync, and the logging sidecar, stayed on the tags stored when the cluster was registered, so a platform upgrade never moved them forward. A unified cluster that derives its configuration now uses the upgraded defaults. New Deployments get them at once, and existing Deployments get them from the post-upgrade Deployment upgrade, or on their next update if you turn derivation on after you upgrade. To turn derivation on, set astronomer.houston.config.clusters.configDerive.mode to on, or to optIn and then opt the cluster in. This isn’t fixed in control plane and data plane installations, because a data plane doesn’t report its image defaults to the control plane.
• Fixed an issue where deployments configuration that you set in your Helm values under astronomer.houston.config.deployments was silently ignored for clusters that were already registered. The value now applies to clusters that derive their configuration.
• Fixed an issue where a cluster whose stored configuration had runtimeManagement.airflowV3.enabled set to false kept Airflow 3 disabled after you enabled it in the platform configuration, and only a direct database update could fix it. The platform value now applies to clusters that derive their configuration.
• Fixed an issue where dagDeploy.extraEnv was silently dropped depending on whether you set it under deployments.helm.dagDeploy or at the top level. deployments.helm.dagDeploy.extraEnv is now honored.
• Fixed an issue where every chart render created a new signing key pair for the data plane internal API, and Laminar kept trusting the old certificate, so Laminar authentication failed. The key now stays stable across renders. The new astronomer.commander.signingKey.regenerateKeyEachUpgrade value is false by default.
• Fixed an issue where operator-based Deployments always had their extra capacity set to 0, and the APC UI didn’t show the setting. Operator-based Deployments now default to, and are validated against, the executor’s minimum extra capacity, as Helm-based Deployments are. A Deployment stored with 0 is raised to the minimum the next time it’s saved.
• Fixed an issue where a Deployment’s status could change from one refresh to the next when its Pods were in a mix of Failed and Unknown phases.
• Fixed an issue where the Elasticsearch host that the APC API stored for a cluster wasn’t updated when the data plane’s Helm release name or external Elasticsearch setting changed, so Deployments on that cluster kept using the old host.
• Fixed an issue where a data plane that reported an empty Airflow chart version or Helm release name replaced the values the APC API stored for its cluster, which left Deployments with no chart version or an unusable Elasticsearch host. Cluster registration now fails with an error that names the missing value, and the metadata sync keeps the last valid value.
• Fixed an issue where the DP-Link timing values in the APC Helm chart, such as the lease duration, reconnect backoff, and degraded and unreachable thresholds, had no effect because the chart set environment variable names that DP-Link doesn’t read. If you set any astronomer.dpLink timing values, they take effect after you upgrade.
• Fixed an issue where the logging sidecar stopped reading task logs as soon as a worker Pod began terminating, for example during a scale-down, node drain, or eviction, so a task that kept running lost the rest of its logs. The logging sidecar now keeps shipping logs until the worker finishes its task.
• Fixed an issue where an adopted operator-based Deployment with the auth sidecar enabled never became healthy, because the APC API didn’t apply the sidecar’s NGINX ConfigMap, Service, and Ingress.
• Fixed an issue where the Elasticsearch environment variables of an adopted Deployment’s original Airflow custom resource appeared among the Deployment’s environment variables in the APC UI and the APC API, and the APC UI offered them for editing.
• Fixed an issue where the cluster details form in the APC UI reset your changes on every keystroke, so you couldn’t edit a cluster’s name.
• Fixed an issue where, after a failed save of a Deployment’s environment variables, the APC UI showed the error toast again on every keystroke.

Known issues

• Laminar copies each Deployment’s Airflow metadata database credentials into the platform namespace, so anyone with access to that namespace can read them. Restrict access to the namespace.
• Hibernation requires worker autoscaling. Hibernation without KEDA isn’t supported in this release.
• Hibernation schedules created in the APC UI can run an hour off. The APC UI converts schedule times with each time zone’s January offset all year, so time zones that observe daylight saving are an hour off for part of the year, and it can save the wrong hour when the browser’s time zone isn’t UTC. As a workaround, set hibernationSchedules with the upsertDeployment mutation using hibernateAtCron and wakeAtCron cron expressions in UTC, or reopen a schedule after you save it in the APC UI and check the time. The hibernationSchedules list replaces all of a Deployment’s schedules, so include every schedule you want to keep. A fix is planned for a future release.
• Task logs don’t appear for Astro Runtime 3.3 and later with the bundled Elasticsearch 8, because newer Runtime images ship the Elasticsearch 9 client. As a workaround, set the environment variable AIRFLOW__ELASTICSEARCH__ES_COMPAT_WITH=8 on each affected Deployment. [confirm: whether the fix for this ships in 2.2.0, PINF-1027 is In Review and its changes are in beta6; if it ships, move this to Bug fixes]
• The MCP server and Laminar ingresses can ignore the Istio gateway flag. Don’t set global.istio.gateway.enabled and mcpServer.enabled together. Gateway values on migration flights, and a single Istio API version across both charts, are also open.
• In control plane and data plane installations that use the Istio ingress gateway, the elasticsearch-nginx auth subrequest can fail with an SNI error.
• db-bootstrapper writes prisma_connection_limit instead of connection_limit to the connection string, so Prisma ignores it. As a workaround, add connection_limit to the APC API’s connection string.
• An upgrade can leave stale support image defaults stored in a cluster’s configuration in every control plane and data plane installation, and in a unified installation whose cluster doesn’t derive its configuration. As a workaround in a unified installation, set astronomer.houston.config.clusters.configDerive.mode to optIn and opt the cluster in. See Derive cluster configuration from platform defaults. In any installation, you can instead update the cluster configuration and re-upsert the Deployments.
• Worker autoscaling authentication on OpenShift isn’t verified. Test autoscaling on OpenShift before you use it in production.
• If the network path between the control plane and a data plane disappears without closing the connection, for example when the data plane’s load balancer is deleted or replaced, DP-Link doesn’t reconnect to that data plane. Its metadata is then refreshed only by the hourly sync, and failover doesn’t select it as a destination. As a workaround, restart DP-Link with kubectl -n <platform-namespace> rollout restart deployment/<release-name>-dp-link.
• Environment variables set through astronomer.dpLink.env are rendered twice in the DP-Link Pod spec, which can make helm upgrade fail or leave DP-Link running with an old value. Leave astronomer.dpLink.env empty, set the variables on the DP-Link Deployment with kubectl set env, and reapply them after each upgrade.
• A cluster registered on APC 2.0.3 or a later 2.0.x release keeps an incomplete container security context in its stored configuration, so after an upgrade the Pods of its Helm-based Deployments lack allowPrivilegeEscalation: false and capabilities.drop: [ALL]. If an admission policy requires those settings, such as the Kyverno disallow-privilege-escalation and require-drop-all-capabilities policies in Enforce mode, the upgraded Pods are denied and the Deployments stay unhealthy. Operator-based Deployments aren’t affected, because the Airflow operator sets both fields itself. As a workaround, set the complete container security context as a cluster override on each affected cluster before you upgrade. Alternatively, set astronomer.houston.config.clusters.configDerive.mode to on in the values for the upgrade, so the cluster derives the current security context defaults. This makes every cluster that hasn’t opted out derive its configuration, not only the affected ones. See Clusters registered on APC 2.0.3 or later 2.0.x releases.

Resolved CVE list

Security enhancements

• Updated the system Brotli decoder library, libbrotlidec, to 1.2.1 in every APC image that includes it, to resolve CVE-2026-111497, a Critical severity out-of-bounds write in the Brotli decoder.
• Patched the CVEs identified against Astro Private Cloud 2.1.2. See the Resolved CVE list.

Bug fixes

• Fixed an issue where saving a custom role cloned from the built-in DEPLOYMENT_ADMIN or SYSTEM_ADMIN role failed with Unknown permission key(s). The role catalog now includes the missing permissions deployment.config.unadopt, system.controlPlanes.get, system.controlPlanes.register, system.controlPlanes.update, system.controlPlanes.deregister, and system.regions.update. See Clone a role.
• Fixed an issue where, with custom roles enabled, a custom role could override a user’s built-in role (System Admin, Op, User, or Viewer) in Airflow 2 and Airflow 3. For example, a System Admin in a Team with a narrower custom role lost admin access in Airflow. A user’s effective Airflow access is now the most-permissive combination of all of their roles. Built-in roles now apply whether they’re assigned directly or inherited through a Team, and members of local Teams also receive the Team’s built-in Workspace and Deployment role bindings. Behavior doesn’t change when custom roles are disabled. See How multiple roles combine.
• Fixed an issue where the APC UI and the APC API showed stale values after you updated a Deployment’s environment variables. The APC API now writes the Kubernetes Secret immediately. If the Secret write fails, the update fails and no changes are saved.
• Fixed an issue where a Pod could appear more than once in a Deployment’s usage metrics on the Metrics tab. Network traffic is now summed per Pod.
• Fixed several issues where the APC API didn’t wait for asynchronous work to finish or didn’t handle its errors. Removing a user’s Team bindings and adding a Team to a Workspace now wait for all of their changes to finish. The metrics poller no longer fails when Prometheus is unavailable, and a failed notification email no longer causes an unhandled error.
• Fixed an issue where the cluster Deployments Configuration editor dropped override keys with a null value, so saving without making any changes listed those keys as Removed.
• Fixed an issue where a System Admin who is also a Deployment Admin couldn’t delete or unadopt a Deployment in the APC UI when deployment.config.delete was disabled for DEPLOYMENT_ADMIN. This regression was introduced in APC 2.1.0 and affected only the APC UI. The APC API still allowed both actions.

Additional improvements

• Component updates: Updated Grafana to 12.4.14 and the NATS server to 2.15.2.

Resolved CVE list

Security enhancements

• APC images and the Astro CLI 1.46.1 and later no longer trust the eMudhra intermediate certificate authorities whose private keys were disclosed in October 2026. If your installation’s TLS certificate chains through one of them, replace it before you upgrade, because connections that use it fail after the upgrade.
• The APC API and the data plane internal API no longer write credentials, such as git-sync keys, registry credentials, and Airflow database passwords, to logs, audit events, or error responses. Upgrading doesn’t remove credentials already logged, so rotate any that might be exposed. See Respond to Airflow database credentials in APC logs.
• On installations with a separate control plane and data plane, the APC API stored its Airflow database creation credentials in each cluster’s configuration and could return them to any signed-in user. The APC API no longer stores or returns these credentials, and the upgrade removes them from existing records. After you upgrade, rotate the credentials in the secret named by houston.airflowBackendSecretName (by default, the APC API’s own database secret).
• Updated the APC UI dependencies dompurify, react-router, and query-string to patch known vulnerabilities.
• Patched the Critical and High severity CVEs identified against Astro Private Cloud 2.1.1. See the Resolved CVE list.

Bug fixes

• Fixed an issue where Deployments that pin their Astro Runtime image by digest failed to start with InvalidImageName when customImageSha was enabled.
• Fixed an issue where users with the deployment.airflow.op or system.airflow.op permission didn’t get the Airflow Op role. These permissions now map to Op on Airflow 2 Deployments and to Airflow User on Airflow 3, which has no Op role. See Airflow Op role removal and restoration.
• Fixed an issue where removing or renaming a configuration override key that contains dots, such as eks.amazonaws.com/role-arn, left the old key on the Deployment’s ServiceAccount with the value DELETE_KEY. As a result, a DELETE_KEY override written in flat form, such as {"a.b": "DELETE_KEY"}, now removes a key literally named a.b instead of the nested key b under a. Before you upgrade, rewrite any such override in nested form.
• Fixed an issue where Astro Runtime releases set inline in astronomer.houston.runtimeReleasesConfig weren’t mounted into the APC API.
• Fixed an issue where Deployments managed by the Airflow operator with Dag-only deploys enabled mounted volumes that weren’t declared, which prevented their Pods from starting.
• Fixed an issue where PgBouncer couldn’t resolve the Airflow metadata database host after an upgrade to APC 2.1.0, so it lost its connection to the database.
• Fixed an issue where setting readOnlyRootFilesystem: false still mounted an emptyDir volume at /tmp, which hid files that the Deployment image added to /tmp. Airflow containers now use the image’s own /tmp. Updating a Deployment to 2.1.2 restarts all of its Airflow components. See Read-only root filesystem.
• Fixed an issue where NATS metrics were missing from Prometheus after an upgrade from APC 0.37.
• Fixed an issue where NGINX ingress controller metrics were missing from Prometheus on the control plane and data plane.

Additional improvements

• Logs for malformed requests: The APC API now logs requests whose body isn’t valid JSON, with the method, path, and client IP address but not the body.
• Prometheus config reloader memory: The default memory request and limit for the Prometheus config reloader container is now 128Mi, up from 25Mi.
• “Dag” in messages: Messages and logs from the Dag server and client now say “Dag” instead of “DAG”. Update any scripts that match on the old text.
• Object store metric: Prometheus now exposes astro_object_store_operations_total for Airflow object store operations.
• Component updates: Updated bundled components, including NATS 2.15.1, Prometheus 3.15.1, Vector 0.60, Alertmanager 0.34.1, registry 3.1.2, Redis 8.10.2, Grafana 12.4.13, Elasticsearch 8.19.23, and NGINX 1.31.8.

Resolved CVE list

Security enhancements

• Signing out of Astro Private Cloud now ends the session. Previously, signing out cleared only the browser cookie, so a copy of the session token taken beforehand stayed valid until it expired, by default after 24 hours. APC now deletes the session record on every sign-out, instead of only when auth.openidConnect.idpGroupsRefresh.enabled is true.
• The APC API now confirms that a session still exists when it verifies a session token, so a revoked session is rejected instead of being accepted until the token expires. Verification previously checked only the token’s signature and expiry, which left no way to end a session early after a token was exposed.
• The PgBouncer SSL certificate generator Job now sets allowPrivilegeEscalation: false and drops all capabilities. Clusters that enforce the Pod Security Standards Restricted profile through Kyverno previously rejected this Job, which blocked any install or upgrade that sets pgbouncer.sslmode: require.
• Patched the Critical and High severity CVEs identified against Astro Private Cloud 2.1.0. See the Resolved CVE list.

Bug fixes

• Fixed an issue where Airflow metadata database and result backend connection credentials could be written in plaintext to APC API logs and audit records when a Deployment was created or updated with custom or user-defined values through the upsertDeployment mutation or a pre-deployment webhook. APC now redacts customer-managed database credentials written to log lines. Upgrading doesn’t remove credentials that are already stored in your logs or audit records, so review who can access them and how long you keep them. See Respond to Airflow database credentials in APC logs.
• Fixed an issue where read-only root filesystem hardening had no way to be disabled, which could increase Pod scheduling latency past task SLAs on Deployments where copying /usr/local/airflow into the writable volume was slow under load. Set deployments.securityContext.container.readOnlyRootFilesystem: false to disable the hardening — including the usr-local-airflow-copier init container and its volume — on Airflow Deployment containers. See Read-only root filesystem.
• Fixed an issue where the usr-local-airflow-copier init container could permanently enter CrashLoopBackOff on Airflow images containing a read-only file or a dangling symlink under /usr/local/airflow.
• Fixed an issue where Flower didn’t receive the usr-local-airflow-copier init container that scheduler and worker components receive, causing Flower to crash on startup on Deployments that load a custom module, such as a secrets backend, through include.
• Fixed an issue where the usr-local-airflow-copier init container declared no CPU or memory requests or limits, so Deployment creation failed on clusters whose namespaces enforce a LimitRange.
• Fixed an issue where the usr-local-airflow-copier init container ignored the cluster’s default runtime image tag or digest and fell back to the Astro Runtime version, producing a malformed image reference on clusters that pin their default runtime image by digest.
• Fixed an issue where an upgrade failed when in-cluster PostgreSQL was enabled, because the StatefulSet had no writable /var/run/postgresql mount and couldn’t read postgresql.conf. The PostgreSQL configuration files are now regenerated during the upgrade instead of leaving the server unable to start.
• Fixed an issue where the data plane internal API didn’t reset the password of a PostgreSQL user that already existed, so a Deployment recreated after an incomplete cleanup failed with password authentication failed.
• Fixed an issue where the houston-upgrade-deployments and houston-cp-refresh Helm hook Jobs read a global.sslmodeEnabled value that no values.yaml file sets, instead of global.ssl.enabled, so their database connections didn’t use the configured SSL mode.
• Fixed an issue where PodDisruptionBudgets were created for the External Secrets Operator and PgBouncer even when global.podDisruptionBudgets.enabled was false. Both components now respect the platform-wide setting rather than requiring a per-component override.
• Fixed an issue where the Dag server expected a <release-name>-sidecar-config ConfigMap while the Airflow Pods used a sidecar-config Secret when loggingSidecar.customConfig was true, which required creating both objects by hand.
• Fixed an issue where a cluster, Workspace, or Deployment override that replaced deployments.logging.loggingSidecar without extraEnv appended a null entry to the logging sidecar’s env array. Helm schema validation rejected the resulting values, so configuration and Deployment updates failed across the triggerer, scheduler, webserver, Dag processor, and workers.
• Fixed an issue where webhook-triggered git-sync-relay syncs ran concurrently and raced on .git/index.lock, so Dag commits could be missed. A delivery that failed at the end of a burst left the checkout stale until the next push.
• Fixed an issue where git-sync annotations weren’t applied to Deployment Pods, causing Pod startup failures on clusters that run an Istio service mesh. The APC API now supports annotations and podAnnotations for git-sync.
• Fixed an issue where Airflow 3 Deployments using the Kubernetes executor with global.loggingSidecar.enabled: true ingested every task log line into Elasticsearch twice. The injected pod_mutation_hook teed task output to the sidecar log in addition to the structured task log that Airflow 3 already writes, and Vector shipped both copies to the same Elasticsearch sink. The tee now applies to Airflow 2 only, which leaves Airflow 2 behavior unchanged and removes the duplicate documents.
• Fixed an issue where the auth sidecar returned a 404 for an authenticated request to /dags/healthz, because nginx had no location block matching that path.
• Fixed an issue where Deployments on Astro Runtime 9.x failed to start the Airflow webserver and logged No module named 'airflow.providers.fab', because the chart injected an auth_manager class that only exists in Astro Runtime 11.x and later.
• Fixed an issue where the last system admin could be removed, leaving an installation with no administrator and no supported way to restore access. APC now blocks the removal and ships a recovery script for installations already in that state.
• Fixed an issue where a deploy rollback failed with an error pulling the Docker manifest for the target image. APC now authenticates image manifest validation across all registries.
• Fixed an issue where the upgrade-deployments script resolved the target airflow-chart version twice, once for its log output and once for the message it published, so the logged version and the version actually applied could disagree. The APC API now also rejects an empty chart version instead of persisting it.
• Fixed an issue where the Deployments list and a Deployment’s detail page could report different health for the same Deployment at the same time. Every element on a page now reads health from one shared subscription.
• Fixed an issue where the APC API ran a separate health check loop for every open subscription to the same Deployment, each on its own timer. Two people watching the same Deployment could see different health at the same moment, and the platform repeated identical Prometheus queries. The APC API now runs at most one health check loop per Deployment across its replicas, and the Prometheus queries within a cycle run concurrently so that each result is a single point-in-time snapshot.
• Fixed an issue where a change to a custom role wasn’t reflected in the APC UI until you refreshed the page.
• Fixed an issue where role assignments didn’t appear in the Show all view on the Roles and Permissions page until you refreshed the page or toggled Hide others.
• Fixed an issue where custom roles weren’t all visible on the Roles and Permissions page unless you filtered by scope, and where the page rendered empty space instead of scrolling each section independently.
• Fixed an issue where DagOnlyDeploymentDisabledError always named deployments.deployMechanisms.dagOnlyDeployment.enabled as the reason a Dag-only deploy was blocked, even when the actual blocker was deployments.deployMechanisms.configureDagDeployment.enabled.
• Fixed an issue where a permission denial rendered a blank page, an indefinite loading indicator, or a false empty state instead of an Access denied view. Query hooks dropped the INSUFFICIENT_PERMISSIONS error rather than surfacing it, so the affected pages fell through to their loading or empty branch and reported the error only in the browser console.
• Fixed an issue where the Astro Runtime version dropdown in the APC UI continued to show stale values after a config governance change applied through Helm values, until you refreshed the page.
• Fixed an issue where the APC UI prevented a system admin from removing the last Workspace or Deployment admin user or team, even though the APC API allowed the removal. Administrators previously had to delete the role binding directly in the database.
• Fixed an issue where the last Workspace or Deployment admin couldn’t be removed when the role was assigned through an IdP-managed team. The last-admin check now falls back to administrators who hold the role through a custom role before it blocks a removal.
• Fixed an issue where only the last worker setting you changed was applied when you created a Deployment in the APC UI, so changes to worker resources, termination grace period, and worker count overwrote each other.
• Fixed an issue where updateSystemServiceAccount returned a permissions error instead of a validation error when the payload contained an unrecognized role.

Additional improvements

• Human-readable user names in Airflow 3: The Airflow 3 authorization token now carries email, fullName, and userType claims, so Airflow shows a user’s email or name instead of an opaque ID in the audit log, in Triggering User on a Dag run, and on backfills, asset materializations, and Human-in-the-loop responses. Astro Runtime has to supply the other half of this change, so each Astro Runtime line has a minimum version: 3.1-19, 3.2-7, or 3.3-6. On the 3.0 line, 3.0-17 and later cover the audit log only, because Airflow 3.0 has no Triggering User field. These fields keep showing an opaque ID on earlier Astro Runtime versions, and on any version until the platform runs 2.1.1 or later.
• Disable the Grafana link: deployments.metricsReporting.grafana.enabled is no longer hardcoded to true in the Helm chart, so installations that don’t use Grafana can stop the Grafana link from appearing in the APC UI.
• Dedicated jwks-hook service account: The jwks-hook Job no longer shares the data plane internal API’s service account configuration. You can now name and scope its service account independently, so the Job runs with only the privileges it needs rather than inheriting a broader set.
• Relaxed X.509 validation for Dag deploy: A new opt-in cluster setting lets the dag-downloader sidecar connect to a Kubernetes API server whose serving certificate omits the Authority Key Identifier, Subject Alternative Name, or Extended Key Usage extensions. The sidecar’s TLS stack enforces these extensions strictly, which broke Dag deploy entirely on clusters provisioned by older installers. The default remains strict validation.

Resolved CVE list

• CVE-2026-4786
• CVE-2026-6791
• CVE-2026-7210
• CVE-2026-8763
• CVE-2026-12704
• CVE-2026-12802
• CVE-2026-12803
• CVE-2026-12816
• CVE-2026-13506
• CVE-2026-13608
• CVE-2026-14199
• CVE-2026-14682
• CVE-2026-15603
• CVE-2026-17033
• CVE-2026-19475
• CVE-2026-25680
• CVE-2026-25681
• CVE-2026-27136
• CVE-2026-27878
• CVE-2026-32952
• CVE-2026-33814
• CVE-2026-33818
• CVE-2026-39821
• CVE-2026-40345
• CVE-2026-41178
• CVE-2026-42151
• CVE-2026-42502
• CVE-2026-42506
• CVE-2026-42533
• CVE-2026-43871
• CVE-2026-49844
• CVE-2026-54411
• CVE-2026-54515
• CVE-2026-56143
• CVE-2026-56853
• CVE-2026-56858
• CVE-2026-56860
• CVE-2026-56862
• CVE-2026-58059
• CVE-2026-58060
• CVE-2026-59639
• CVE-2026-59642
• CVE-2026-59647
• CVE-2026-59650
• CVE-2026-59889
• CVE-2026-59903
• CVE-2026-59949
• CVE-2026-71497
• CVE-2026-72639
• CVE-2026-72642
• CVE-2026-72645
• CVE-2026-72647
• CVE-2026-72678
• CVE-2026-72679
• CVE-2026-72684
• CVE-2026-72685
• CVE-2026-72686
• CVE-2026-72687
• CVE-2026-75595
• CVE-2026-75596
• CVE-2026-75899
• CVE-2026-75931
• CVE-2026-75975
• CVE-2026-76172
• CVE-2026-77037
• CVE-2026-77063
• CVE-2026-77078
• CVE-2026-77310
• CVE-2026-78605
• CVE-2026-80229
• CVE-2026-80230
• CVE-2026-80231
• CVE-2026-82208
• CVE-2026-82333
• CVE-2026-82417
• CVE-2026-82562
• CVE-2026-84375
• GHSA-2x7j-588g-ccc2
• GHSA-8m3c-c648-2xjj
• GHSA-cc9r-2j5m-2m83
• GHSA-hrxh-6v49-42gf
• GHSA-mhm7-754m-9p8w
• GHSA-mpwr-8vm7-h73f
• GHSA-wmmp-3585-3rmp

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 APC Helm 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.
• New image: APC 2.1 adds the airflow-operator-controller image, which runs the Airflow Kubernetes Operator for Deployments in operator mode. It’s installed only when operator support is enabled. See Container image reference.
• 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 bundled Grafana dashboards rendered synthetic random-walk data instead of No data on recent Grafana versions. The dashboards’ panels declared no explicit datasource, so their queries fell back to Grafana’s built-in test datasource rather than the configured Prometheus datasource, and a panel with no underlying metrics appeared to show real data.
• Fixed an issue where the post-installation notes showed a Grafana URL in data plane mode, even though Grafana only deploys in control plane or unified mode.
• 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

• CVE-2023-26144
• CVE-2025-22872
• CVE-2025-47911
• CVE-2025-58190
• CVE-2026-0864
• CVE-2026-4360
• CVE-2026-7246
• CVE-2026-11940
• CVE-2026-11972
• CVE-2026-12590
• CVE-2026-13149
• CVE-2026-13221
• CVE-2026-13676
• CVE-2026-13697
• CVE-2026-14257
• CVE-2026-14643
• CVE-2026-15157
• CVE-2026-15308
• CVE-2026-16221
• CVE-2026-16728
• CVE-2026-16729
• CVE-2026-18446
• CVE-2026-27141
• CVE-2026-34180
• CVE-2026-39822
• CVE-2026-42151
• CVE-2026-42505
• CVE-2026-54272
• CVE-2026-55170
• CVE-2026-55689
• CVE-2026-55831
• CVE-2026-55833
• CVE-2026-56745
• CVE-2026-56746
• CVE-2026-56819
• CVE-2026-57432
• CVE-2026-59869
• CVE-2026-59871
• CVE-2026-59873
• CVE-2026-59874
• CVE-2026-59875
• CVE-2026-59876
• CVE-2026-59877
• CVE-2026-59881
• CVE-2026-59884
• CVE-2026-59885
• CVE-2026-59886
• CVE-2026-59887
• CVE-2026-59890
• CVE-2026-59898
• CVE-2026-59899
• CVE-2026-59900
• CVE-2026-59901
• CVE-2026-59921
• CVE-2026-67213
• CVE-2026-67214
• CVE-2026-69152
• CVE-2026-69192
• CVE-2026-69198
• CVE-2026-69243
• CVE-2026-69244
• CVE-2026-69247
• CVE-2026-69249

Product lifecycle, support, and compatibility matrix

• For Astro Private Cloud compatibility with Kubernetes, Postgres, and Astro Runtime versions, see Version compatibility.
• For the Astro Private Cloud support lifecycle, see Astro Private Cloud release and lifecycle policy.

Security enhancements

• Updated the system Brotli decoder library, libbrotlidec, to 1.2.1 in every APC image that includes it, to resolve CVE-2026-111497, a Critical severity out-of-bounds write in the Brotli decoder.
• The Airflow operator controller 1.5.10 no longer trusts the eMudhra intermediate certificate authorities whose private keys were disclosed in October 2026. Version 1.5.9 still trusted them because the CA bundle in its base image wasn’t updated. This affects only installations that enable the Airflow operator, which is off by default. If your installation’s TLS certificate chains through one of these authorities, replace it before you upgrade, because connections that use it fail after the upgrade.
• Patched the CVEs identified against Astro Private Cloud 2.0.5. See the Resolved CVE list.

Bug fixes

• Fixed an issue where the APC UI and the APC API showed stale values after you updated a Deployment’s environment variables. The APC API now writes the Kubernetes Secret immediately. If the Secret write fails, the update fails and no changes are saved.
• Fixed an issue where a Pod could appear more than once in a Deployment’s usage metrics on the Metrics tab. Network traffic is now summed per Pod.
• Fixed several issues where the APC API didn’t wait for asynchronous work to finish or didn’t handle its errors. Removing a user’s Team bindings and adding a Team to a Workspace now wait for all of their changes to finish. The metrics poller no longer fails when Prometheus is unavailable, and a failed notification email no longer causes an unhandled error.
• Fixed an issue where the cluster Deployments Configuration editor dropped override keys with a null value, so saving without making any changes listed those keys as Removed.
• Fixed an issue where a Deployment with git-sync enabled showed Unhealthy indefinitely after its git-sync-init init container failed at startup and then succeeded on retry. The APC API no longer counts a past git-sync-init failure when it calculates Deployment status. A Pod that is still blocked on git-sync shows as Deploying.

Additional improvements

• Component updates: Updated bundled components, including NATS 2.15.2, Vector 0.61, Alertmanager 0.34.2, Redis 8.10.3, Grafana 12.4.14, and the NGINX ingress controller 1.15.12.

Resolved CVE list

Security enhancements

• APC images and the Astro CLI 1.46.1 and later no longer trust the eMudhra intermediate certificate authorities whose private keys were disclosed in October 2026. If your installation’s TLS certificate chains through one of them, replace it before you upgrade, because connections that use it fail after the upgrade.
• The APC API and the data plane internal API no longer write credentials, such as git-sync keys, registry credentials, and Airflow database passwords, to logs, audit events, or error responses. Upgrading doesn’t remove credentials already logged, so rotate any that might be exposed. See Respond to Airflow database credentials in APC logs.
• On installations with a separate control plane and data plane, the APC API stored its Airflow database creation credentials in each cluster’s configuration and could return them to any signed-in user. The APC API no longer stores or returns these credentials, and the upgrade removes them from existing records. After you upgrade, rotate the credentials in the secret named by houston.airflowBackendSecretName (by default, the APC API’s own database secret).
• Updated the APC UI dependency dompurify and the APC API dependencies to patch known vulnerabilities.
• Patched the Critical and High severity CVEs identified against Astro Private Cloud 2.0.4. See the Resolved CVE list.

Kubernetes version support

• Astro Private Cloud 2.0.5 now supports Kubernetes 1.36 and 1.37.

Bug fixes

• Fixed an issue where users with the deployment.airflow.op or system.airflow.op permission didn’t get the Airflow Op role. These permissions now map to Op on Airflow 2 Deployments and to Airflow User on Airflow 3, which has no Op role. See Airflow Op role removal and restoration.
• Fixed an issue where setting readOnlyRootFilesystem: false still mounted an emptyDir volume at /tmp, which hid files that the Deployment image added to /tmp. Airflow containers now use the image’s own /tmp. Updating a Deployment to 2.0.5 restarts all of its Airflow components. See Read-only root filesystem.

Additional improvements

• Logs for malformed requests: The APC API now logs requests whose body isn’t valid JSON, with the method, path, and client IP address but not the body.
• Prometheus config reloader memory: The default memory request and limit for the Prometheus config reloader container is now 128Mi, up from 25Mi.
• Airflow 3 role permissions: The Airflow 3 Editor and Admin roles gain dataset create and delete and access to cluster activity and Dag warnings. Admin also gains access to task reschedules.
• Component updates: Updated bundled components, including NATS 2.15.1, Prometheus 3.15.1, Vector 0.60, Alertmanager 0.34.1, registry 3.1.2, Redis 8.10.2, Grafana 12.4.13, Elasticsearch 8.19.23, and NGINX 1.31.8.

Resolved CVE list

Security enhancements

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

Bug fixes

• 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 NGINX metrics were missing from the Prometheus dashboard due to a mismatch in ingress controller component naming.
• Fixed an issue where NATS metrics configuration was missing after upgrading from Astro Private Cloud 0.37 to 1.x or 2.x. The configuration was dropped during the STAN migration and is now restored.

Additional improvements

• Added a default executor configuration fallback. Astro Private Cloud now falls back to the default executor config when the executor section is missing or passed as an empty list. Customer-provided overrides continue to be respected and applied on top of these defaults.

Resolved CVE list

• CVE-2026-13608
• CVE-2026-18924
• CVE-2026-19931
• CVE-2026-80229
• CVE-2026-80230
• CVE-2026-80231
• CVE-2026-82208
• CVE-2026-82209

Bug fixes

• Fixed an issue where read-only root filesystem hardening had no way to be disabled, which could increase Pod scheduling latency past task SLAs on Deployments where copying /usr/local/airflow into the writable volume was slow under load. Set deployments.securityContext.container.readOnlyRootFilesystem: false to disable the hardening — including the usr-local-airflow-copier init container and its volume — on Airflow Deployment containers. See Read-only root filesystem.
• Fixed an issue where the usr-local-airflow-copier init container could permanently enter CrashLoopBackOff on Airflow images containing a read-only file or a dangling symlink under /usr/local/airflow.
• Fixed an issue where Flower didn’t receive the usr-local-airflow-copier init container that scheduler and worker components receive, causing Flower to crash on startup on Deployments that load a custom module, such as a secrets backend, through include.

Breaking changes

• postgres-exporter is upgraded to v0.20.0. The replication_slot collector is renamed to replication_slots (--collector.replication_slot → --collector.replication_slots, --no-collector.replication_slot → --no-collector.replication_slots), and --disable-settings-metrics / PG_EXPORTER_DISABLE_SETTINGS_METRICS are removed — use --no-collector.settings instead. Update any Prometheus alerts, dashboards, or scrape configs that reference the old collector name or removed flags before you upgrade.

Security enhancements

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

Bug fixes

• Fixed an issue where switching a Deployment to Dag-only deployment failed on ARO OpenShift because the generated Pod spec hardcoded runAsUser: 50000, which falls outside the namespace’s SCC-assigned UID range.
• Fixed an issue where the embedded GraphQL Playground landing page at GET /v1 failed with a req.body is not set error, caused by a body-parser 2.x behavior change introduced by the Apollo Server 5 migration. POST requests and the Altair playground were unaffected.
• Fixed an issue where Kuiper reload generated incorrect Prometheus proxy targets for unified-mode clusters, after the default data plane cluster name changed from default-populated-by-db-bootstrapper to default.
• Fixed an issue where the post-installation notes showed a Grafana URL in data plane mode, even though Grafana only deploys in control plane or unified mode.

Additional improvements

• APC UI performance: The initial page load is significantly faster — the Monaco editor is slimmed down, heavy routes are lazy-loaded, and responses are gzipped.

Resolved CVE list

• CVE-2026-4786
• CVE-2026-6846
• CVE-2026-7210
• CVE-2026-7246
• CVE-2026-7383
• CVE-2026-8763
• CVE-2026-9076
• CVE-2026-11940
• CVE-2026-11972
• CVE-2026-12802
• CVE-2026-12803
• CVE-2026-12816
• CVE-2026-13221
• CVE-2026-13506
• CVE-2026-13676
• CVE-2026-13697
• CVE-2026-14257
• CVE-2026-14682
• CVE-2026-16221
• CVE-2026-18446
• CVE-2026-25800
• CVE-2026-33818
• CVE-2026-34180
• CVE-2026-34181
• CVE-2026-34182
• CVE-2026-34183
• CVE-2026-39822
• CVE-2026-40345
• CVE-2026-42151
• CVE-2026-42504
• CVE-2026-42533
• CVE-2026-42764
• CVE-2026-42765
• CVE-2026-44432
• CVE-2026-45445
• CVE-2026-45447
• CVE-2026-54273
• CVE-2026-54274
• CVE-2026-54275
• CVE-2026-54277
• CVE-2026-54278
• CVE-2026-54279
• CVE-2026-54280
• CVE-2026-55831
• CVE-2026-55833
• CVE-2026-56745
• CVE-2026-56819
• CVE-2026-56853
• CVE-2026-56859
• CVE-2026-56862
• CVE-2026-57432
• CVE-2026-58059
• CVE-2026-58060
• CVE-2026-59639
• CVE-2026-59642
• CVE-2026-59650
• CVE-2026-59869
• CVE-2026-59873
• CVE-2026-59874
• CVE-2026-59884
• CVE-2026-59885
• CVE-2026-59886
• CVE-2026-59887
• CVE-2026-59898
• CVE-2026-59899
• CVE-2026-59900
• CVE-2026-59901
• CVE-2026-60005
• CVE-2026-69152
• CVE-2026-69192
• CVE-2026-69244
• CVE-2026-69249
• CVE-2026-73566
• CVE-2026-76905
• CVE-2026-77354

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

• CVE-2026-5079
• CVE-2026-27140
• CVE-2026-27143
• CVE-2026-27144
• CVE-2026-29181
• CVE-2026-32280
• CVE-2026-32281
• CVE-2026-32283
• CVE-2026-32952
• CVE-2026-33810
• CVE-2026-33814
• CVE-2026-33816
• CVE-2026-34986
• CVE-2026-39821
• CVE-2026-39823
• CVE-2026-39827
• CVE-2026-39829
• CVE-2026-39835
• CVE-2026-39836
• CVE-2026-41506
• CVE-2026-42501
• CVE-2026-44432
• CVE-2026-45022
• CVE-2026-45570
• CVE-2026-46597

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.
• New images: APC 2.0 adds the ap-external-secrets image for data plane failover and the ap-node-exporter image for cluster-level metric collection. Both are disabled by default. See Container image reference.
• 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

• CVE-2024-45337
• CVE-2025-15467
• CVE-2025-62718
• CVE-2025-68121
• CVE-2026-4519
• CVE-2026-24051
• CVE-2026-27140
• CVE-2026-27144
• CVE-2026-28387
• CVE-2026-28388
• CVE-2026-28389
• CVE-2026-28390
• CVE-2026-29181
• CVE-2026-29785
• CVE-2026-32280
• CVE-2026-32281
• CVE-2026-32282
• CVE-2026-32283
• CVE-2026-32829
• CVE-2026-32887
• CVE-2026-33186
• CVE-2026-33540
• CVE-2026-33810
• CVE-2026-34986
• CVE-2026-35172
• CVE-2026-39883
• CVE-2026-40175
• CVE-2026-41676
• CVE-2026-41678
• CVE-2026-41681

Product lifecycle, support, and compatibility matrix

• For Astro Private Cloud compatibility with Kubernetes, Postgres, and Astro Runtime versions, see Version compatibility.
• For the Astro Private Cloud support lifecycle, see Astro Private Cloud release and lifecycle policy.