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 2, 2026
airflow-chart, including the apache airflow subchart.paginatedWorkspaceUsers returned all role bindings across workspaces when using inline arguments instead of filtering them to the requested workspace.Release date: November 2, 2025
If you are upgrading your EKS cluster from Kubernetes version 1.32 to 1.33 or later, you need to ensure you upgrade from Amazon Linux 2 to Amazon Linux 2023 AMI. See Upgrade from Amazon Linux 2 to Amazon Linux 2023 for more details.
updateSystemServiceAccount GraphQL mutation for system-level service accounts.
updateServiceAccount is now deprecated and should no longer be used.
upsertDeployment mutation.LimitRanges after setting disableManageResourceQuotasAndLimitRanges=true. Both ResourceQuotas and LimitRanges are now correctly skipped when this flag is enabled.fsGroup to the registry Pod security context.dag-downloader sidecar failed to watch updates (HTTP 410: too old resourceVersion), preventing DAG sync. Watch handling now updates from the latest resource version.filesd reloader service by ensuring database sessions are properly closed, eliminating frequent pool exceeded errors.paginatedWorkspaceUsers returned all role bindings across workspaces when using inline arguments instead of filtering them to the requested workspace.Release date: August 12, 2025
Previously, the KubernetesExecutor always set CPU and Memory limits for worker Pods via the Astronomer API and UI, with no option to disable this behaviour. 0.37.5 introduces a new configuration option, workers.resources.enabled for the KubernetesExecutor. When workers.resources.enabled is set to false, Astronomer ignores CPU and memory resource settings from the API/UI, allowing you to define them exclusively through other mechanisms such as Pod mutation hooks, Pod configuration files, or DAG code.
You should use this feature when you need to manage worker resource configurations outside of Astronomer tools. For example, if your organization enforces CPU/memory limits by using admission controllers or custom Kubernetes policies.
Avoid setting workers.resources.enabled to false if you want to manage worker CPU/memory requests and limits through the Astronomer API or UI.
The default KubernetesExecutor configuration is now:
If you’ve configured your KubernetesExecutor so that CPU and memory requests/limits are set at the Deployment level through Houston (instead of at the DAG level), you only need to add the new resources.enabled: false flag to disable resource configuration via the API/UI. This ensures that worker resource settings are applied exclusively from your preferred source, such as Pod mutation hooks or Pod configuration files.
If you use the default KubernetesExecutor worker resource configuration in your Deployments, you can disable automatically creating any worker resource requests and limits. The following configuration sets them as an empty dict.
nodeSelector, affinity, and tolerations configuration for dag-deploy and git-sync-relay components to enable consistent Kubernetes scheduling across all Airflow components. If you have already provided component-specific nodeSelector, affinity, and tolerations, in the Houston Deployment configurations, it takes precedence over the global configuration.Component specific configuration for git-sync-relay:
Airflow-wide configuration:
disableManageResourceQuotasAndLimitRanges=true only disabled ResourceQuotas but not LimitRanges. Both are now properly skipped for consistent resource management behaviour.
LimitRanges were still applied even when disableManageResourceQuotasAndLimitRanges=true. Starting with this release, both ResourceQuotas and LimitRanges are skipped, ensuring consistent and complete disabling of resource constraint management when this flag is set.securityContext blocks in houston-cleanup-deploy-revisions-cronjob.yaml manifest that caused Helm validation failures in strict linting environments.Release date: July 7, 2025
You can now configure the resources and storage provider secret for Airflow database cleanup with new cleanupAirflowDb configuration options, including adding secret environment variables. These configurations improve the previous implementation, which required you to configure Storage provider secrets and other attributes with the Scheduler configuration. See Airflow database cleanup for more details.
In v0.37.0-0.37.3, you defined your Airflow metadata database cleanup job with a combination of scheduler and cleanupAirflowDb configurations. While Software can still accept and successfully complete cleanup jobs using the scheduler configuration, this is now deprecated in favor of using cleanupAirflowDb.
The following parameters allow you to configure your Storage provider secret:
extraVolumesextraVolumeMountsThe following new configurations allow you to define the CPU and memory resources and limits you want to allocate to the cleanup job, instead of inheriting default values from the Scheduler configuration:
resources.limitsresources.requestsThese configurations become the new defaults for your cleanup job if you do not pass any additional configurations in your GraphQL mutation. Additionally, if you don’t use the manual trigger and instead use the cleanup cronjob, these resources also become the new default used when scheduling cleanup jobs. You can use a Houston API query to override these values.
You can also now configure environment variables for your cleanup job with extraEnv:
Changes were introduced in versions 0.37.0 to 0.37.3 that resulted in every KubernetesExecutor task getting ephemeral storage, whether explicitly requested in the dag code or not. Prior to 0.37.0, any task Pod created by the KubernetesExecutor without defined resource quotas fell back to default quota limits of 1AU. See 0.37 Upgrade Considerations for upgrade steps and remediation recommendations.
The new configuration, houston.deployments.executors.workers.ephemeralstorage.disabled, default True, reverts this behavior so that only tasks that explicitly request ephemeral storage receive it, and there is no fallback behavior if dag code does not explicitly request ephemeral storage.
If you have not set ephemeral storage amounts for KubernetesExecutor in your dag, relying instead on the fallback ephemeral storage assignment, you must either update your dag to request ephemeral storage or change houston.deployments.executors.workers.ephemeralstorage.disabled, to False.
Astronomer no longer configures ephemeral storage resources for Deployments using the kubernetesExecutor by default. In 0.37.0-0.37.3, when using Kubernetes Executor, task Pods inherited certain default resource values like ephemeral storage requests and limits from the Celery Worker configuration if specific Kubernetes executor-task-pod values were not explicitly set, even though the KubernetesExecutor and Celery Executor should operate independently. Now, houston.deployments.executors.workers.ephemeralstorage.disabled is set to true by default. This means that Astronomer does not configure any ephemeral storage capacity for Deployments running the KubernetesExecutor, but you can configure ephemeral storage capacity at the dag-level by using Pod overrides.
If you want to define ephemeral storage configurations for Deployments via the Houston API, you must change ephemeralStorage.disabled to false. This allows Kubernetes to apply namespace-level defaults from the Houston API, See Run the Kubernetes executor for more information.
template or tpl() strings for dynamic generation, Houston could not correctly parse and render the template. As a result, Houston did not correctly translate the generated name into the corresponding Airflow service account name. This lead to failures during deploys due to invalid Kubernetes resource names, that violate Kubernetes naming conventions. Now, you can use templates for custom service accounts.nats-exporter has been removed from the new v0.17.3 nats-streaming image. For nats-streaming v0.17.3 and above, the nats-exporter is no longer supported or shipped.dagProcessor and added both liveness and readiness probes for the logGroomerSidecar. See Deployment Resources: Dag Processor and Configure probes: Airflow for more information about how to set up the Dag Processor and configure probes.astronomer.houston.updateRuntimeCheck.url would cause outbound connections for the Runtime check to fail when a proxy config is set. This bug was because the houston-check-runtime-updates.yaml cronjob did not honor the proxy configuration, GLOBAL_AGENT_HTTPS_PROXY. Now, you can add custom URL configurations for the update Runtime Check cronjob with proxy connections enabled.ap-kuiper-reloader to the 0.37.3 Release Notes.Resolved the following vulnerabilities:
Release date: June 3, 2025
podSecurityContext for all Pods deployed by the Astronomer Software Helm chart. See Configure security context for more information about how Astronomer Software uses security contexts, and how to enable them.global.podLabels, to configure Pod labels across all Pods created by the Astronomer chart, including Deployments, statefulsets, cronjobs, jobs, daemonsets, and Helm hooks. This allows you to label Pods created by Astronomer Software and easily search for them using the kubectl get pods command. See Add Pod labels for more information.passwordPolicy, to define the length and number of uppercase, lowercase, number, and special characters required. See the Astronomer Trust Center for documentation of how to set up this configuration.customImageShaEnabled is set to true. See Create a Deployment to learn more about how to create Deployments using a specific Runtime release by specifying its sha256 value.ap-kuiper-reloader. This utility generates targets for statsd and the pgbouncer exporter, which allows Prometheus to use a file-based service discovery mechanism. This removes the need for a cluster role that was previously required when using HTTP-based service discovery. This component is not configurable.astronomer-bootstrap-secret with the wrong component label value if the db-bootstrapper component secret name was customized. Now, Astronomer creates the label as component=astronomer-houston-backend, as expected.TERM signals. Now, tini -- correctly handles args to initiate termination as expected.Resolved the following vulnerabilities:
Release date: May 7, 2025
Kubernetes versions 1.27 and 1.28 are not maintained in Software version 0.37.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.
loggingSidecar container with values.yaml.system.user.forceDelete permission.manageSystemPermissionsViaIdpGroups.enabled was true.global.networkPolicy did not disable network policies for DAG server and Git Sync Relay components. Now, the Airflow network policy configuration covers these components.disableManageResourceQuotasAndLimitRanges prevented the Extra Capacity value from getting calculated, leading to severely undersized PgBouncer pool configurations and degraded UI performance. PgBouncer sizing now correctly uses fallback capacity calculations.dag-processor extra container logic was not working. You can now configure extra sidecar containers for dag-processor.ResourceQuota creation, even when disableManageResourceQuotasAndLimitRanges was set to true. Deployment updates now correctly respect the config flag.Resolved the following vulnerabilities:
Release date: April 18, 2025
As your team and Airflow use cases grow, scaling up your Airflow environment reliably can be a challenge. Complex, dynamically-generated DAGs, sub-optimal DAG parsing practices, or a growing business that requires a larger data pipeline can strain DAG processing and threaten your Airflow scheduler’s availability. Deployments now support high-scale environments more reliably by separating the DAG processor from the scheduler. You can now configure the number of DAG processors for the Deployment from the UI and the Houston API.
This feature is enabled by default. To disable standalone DAG processors for Deployments, set the dagProcessorEnabled feature flag to false in your Houston API configuration in the config.yaml file:
Astronomer Software version 0.37.1 upgrades PostgreSQL from 15 to 17. If you use in-cluster PostgreSQL for your workflows, upgrading to Software 0.37.1 without pinning your PostgreSQL version can impact your workflows. See the Upgrade to Postgres 17 in Astronomer Software 0.37.1 for upgrade considerations and steps.
priorityClassName in the Prometheus StatefulSet, allowing you to set a higher priority for Prometheus during restarts, similar to blackbox exporter and node-exporter. This can be configured in the values.yaml file:network.openshift.io/policy-group: ingress label for ingress resources with the ingressAllowedNamespaces config option in the values.yaml file. ingressAllowedNamespaces will allow users to whitelist the namespaces from which ingress traffic will be allowed to auth-sidecar."executor": null incorrectly.global.sccEnabled is set.auth-sidecar, logging-sidecar, and dag-sync enabled so that Deployments can update with default resources without any insufficient quota issues.git-sync containers were removed from Airflow Pods if you upgrade to 0.37.0 and then updated a pre-existing Git-sync Deployment.ResourceQuota even when disableManageResourceQuotasAndLimitRanges: true was set. Updates now correctly skip quota and limit management when the flag is enabled.dag-server logs were not visible in the UI when using the Vector sidecar.Resolved the following vulnerabilities:
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.See Clean up and delete task metadata from Airflow DB.
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:disableManageResourceQuotasAndLimitRanges: true, all Pods running in the Astronomer Software application will be able to consume unlimited resources on the nodes that they are scheduled on, which can lead to cluster-wide instability. It is strongly advised that users manage their own resourceQuotas and limitRanges when setting disableManageResourceQuotasAndLimitRanges: true.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.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.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.
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