This document contains release notes for each version of Astronomer Software.
Version 0.37 is the latest long-term support (LTS) version of Astronomer Software. To upgrade to version 0.37, see Upgrade Astronomer. For more information about Software 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 Astronomer Software, 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:
Release date: February 28, 2025
With the Astro CLI version 1.33 release, you can now use additional flags to deploy pre-built docker images from local or remote repositories. These flags include:
--image-name to specify a prebuilt docker image to deploy. This image-name can include a sha.--remote flag.--runtime-version.See Deploy a prebuilt image for more information about prebuilt images and astro deploy for deploy options.
The git-sync feature allows you to deploy DAGs to your Airflow Deployments directly from your GitHub repos, without additional CI/CD configuration. Previously, Astronomer Software had one possible configuration for git-sync, and it only supported DAG deploys and DAG deploy rollbacks. Now, you can customize your git-sync configuration to choose how to fetch changes from the git repo and how that code is stored and shared within the Airflow Deployment with the new flags, repoShareMode and repoFetchMode.
poll and webhook.git-daemon and shared-volumes.Additionally, you can now roll back images only for git-sync deploy revisions through the UI and with the Houston API, allowing you to revert to previous stable images in case of deploy issues or failures. This does not roll back the git configurations.
See Configure git-sync code deploys for more information.
purgeArchive parameter has been replaced with the new parameter, dropArchives.You can now enable setting default, minimum, and independent limits for CPU and memory using Custom Resources with the Houston API, moving beyond the constraints of Astro Units (AUs). This improves flexibility and control over resource allocation. See Use the Houston API on Astronomer Software and Customize resource limits.
houston.config.deployments.componentsCustomDefaultsEnabledhouston.config.deployments.maxExtraCapacity.cpuhouston.config.deployments.maxExtraCapacity.memoryhouston.config.deployments.maxPodCapacity.cpuhouston.config.deployments.maxPodCapacity.memoryYou must enable Custom Defaults in the Houston values.yaml file. For best performance, disable AUs.
Then, configure your custom default values. The following example shows a custom definition for the Airflow Scheduler component.
See Bring your own service accounts for more information about the rbacEnabled flag and the Helm Chart Configuration reference for other options.
config.airgapped.enabled and runtimeReleasesConfigMapName. Set the following configuration following Install Astronomer Software in an Airgapped Environment instructions:extra_au and extra_capacity when creating a Deployment with the new parameter, disableManageResourceQuotasAndLimitRanges. When set to true, you can install Astronomer Software in environments with strict controls over resource quotas and limit ranges. Set to false by default. See Disable management of quotas and limitranges. Use the following configuration:upsertDeployment behavior so that it defaults to the latest available Runtime version when Runtime is enabled, and no Runtime or Airflow version is included.global.extraAnnotations.values.yaml chart with the new configuration variable, podAnnotations. See Helm chart config reference for more details.request and limit for CPU and memory used by default for KubernetesExecutor Pods. See more about configuring custom resources in the UI.enableSelfScrape parameter to false in your Prometheus values.yaml file. This parameter is set to true by default:prometheus.rbac.role.kind and prometheus.rbac.role.create to scope Prometheus-specific roles that can override a global configuration that permits creating other components with cluster-level roles. Use the following configuration:Or, you can disable creating any components with cluster roles, and configure the Prometheus RBAC role specifically.
Astronomer Certified (AC) is no longer supported by Astronomer Software starting in Software v0.37. You must upgrade all existing Deployments from AC to Runtime to upgrade to Software 0.37.
See Migrate to Runtime for migration instructions.
cli-install has been deprecated. Use the instructions at Install the CLI to install the Astro CLI instead.@sha256 when using the Astro CLI or Houston API.route.openshift.io/termination: "edge" are supported for generating routes. You must update your Ingress configurations to use Edge termination for route generation to function properly. If you’re on an older version of OpenShift, route creation should be done manually. See Required Environment Configuration for OpenShift.disableDesiredRuntimeVersion, in your Houston API values.yaml configuration to false:global.storageClass was configured, you could not override it by configuring specific components. Now, you can set a global storageClass configuration, and modify it with specific component definitions, such as prometheus.storageClass.Resolved the following vulnerabilities:
Release date: March 18, 2025
You can now define custom ingress annotations in the Kibana values.yaml chart with the new configuration, ingressAnnotations. Customizing annotations allows you to extend ingress functionality and enable integration with third-party tools, such as monitoring systems, security services, or cloud provider-specific features.
To add custom annotations, you must add ingressAnnotations to your Kibana controller chart, using annotations compatible for any controller.
For example, you can choose one of the nginx annotations to customize its behavior. The following example shows an example of how you can configure your whether or not your Kibana instance receives nginx opentelemetry data with the nginx.ingress.kubernetes.io/enable-opentelemetry annotation.
For more detail about related functionality, see:
If you prefer to allow users to only access the new GraphQL IDE, you can disable access to the original Apollo GraphQL Playground, with a new feature flag. The Apollo GraphQL Playground makes external requests to load assets like JavaScript, CSS, and other resources from external URLs, which means it cannot be used in an airgapped environment or in cases where strict security requirements apply.
To disable the Apollo GraphQL Playground, set the graphqlPlaygroundEnabled feature flag to false in your Houston API configuration in the config.yaml file:
upsertDeployment behavior so that it defaults to the latest available Runtime version when Runtime is enabled, and no runtime or Airflow version is included.runAsNonRoot: true by default.statsd, redis, pgbouncer, pgbouncerExporter, and gitSync are now specified in global.airflow.images. If you have configured custom image values for these components, you will now need to update those configurations under global.airflow.images to ensure they are properly applied.global.storageClass was configured, you could not override it by configuring specific components. Now, you can set a global storageClass configuration, and modify it with specific component definitions, such as prometheus.storageClass.KubernetesPodOperator Pods with xcom_push enabled pulled an external image for the XCom sidecar. It now uses the configured private repository.manageSystemPermissionsViaIdpGroups.enabled was true.system.user.forceDelete permission.deploymentRemoveTeamRole mutation did not delete the specified team ID from the specified Deployment. Now, the delete team function works as expected.fullName key.global.loggingSidecar.repository was ignored, and the DAG server continued to pull the sidecar logging image from the default quay.io/astronomer. The DAG server now correctly pulls the image from the specified custom repository.workspaceDeployment queries would return "executor": null incorrectly.name_provider query filter was not working as expected.auth-sidecar, logging-sidecar, and dag-sync enabled so that Deployments can update with default resources without any insufficient quota issues.runAsUser or fsGroup to null in the podTemplate would break the KubeExecutor on OpenShift. Added support for configurable security context overrides in Pod templates.namespacePools.enabled and sccEnabled were true.Resolved the following vulnerabilities:
Release date: November 13, 2024
You can now set resource requests and limits for all Pods in the Astronomer namespace, which provides more granular control over resource allocation. This helps to ensure that applications have adequate CPU and memory resources, without over-provisioning or under-provisioning.
When you create, update, or upsert a Deployment with the Houston API, you can now use the new parameters, metadataConnectionJson and resultBackendConnectionJson to configure Airflow to use an external database. If you disable the default pgbouncer proxy, use metadataConnection and resultBackendConnection for your external database. See Use a MySQL or PostgreSQL database for metadata or storage for setup information.
You can now configure pre-created Service Accounts (SAs) for all Astronomer and Airflow components or choose to use the default service account configuration. You can also use the registry template to create your custom SAs.
Additionally, this feature allows you to disable Astronomer from creating Roles, RoleBindings, and other SAs in the namespace by setting the global config rbacEnabled to false.
A new IDE is available at /v1/playground as part of the latest update at https://houston.<your-base-domain>/v1/playground. Please note that the default GraphQL Playground remains accessible at https://houston.<your-base-domain>/v1. This new IDE provides enhanced features for a better development experience, while maintaining access to the existing playground for continuity. To learn more about the GraphQL playground, see Develop and test Houston API queries.
You can now configure the resource sizes and limits for the triggerer through the UI or programmatically.
Enhanced the automatically generated description that appears in the Deploy History, providing you with improved metadata about your code deploys.
Added the fluent-plugin-datadog gem to fluentd and upgraded the fluentd version to version 0.14.4.
Included the ability to disable creation of service accounts and rolebindings for the dag-deploy server. Use the following configuration:
You can now create an IdP group by selecting the source type from the full list of sources that are supported by Astronomer Software, including Local, Okta, and Microsoft. This means you do not need a user to log in to the IdP provider to be able to create new Teams. See Import Identity Provider Groups.
Added the ability for ingress-nginx to run with the CAPABILITY_DROP ALL option. This configuration ensures that the NGINX pods run with no Linux capabilities, providing a more secure environment by reducing privileges.
Removed some environment variables used for UI error reporting to Astronomer.
You can now globally configure the cpu and memory limits and requests for auth-sidecar. The following shows an example configuration for your config.yaml:
You can now set the DAG-deploy security context for containers and pods individually using the following code. For container security contexts:
For pod security contexts:
Astronomer Software v0.36 introduces new behavior when defining customizations for liveness and readiness probes for each component.
If you have previously customized liveness and readiness probes, you must now define the full probe in your values.yaml file. See Configure liveness and readiness probes.
The configuration for global.dagOnlyDeployment.image is now deprecated. To use global configs for DAG-only deploys, use the global.dagOnlyDeployment.repository and tag parameters instead. For example, use:
The configuration for global.loggingSidecar.image is now deprecated. To use global configs for sidecar logging, use the global.loggingSidecar.repository and tag parameters instead. For example, use:
Now, you can create a custom tls secret name by defining the tlsSecret value. Previously, the configuration for global.tlsSecret was defined as astronomer-tls by default, and could not be changed. The following example shows how to define the custom name as astronomer-secret:
By default, the Astronomer Software install does not require elevated privileges. This means that the Software container ports are limited to 1024 or greater by default. If you need your install to have exceptions for privileged access, you can update the controller settings in the Helm configs.yaml file by using the following:
The OSS Airflow chart version has been updated to 1.13.5.
Removed the need to set the Runtime version on the Astronomer Software UI prior to performing a Runtime upgrade. You can now skip this extra step and can directly perform the upgrade via the CLI or Houston API with the new RunTime version. See Upgrade Astro Runtime for more information. If you want to follow the legacy workflow, you must change the feature flag, disableDesiredRuntimeVersion, in your Houston API values.yaml configuration to false:
securityContext caused Deployment issues.dag-only code deploy.MANUAL_NAMESPACES_MODE to prevent Commander from creating namespaces automatically, they might still be created. Now, if you enable manual namespace creation, Astronomer Software does not create or edit namespace labels.Resolved the following vulnerability:
Release date: October 14, 2024
Release date: October 4, 2024
Improved the Deployment Rollbacks user experience by alerting you when you enable or disable rollbacks.
Added a new tab, AirflowDowngrade, to the Logging UI to show Deployment rollback status logs.
Added a new tab, DagServer, to the Logging UI to show DAG server events, without requiring you to log in to the kubernetes cluster.
You can now configure K8s tolerations to the containerd DaemonSet. The following example shows a configuration to enable this functionality. Your specific configuration values might be different:
periodSeconds was erroneously called periodSeconds5. You can now set periodSeconds with periodSeconds, as expected.astro deploy command for Deployments with DAG-only deploys enabled. Now, this type of deploy scenario creates a single entry in Deploy History page. Requires Astro CLI version 1.29 or higher.Resolved the following vulnerabilities:
Release date: August 1, 2024
Kubernetes versions 1.25 and 1.26 are not supported in Software version 0.35.2 and future versions. See Kubernetes version support table and policy for a full list of supported Kubernetes versions and the Software versions they correspond to.
The Astronomer Software UI now lists yanked versions of the Astro Runtime. These versions contain potential bugs and are to be used as per user discretion. See Restricted Runtime versions for more information about yanked versions.
Added priorityClass support for fluentd and prometheus-node-exporter daemonsets. Include the following configuration to use this functionality.
Added support for extraEnv to fluentd so that you can pass custom variables. You can use the following configuration for this functionality:
Added persistence section to the DAG server config, which can be passed to the Airflow Helm chart.
When migrating to an Astro Runtime from Astronomer Certified (AC), only AC Versions that are 2.2.5 and greater have equivalent Runtime versions. Previously, you could see equivalent versions of the Astro Runtime you could choose to migrate to in the UI. Now, to see the equivalent version of Astro Runtime for a Deployment running AC in the Deployment Settings page, you need to set the following configuration:
Release date: July 15, 2024
Fixed an issue where if you had a DAG-only deploy, it was possible for users to access its dag-server from any other kubernetes namespace. See Upgrade considerations for 0.35 for more details about the security fix.
Resolved the following vulnerabilities:
Release date: July 1, 2024
Deploy rollbacks are a new way to ensure that your Deployments can keep running after a broken code deploy or upgrade. When you trigger a rollback to a past deploy, your previous image and/or DAG code are redeployed and start running.
To configure deploy rollbacks, see Deploy rollbacks.
You can now configure Astronomer Software to use a MySQL database as the backend for both Houston and your Airflow Deployments. To connect your Astronomer Software installation to a MySQL database, you update the astronomer-bootstrap secret in your cluster to point to your database:
Astronomer Teams can now be created without associating the team to an existing identity provider (IdP) group. Use local Teams to efficiently manage permissions for groups that might not exist in your identity provider.
priorityClass to pods created by templates/trust-private-ca-on-all-nodes/containerd-daemonset.yaml. This allows you to set a high priority class for certain pods to force an evication for important processes.astronomer.houston.config.deployments.registry.protectedCustomRegistry.updateRegistry.host is not set.global.nats.jetStream.enabled = false in the Software platform configuration.astroUnitsEnabled value in values.yaml was not respected when creating Deployments via the Houston API, resulting in Deployment creation failing when the resource strategy is not explicitly specified.lastUsedAt data for a service account was not updated when the service account deployed an Airflow image.dagDeployment server and client resources from being configurable.Resolved the following vulnerabilities:
Release date: November 26, 2024
A new IDE is available at /v1/playground as part of the latest update at https://houston.<your-base-domain>/v1/playground. Please note that the default GraphQL Playground remains accessible at https://houston.<your-base-domain>/v1. This new IDE provides enhanced features for a better development experience, while maintaining access to the existing playground for continuity.
If you prefer to allow users to only access the new GraphQL IDE, you can disable access to the original Apollo GraphQL Playground, with a new feature flag. The Apollo GraphQL Playground makes external requests to load assets like JavaScript, CSS, and other resources from external URLs, which means it cannot be used in an airgapped environment or in cases where strict security requirements apply.
To disable the Apollo GraphQL Playground, set the graphqlPlaygroundEnabled feature flag to false in your Houston API configuration in theconfig.yaml file:
To learn more about the GraphQL IDE, see Develop and test Houston API queries.
You can now define custom ingress annotations in the Kibana values.yaml chart with the new configuration, ingressAnnotations. Customizing annotations allow you to extend ingress functionality and enable integration with third-party tools, such as monitoring systems, security services, or cloud provider-specific features.
To add custom annotations, you must add ingressAnnotations to your Kibana controller chart, using annotations compatible for any controller.
For example, you can choose one of the nginx annotations to customize its behavior. The following example shows an example of how you can configure your whether or not your Kibana instance receives nginx opentelemetry data with the nginx.ingress.kubernetes.io/enable-opentelemetry annotation.
For more detail about related functionality, see:
cpu and memory limits and requests for auth-sidecar. The following shows an example configuration for your config.yaml:https://houston.<your-base-domain>/v1/playground. See Develop and test Houston API queries for more information.deploymentRemoveTeamRole mutation did not delete the specified team ID from the specified Deployment. Now, the delete team function works as expected.Release date: October 14, 2024
For Deployments with DAG-only deploys, added a new tab, DagServer, to the Logging UI to show DAG server events, without requiring you to log in to the Kubernetes cluster.
You can now configure K8s tolerations to the containerd DaemonSet. The following example shows a configuration to enable this functionality. Your specific configuration values might be different:
periodSeconds was erroneously called periodSeconds5. You can now set periodSeconds with periodSeconds, as expected.Resolved the following vulnerabilities:
Release date: July 17, 2024
Fixed an issue where if you had a DAG-only deploy, it was possible for users to access its dag-server from any other kubernetes namespace. See Upgrade considerations for 0.34 for more details about the security fix.
Resolved the following vulnerabilities:
Release date: May 31, 2024
DAG-only deploys are now fully compatible with OpenShift clusters.
You can now configure resource usage for the DAG-only deploy server in your values.yaml file like in the following example:
You can now configure a priorityClass for all Pods created by the Containerd daemonset. This ensures that Pods generated by the daemonset can be reliably spun up on new nodes whenever they’re removed from an existing node. To configure this, add the following lines to your values.yaml file and apply the configuration to your platform:
astroUnitsEnabled value in values.yaml was not respected when creating Deployments via the Houston API, resulting in Deployment creation failing when the resource strategy is not explicitly specified.lastUsedAt value not updating as expected.airflowStratV2 PGBouncer calculation strategy.Resolved the following vulnerabilities:
Release date: April 8, 2024
config.yaml have been replaced with values.yaml.NGinx now has a dedicated service account with only the required permissions for the service
You can now specify an image pull secret for the privateCaCertsAddToHost.certCopier image so that it can pull the image from a private registry.
Added support for Kubernetes 1.29.
You can now define additionalScrapeJobs in the Prometheus Helm chart so that Prometheus scrapes additional jobs on the Astronomer Software cluster. For example, you could add the following configuration to values.yaml to scrape a static job:
houston.config.deployments.resourceProvisioningStrategy.astroUnitsEnabled was not respected when creating Deployments using the Houston API.Resolved the following vulnerabilities:
Release date: February 12, 2024
This update includes a breaking change to the Astronomer Software Helm chart. The setting enableSystemAdminCanUseAllRuntimes no longer exists and has been replaced with:
This new setting changes whether all Admin-level users can view and upgrade to deprecated versions of Astro Runtime from the Software UI.
By default, any user with an Admin-level role (Deployment Admin, Workspace Admin, System Admin) can now upgrade a Deployment to an unsupported version of Astro Runtime using the Astro CLI and the Houston API.
You can additionally set the following value in your values.yaml file to enable these users to view and upgrade to unsupported Runtime versions through the Software UI:
You can now set a Resource Strategy for each Deployment to fine-tune how Astronomer Software reserves resources for the Deployment within the cluster. The new resource strategies don’t use AUs, meaning you can specify the exact CPU/ Memory requests and limits based on the needs of the Deployment. For example, you can configure a Deployment to have significantly more memory than CPU in extra capacity so that memory-intensive tasks are always guaranteed to run. See Customize resource usage for more information.
astro deploy -—dagsYou can now deploy only the DAGs folder of an Astro project to a Deployment. If you only need to deploy DAG code changes, DAG-only deploys are faster and safer than a full image deploy. This also allows you to configure CI/CD pipelines that allow certain team members to only push DAGs, while allowing other team members to push Astro project configuration updates. See Deploy DAGs for more information.
You can now configure a global label that is applied to all Astronomer Software Pods.
You can now filter on release_name when you make a deployments() query to the Houston API.
You can now use containerd-based Astro Runtime images on an Astronomer Software cluster with a self-managed private CA certificate. To configure a self-managed private CA certificate, add the following configuration to your values.yaml file and apply the configuration to your cluster:
You can now make a createDeployment or upsertDeployment query by specifying a Workspace name or label instead of a Workspace ID.
You can now disable the astro-cli Pod to free up resources on your cluster. This Pod is typically only used in airgapped clusters that can’t access https://install.astronomer.io. To disable the Pod, add the following configuration to your values.yaml file and apply the change to your cluster:
Astronomer Software now redeploys your Deployment when you switch your executor type.
You no longer have to manually define your private registry in the configuration for Vector logging sidecars..
updateDeployment queries to ensure that Deployment resource limits and requests are set correctly.Resolved the following vulnerabilities:
Release date: January 19, 2024
Resolved the following vulnerabilities:
Release date: November 20, 2023
In 0.33.2, non-System Admin users can now update Deployments using deprecated versions of Astro Runtime. By default, non-System Admin users can now interact with Deployments using deprecated Runtime versions, but only System Admins can create new Deployments with deprecated Runtime versions. As a result of this change, the enableSystemAdminCanUseNonSupportedRuntime key has been replaced with enableSystemAdminCanUseAllRuntimes. To set the new flag, add the following configuration to your values.yaml file:
You can now configure a global index name prefix to use for both Fluentd and sidecar-based logging, which allows Astronomer Software to retain logs when you migrate between logging solutions. To enable this feature, add the following lines to your values.yaml file:
Deprecated Kubernetes 1.23
invites query returned an error instead of an empty array when no users invites were found.Resolved the following vulnerabilities:
Release date: October 13, 2023
astronomer.auth.microsoft.useExternalProxy: false in your values.yaml file to bypass proxy support for Azure logins.astronomer.registry.serviceaccount in your values.yaml file.userManagement.enable was false.CreateDeployment request would return a successful response even though no Deployment was created due to no specified Airflow version.ap-blackbox-exporter did not respect global network policies.Resolved the following vulnerabilities:
Release date: September 8, 2023
Astronomer Software can now automatically scale the size of PGBouncer connection pools based on your Airflow component counts and Airflow configuration, instead of solely based on total AU. This improves performance, scalability, and utilization of database connections across all Deployments.
This feature is off by default. You can enable it by setting deployments.pgBouncerResourceCalculationStrategy: airflowStratV2 in your values.yaml file. To revert back to previous behavior, set this key to auStratV1 instead.
prometheus.defaultAlerts.airflow.enabled and prometheus.defaultAlerts.airflow.enabled to false in your Prometheus Helm chart. If you disable these alerts, you can still add back specific alerts or configure custom alerts using prometheus.defaultAlerts.additionalAlerts. See Create custom alerts.elasticsearch.curator.age.timestring when you configure a custom indexing pattern for Vector logging sidecars. The only required value is now astronomer.houston.config.deployments.helm.loggingSidecar.indexPattern.deployments.canUpsertDeploymentFromUI: false to prevent all users besides System Admins from updating Deployments and environment variables through the Astronomer UI.triggerer-log-groomer component.astronomer.houston.config.deployments.components applied only to Deployments that were created after the configuration was set.system.teams.remove permission.properties.email using the upsertDeployment mutation.Resolved the following vulnerabilities:
Release date: February 16, 2024
certCopier image, meaning that you couldn’t pull it from a private registry.Resolved the following vulnerabilities:
Release date: December 8, 2023
You can now configure a global index name prefix to use for both Fluentd and sidecar-based logging, which allows Astronomer Software to retain logs when you migrate between logging solutions. To enable this feature, add the following lines to your values.yaml file:
Deprecated Kubernetes 1.23.
Astronomer Software now throws an error if you attempt to install it with an unsupported version of Kubernetes.
You can now set the following configuration to bypass proxy support when Astronomer Software redirects to Azure login. This might be required in some circumstances when importing identity provider groups as Teams:
userManagement.enable was false.invites query returned an error instead of an empty array when no users invites were found.Resolved the following vulnerabilities:
Release date: October 19, 2023
You can now create a default Kibana index when installing Software.
ap-blackbox-exporter did not respect global network policies.Resolved the following vulnerabilities:
Release date: August 31, 2023
Values.defaultAlerts.airflow.enabled and prometheus.defaultAlerts.platform.enabled to false in your Prometheus Helm chart. If you disable these alerts, you can still add back specific alerts or configure custom alerts using prometheus.defaultAlerts.additionalAlerts. See Create custom alerts.elasticsearch.curator.age.timestring when you configure a custom indexing pattern for Vector logging sidecars. The only required value is now global.loggingSidecar.indexPattern.astronomer.registry.serviceaccount in your values.yaml file.triggerer-log-groomer component.astronomer.houston.enableHoustonInternalAuthorization in your values.yaml file to redirect all authorization requests from the ingress controller to the Houston API internal service endpoint. This can increase performance and decrease network latency.Resolved the following vulnerabilities:
Release date: June 23, 2023
Release date: June 12, 2023
Overprovisioning now also applies to the following components:
You can now configure astronomer.houston.config.deployments.overProvisioningComponents to limit the scope of overprovisioning only to specific Airflow components.
Teams without any users are now automatically deleted when SCIM is disabled.
You can now authenticate to an external storage service for archiving task metadata using Workload Identity.
You can now set prometheus.config.scrape_configs.kubernetes_apiservers.tls_config.insecure_skip_verify in the Prometheus Helm chart.
You can now set astronomer.houston.config.deployments.helm.prometheus.certgenerator.extraAnnotations in your values.yaml file.
You can now configure credentials for a registry backend as Kubernetes secrets in your values.yaml file. See Configure a registry backend.
git-sync-relay containers wouldn’t restart as expected after being terminated.manageSystemPermissionsViaIdpGroups is set to true.Resolved the following vulnerabilities:
Release date: April 28, 2023
You can now clean task data from your Deployments by exporting it to an external storage service. This workflow reduces the amount of data Airflow stores in your Deployment metadata database by archiving data that you don’t need to access on a regular basis. To configure this job, see Clean Deployment task metadata.
You can now programmatically create or update Deployments using the Houston API upsertDeployment mutation. Unlike createDeployment, the upsertDeployment mutation includes keys for configuring Deployment resources such as environment variables. See Create or update a Deployment with configurations.
You can reduce the amount of CPU and memory that an Airflow component requests in development environments, allowing you to more efficiently provision resources based on the requirements for your development Deployments. See Underprovision Airflow resources for configuration steps.
You can now clean task data from your Deployments by exporting it to an external storage service. This workflow reduces the amount of storage Astronomer Software uses by archiving data that you don’t need to access on a regular basis. See Configure a Deployment for configuration steps.
You can assign the System Admin, System Editor, and System Viewer permissions to teams by setting the following values in your values.yaml file:
When coupled with disabling individual user management, this feature allows you to control all user permissions on Astronomer Software exclusively through your identity provider. For more information, see Import IdP groups.
Astronomer Software version 0.32 upgrades PostgreSQL from 11.18.0-1 to 15. If you use in-cluster PostgreSQL for your workflows, upgrading to Software 0.32 without pinning your PostgreSQL version can impact your workflows. See the Upgrade to Postgres 15 for upgrade considerations and steps.
elasticsearch.curator.age.timestring and astronomer.houston.config.deployments.helm.loggingSidecar.indexPattern in your values.yaml file.astronomer.customLogging.extraEnv value in your values.yaml file.astronomer.houston.config.deployments.sysAdminScalabilityImprovementsEnabled key has been replaced with astronomer.houston.config.deployments.performanceOptimizationModeEnabled for improved performance across additional Software UI views.Resolved the following vulnerabilities:
Release date: February 24, 2023
extraVolumes and extraVolumeMounts in the Alertmanager Helm chart, which can be useful for storing secret credentials for services that read your alerts.astronomer.houston.ingress.annotation in the Astronomer Helm chart to configure custom ingress annotations for Houston.yarn upgrade-deployments <deployment-id> from within the Houston Pod.AIRFLOW__LOGGING__REMOTE_BASE_LOG_FOLDER in a Deployment if you were using an Astronomer Certified image.docker/build-push-action GitHub action could produce errors in Houston that affected the entire Astronomer Software installation.Resolved the following vulnerabilities:
Release date: February 2, 2023
You can now configure custom annotations for Houston ingress by setting astronomer.houston.ingress.annotation in your values.yaml file.
The System Admin Deployments list in the Software UI is now paginated.
You can now use the following values in your values.yaml file to configure resource allocation for the git-sync relay service:
astronomer.gitSyncRelay.gitSyncResourcesastronomer.gitSyncRelay.gitDaemonResourcesastronomer.gitSyncRelay.securityContextYou can now set timeoutSeconds for readinessProbe and livenessProbe in the Prometheus Helm chart.
Fixed an issue where Deployments with many DAGs could not be successfully upgraded due to a short timeout.
Houston API now logs an installation’s deployed image versions whenever a GraphQL mutation is completed.
Resolved the following vulnerabilities:
Release date: December 23, 2022
extraFlags for the Prometheus startup command in the Prometheus Helm chart.Resolved the following vulnerabilities:
Release date: December 7, 2022
You can now view task usage metrics from the Software UI.
Task usage metrics provide an overview of your Airflow task runs and can help you quickly identify Deployments where more tasks are running or failing than expected.
To configure the feature, see Set up task usage metrics.
Astronomer Software’s role-based access control (RBAC) system now supports a single root user for each installation. The root user has a non-configurable username and autogenerated password stored as a Kubernetes secret in your installation.
See Manage the root user.
Astronomer Software now supports managing users through System for Cross-domain Identity Management (SCIM), which allows you to automatically provision and deprovision users based on templates for access and permissions. See Manage users with SCIM.
Using the new root user feature, you can now configure Astronomer Software so that users are managed exclusively through Teams. This helps you better integrate with your identity provider (IdP) by ensuring that all users on your platform are authenticated and managed through the IdP. See Disable individual user management.
Astronomer Software 0.31 includes new default resource limits and requests on the following resources:
You might experience OOMKill errors or unexpected behavior after upgrading if you use resources beyond the new default limits. To minimize disruption, view resource usage for these components in Grafana prior to upgrade and compare this usage to the default resource limits in the Astronomer Helm chart.
If your current usage is expected and higher than the default resource limits, update the limits in your values.yaml file before upgrading to Astronomer Software 0.31.
es-client by setting elasticsearch.client.securityContext.capabilities.add={} in the ElasticSearch Helm chart.astronomer.registry.logLevel to filter which types of logs appear in your Docker registry.astronomer.houston.config.useAutoCompleteForSensativeFields=false to disable autocomplete on sensitive fields in the Software UI.astronomer.houston.config.shouldLogUsername=true to include user email addresses in audit logs for logins through the Houston API.httpOnly and secure flags.astronomer.houston.updateRuntimeCheck.url was ignored if not all supported Deployment image versions were present in the destination URL.Resolved the following vulnerabilities:
Release date: September 15, 2023
values.yaml file. See Configure a registry backend.prometheus.defaultAlerts.airflow.enabled and prometheus.defaultAlerts.airflow.enabled to false in your Prometheus Helm chart. If you disable these alerts, you can still add back specific alerts or configure custom alerts using prometheus.defaultAlerts.additionalAlerts. See Create custom alerts.elasticsearch.curator.age.timestring when you configure a custom indexing pattern for Vector logging sidecars. The only required value is now astronomer.houston.config.deployments.helm.loggingSidecar.indexPattern.astronomer.registry.serviceaccount in your values.yaml file.Resolved the following vulnerabilities:
Release date: May 26, 2023
astronomer.customLogging.extraEnv value in your values.yaml file.prometheus.config.scrape_configs.kubernetes_apiservers.tls_config.insecure_skip_verify in the Prometheus Helm chart.astronomer.houston.config.deployments.helm.prometheus.certgenerator.extraAnnotations in your values.yaml file.elasticsearch.curator.age.timestring and astronomer.houston.config.deployments.helm.loggingSidecar.indexPattern in your values.yaml file.deployments.enableSystemAdminCanCreateDeprecatedAirflows to true.global.loggingSidecar.terminationEndpoint in your values.yaml file.Resolved the following vulnerabilities:
Release date: March 2, 2023
extraVolumes and extraVolumeMounts in the Alertmanager Helm chart, which can be useful for storing secret credentials for services that read your alerts.docker/build-push-action GitHub action could produce errors in Houston that affected the entire Astronomer Software installation.Resolved the following vulnerabilities:
Release date: January 11, 2023
timeoutSeconds for both readinessProbe and livenessProbe in the Prometheus Helm chart.AIRFLOW__LOGGING__REMOTE_BASE_LOG_FOLDER in a Deployment if you were using an Astronomer Certified image.Resolved the following vulnerabilities:
Release date: November 3, 2022
astronomer.houston.updateRuntimeCheck.url: true was ignored when searching for new Astronomer Certified and Astro Runtime images.Resolved the following vulnerabilities:
Release date: October 26, 2022
customReceiver in the Alertmanager Helm chart.astronomer.minAstroRuntimeVersion and astronomer.airflowMinimumAstroRuntimeVersion in your values.yaml file.livenessProbe and readinessProbe specific to Prometheus in the Prometheus Helm chart.global.loggingSidecar.extraEnv in your values.yaml file.global.loggingSidecar.resources in your values.yaml file.astronomer.apollo.introspection in your values.yaml file.houston.deployments.components value in Helm could make the Software UI unavailable.namespaceFreeFormEntry: true was set in values.yaml.Resolved the following vulnerabilities:
Release date: September 22, 2022
securityContext for Fluentd Pods and containers.astronomer.houston.config section of the Astronomer Helm chart.Release date: September 12, 2022
Resolved the following vulnerabilities:
Release date: August 29, 2022
A change in 0.30 enabled the trgm extension for PostgreSQL. If you use Azure Database for PostgreSQL as your database backend, you need to enable the pg_trgm extension before upgrading to Software 0.30 using either Azure portal or the Azure CLI. See Azure documentation for configuration steps.
If you don’t complete this setup before your upgrade, the upgrade will fail.
The Software UI now refreshes your JSON web token (JWT) based on the validity of your authentication token from your IdP. This means that as long as you stay logged in to your IdP, you no longer have to refresh the Software UI to continue accessing the Software UI, Astro CLI, and Houston API.
Additionally, if you change a user’s access to Astronomer from your IdP, their permissions will be automatically updated in Astronomer after their current IdP token expires. If you remove a user completely from Astronomer, they are automatically logged out of the Software UI and CLI after their current IdP token expires.
As part of this change, you can now configure jwt.authDuration in your Houston Helm configuration. If a user is logged on longer than authDuration, they will be immediately logged out regardless of the status of their JWT or authentication token.
authUrlParams for your identity provider (IdP) in values.yaml.updateRuntimeCheck.enabled:false did not properly stop an Astronomer Software installation from checking for Runtime updates.values.yaml are now reflected in the Software UI.idpGroupsRefreshEnabled was set to false.Release date: October 11, 2022
(https://github.com/kubernetes/kubernetes/issues/65106) that occurs when you upgrade Helm charts that include duplicate keys in an env array. If you have a Helm chart with duplicate keys and upgrade to Astronomer Software 0.29.3+, all key-value pairs with the duplicate key are removed from your environment.
To preserve duplicate keys in your Helm chart, you can either reapply the values after upgrading, or you can use the --reset-values flag when you run the upgrade script as described in Upgrade Astronomer.
livenessProbe and readinessProbe specific to Prometheus in the Prometheus Helm chart.securityContext for Fluentd Pods and containers in the Fluentd Helm chart.houston.deployments.components value in Helm could break the Software UI.Resolved the following vulnerabilities:
Release date: September 13, 2022
authUrlParams for your identity provider (IdP) in values.yamlenableSystemAdminCanCreateDeprecatedAirflows: trueResolved the following vulnerabilities:
Release date: August 5, 2022
Release date: July 18, 2022
customLogging.enabled=true and loggingSidecar.customConfig=false in your Helm configuration, logs now appear in the Software UI as expected.astro workspace delete.upgradeDeployments=true.Release date: June 3, 2022
releaseName and labeldisplayNameRelease date: June 1, 2022
You can now use Astro Runtime images in your Software Deployments. Additionally, you can now select Runtime images when setting Image Version for a Deployment in the Software UI.
Functionally, Runtime images are similar to Certified images. They both include:
Astro Runtime includes additional features which are not available in Astronomer Certified images, including:
astronomer-providers package, which includes a set of operators that are built and maintained by AstronomerTo upgrade a Deployment to Runtime, follow the steps in Upgrade Airflow, making sure to replace the Astronomer Certified image in your Dockerfile with an Astro Runtime version.
You can now configure a custom container image registry in place of Astronomer’s default registry. This option is best suited for mature organizations who require additional control for security and governance reasons. Using a custom registry provides your organization with the opportunity to scan images for CVEs, malicious code, and approved/ unapproved Python and OS-level dependencies prior to deploying code. To configure this feature, see Configure a custom image registry.
You can now configure logging sidecar containers to collect and export task logs to ElasticSearch. This exporting approach is best suited for organizations that use Astronomer Software in a multi-tenant cluster where security is a concern, as well as for organizations running many small tasks using the Kubernetes executor. To configure this feature, see Export task logs.
The process for configuring namespace pools has been simplified. As an alternative to manually creating namespaces, you can now delegate the creation of each namespace, including roles and rolebindings, to Astronomer Software. While this feature is suitable for most use cases, you can still manually create namespaces if you want more fine-grained control over the namespace’s resources and permissions. For more information, see Namespace pools.
teamFilterRegex in values.yaml to filter out IdP groups from being imported using regexlog_idloadBalancerIP key in the Nginx Helm chartnetworkNSLabels from true to false in values.yamlRelease date: January 26, 2023
Resolved the following vulnerabilities:
Release date: October 14, 2022
Release date: September 21, 2022
authUrlParams for your identity provider (IdP) in values.yamlResolved the following vulnerabilities:
Release date: June 23, 2022
displayNameRelease date: April 8, 2022
groups via the astronomer.houston.config.auth.openidConnect.<idp>.claimsMapping setting in values.yaml.Release date: March 17, 2022
Release date: March 14, 2022
global.external_labels and remote_write options for Prometheus through the Astronomer Helm chart.nodeSelector, tolerations, and affinity in the STAN and NATS Helm charts.Release date: February 22, 2022
Release date: February 15, 2022
You now can import existing identity provider (IDP) groups into Astronomer Software as Teams, which are groups of Astronomer users that have the same set of permissions to a given Workspace or Deployment. Importing existing IDP groups as Teams enables swift onboarding to Astronomer and better control over multiple user permissions.
prefer and require SSL modes for connecting to PGBouncer. You can set this SSL mode via the global.ssl.mode value in your values.yaml file. Note that in v0.28.0, this feature works only with AWS and Azure.grafana.extraEnvVars setting in your values.yaml file.Release date: March 8, 2022
Release date: Feb 22, 2022
To provide more control over resource usage across your organization, you can now limit the ability to create Workspaces only to users with System Admin permissions.
For more information about each role’s permissions, including instructions for how to modify a role’s permissions, see Platform User Management.
houston.config.deployments.enableSystemAdminCanCreateDeprecatedAirflows configuration which enables System Admins to create Deployments with deprecated versions of Astronomer CertifiedRelease date: January 10, 2022
Release date: December 21, 2021
You can now configure a custom OAuth flow as an alternative to Astronomer’s default implicit flow. You can customize Astronomer’s existing Okta, Google, and GitHub OAuth flows, or you can import an entirely custom OAuth flow. For more information, read Configure a Custom OAuth Flow.
You can now configure a Git repo to continually push DAGs to an Astronomer Deployment via git-sync. DAGs deployed via git-sync automatically appear in the Airflow UI without requiring additional action or causing downtime. For more information, read Deploy DAGs via Git Sync.
Custom ElasticSearch logging tools are now supported via new values in your values.yaml file:
By default, the Astronomer CLI uses Docker to execute a few specific commands. As an alternative, you can now configure the Astronomer CLI to use Podman instead. For more information, read Run the CLI with Podman.
values.yaml did not work when NFS DAG deploys were enabled.Release date: March 1, 2022
Release date: January 10, 2022
Release date: December 11, 2021
Resolved the following vulnerabilities:
Release date: November 22, 2021
Apache Airflow 2.2.0 is an exciting milestone in the open source project. Most notably, this release introduces custom timetables and deferrable operators.
Timetables are a powerful new framework that you can use to create custom schedules using Python. In an effort to provide more flexibility and address known limitations imposed by cron, timetables use an intuitive data_interval that, for example, allows you to schedule a DAG to run daily on Monday through Friday, but not on the weekend. Timetables can be easily plugged into existing DAGs, which means that it’s easy to create your own or use community-developed timetables in your project.
For more information on using timetables, read the Apache Airflow Documentation.
Deferrable operators are a new type of Airflow operator that promises improved performance and lower resource costs. While standard operators and sensors take up a Worker or Scheduler slot even when they are waiting for an external trigger, deferrable operators are designed to suspend themselves and free up that Worker or Scheduler slot while they wait. This is made possible by a new, lightweight Airflow component called the Triggerer.
As part of supporting deferrable operators, you can provision multiple Triggerers on your Astronomer Deployments. By provisioning multiple Triggerers, you can ensure that tasks using Deferrable Operators are run even when one Triggerer goes down. For more information about configuring Triggerers and other resources, see Configure a Deployment.
You can now specify a --verbosity flag for all Astronomer CLI commands. When you specify this flag with a CLI command, the CLI prints out Logrus logs as the command runs. This is useful for debugging any errors that might result from a CLI command.
The flag prints out different levels of logs depending on the value that you pass it. Each possible value (debug, info, warn, error, fatal, and panic) maps to a different Logrus logging level. For more information about these logging levels, read the Logrus documentation.
astronomer.global.clusterRoles: false in your values.yaml file and pushing a new RoleBinding to a pre-created Kubernetes namespace.astronomer.houston.config section of your values.yaml file, you can now configure a list of allowedSystemLevelDomains []. If you configure this list, only users with emails from domains specified in the list (for example, <company>.com) can be granted System Admin privileges.nodePort.<release-name>-dags-prod-worker-serviceaccount to release_name-dags-prod-airflow-worker.astronomer.houston.config.deployments.helm.airflow section of values.yaml