Release Notes

Astro Private Cloud release notes

This document contains release notes for each version of Astro Private Cloud (APC).

Version 1.0 is the latest long-term support (LTS) version of Astro Private Cloud. To upgrade to version 1.0, see Upgrade Astro Private Cloud. For more information about APC release channels, see Release and lifecycle policies. To read release notes specifically for the Astro CLI, see Astro CLI release notes.

Because Astronomer has separate maintenance life cycles for each minor version of APC, the same change can be introduced multiple times across minor versions, resulting in multiple identical release notes. When a new minor version releases, such as version 0.33.0, all changes from previously released versions are included in the new minor version.

If you’re upgrading to receive a specific change, ensure the release note for the change appears either:

  • Within your target minor version.
  • In a patch version that was released before the first release of your target minor version. For example, a change in 0.32.5, which released 12/8/2023, is not guaranteed to appear in the 0.33 series, which released 9/8/2023, unless there is a release note for it in an 0.33 patch. However, all changes in 0.32.1, which released June 12, 2023, are guaranteed to be in the 0.33 series, because 0.32.1 was released before 0.33.0.

1.0

Astro Private Cloud 1.0 introduces architectural and component changes to enable cross-cluster Airflow management, improve security and scalability, and provide access to the most up to date Airflow 3 features.

New Features

  • Separation of the Control Plane and Data Planes: Previously, all product and Airflow components were required to run in the same Kubernetes cluster. In Astro Private Cloud 1.0, you can run the Astro Private Cloud components in one cluster, the Control Plane and Airflow components in a separate cluster, a Data Plane. This enables you to manage Airflow deployments across multiple clusters, regions, or cloud providers from one installation of Astro Private Cloud. As part of this capability, Astro Private Cloud 1.0 introduces a suite of Data Plane management features to help manage Airflow deployments across multiple Data Planes.
  • Airflow 3 support: Astro Private Cloud 1.0 introduces support for Airflow 3, via support for the Astro Runtime version 3.1-2 and later. You can now leverage the last Airflow 3 features in Astro Private Cloud 1.0. Astro Private Cloud 1.0 also introduces a supported upgrade path from Airflow 2 to Airflow 3.
  • New GUI: Astro Private Cloud 1.0 introduces an entirely new user interface, intended to provide a modern and intuitive experience for monitoring and managing many Airflow deployments across teams.

Security Enhancements

  • CVE mitigation strategy: To minimize CVE exposure, some container images that make up the Astro Private Cloud platform have been migrated to Chainguard’s hardened images.
  • Read-only root filesystem: Astro Private Cloud 1.0 introduces the ability to run containers with a fully read-only root filesystem, for customers with security restrictions that prevent higher-level permissions.
  • Disabled running as root: Root permissions were removed from all images.
  • Labels can be added to pods: Labels can now be specified in the Astro Private Cloud helm chart, and propagated to every pod created by airflow-chart, including the apache airflow subchart.
  • Scoped Service Account updates: Updates to Service Accounts can now be more tightly scoped to either system, Workspace, or Deployment level.
  • Removal of ClusterRole requirements from Unified installation modes: When Astro Private Cloud 1.0 is installed in Unified mode, it does not require cluster-scoped permissions (ClusterRole).

Breaking Changes

A complete list of breaking changes and migration steps can be found in the product documentation.

  • Removal of Prometheus Exporters (nodeExporterEnabled, blackboxExporterEnabled) - These exporters generated large volumes of metrics that were often unused, increasing Prometheus data size and impacting performance. To improve efficiency, they are no longer provisioned by default.
  • Replaced NATS Streaming (STAN) with JetStream - The default messaging backend has been migrated from NATS Streaming (STAN) to NATS JetStream, since STAN is now deprecated and no longer actively maintained. JetStream is the recommended replacement, providing improved scalability, reliability, and native support in the NATS ecosystem.
  • Removal of SingleNamespace Mode - SingleNamespace mode was a proposed feature that allowed multiple Airflow deployments to run in the same namespace as platform components. The proposed feature is now deprecated.
  • Removal of Astronomer Units (AU) - The AU (Astronomer Unit) abstraction for resource configuration has been removed. Resource management for Airflow components is now standardized using granular CPU and memory settings.
  • Replacement of Create/Update Deployment Mutations - The createDeployment and updateDeployment GraphQL mutations have been removed. These mutations have been replaced with a single upsertDeployment mutation.
  • Replacement of Fluentd with Vector for DaemonSet-based Logging - The default logging DaemonSet has been migrated from Fluentd to Vector. This provides improvements in performance (lower CPU/memory footprint), reliability, and a simpler configuration model. Daemonset logging is not supported in Airflow 3, so sidecar logging must be enabled for Airflow 3 deployments. See the install guide for how to enable sidecar logging.
  • Removal of enableHoustonInternalAuthorization Flag - The enableHoustonInternalAuthorization flag has been removed. Authentication and authorization are now gated by installation mode.
  • Removal of sysAdminScalabilityImprovementsEnabled flag - This flag enabled a series of internal optimizations to improve scalability and API performance in environments with a large number of users and deployments. The underlying improvements are now part of the platform’s core logic and no longer require feature gating. This simplifies configuration and ensures consistent performance across all environments.
  • Removal of unsupported Runtime Allowance (enableSystemAdminCanUseNonSupportedRuntime) - This flag allowed system administrators to deploy Airflow runtimes that were not officially supported by Astronomer. To ensure reliability, maintainability, and supportability, the platform now strictly enforces supported runtime versions.
  • Removal of updateServiceAccount GraphQL Mutation - the legacy GraphQL mutation updateServiceAccount is removed. You can now use one of the following mutations, depending on the scope of the service account you want to update. Scoped mutations improve security and make it clearer which service account you are targeting for updates.
    • updateSystemServiceAccount (for system-level service accounts)
    • updateWorkspaceServiceAccount (for Workspace-level service accounts)
    • updateDeploymentServiceAccount (for Deployment-level service accounts)

Support Changes

  • Extension of the standard support term from one year to two years.
  • Introduction of a Long-Term Support release channel for support extension to three years for the Astro Private Cloud image versions (not for Airflow or Astro Runtime versions).
  • Introduction of a Mission-Critical support tier.

See more in the Release lifecycle and support policy.

Product Lifecycle and Compatibility Matrix

  • The Astro Private Cloud 1.0 support lifecycle and compatibility with Kubernetes, Postgres, and Astro Runtime versions, can be found in the product documentation. See the Version Compatibility reference documentation.