Skip to main content
Archived release notes for Astro CLI versions 1.37 through 1.20.
​
October 14, 2025

​
Support for Astro Private Cloud 1.0

Added support for Astro Private Cloud 1.0, including the ability to push images and dags to separate data plane clusters.

​
Additional improvements

  • The Deployment get, list, and update commands now display a new REMOTE EXECUTION column that indicates if Remote Execution is enabled for a Deployment.
  • References to Astronomer Software have been updated to Astro Private Cloud in the CLI and documentation.
  • A new --workspace-id flag has been added to organization switch for selecting a Workspace programmatically.

​
Bug fixes

  • Update Airflow client to update default_pool correctly by sending only slots and include_deferred with an update_mask.
  • Ignore hidden files during Astro IDE project export.
​
September 10, 2025

​
New Astro IDE commands

Public PreviewThis feature is in Public Preview.
Added the following commands so that you can work with the Astro IDE from the Astro CLI:

​
Additional improvements

Enhanced error handling during Docker image pushes in astro deploy. When a 403 Forbidden error occurs, the CLI now displays actionable troubleshooting guidance, including steps for clearing Docker credentials, disabling the containerd snapshotter, and a link to detailed support documentation.

​
Bug fixes

  • Fixed an issue where the CLI would silently not load connections from the specified Astro Deployment or Workspace if the settings file was missing. The CLI now loads Astro connections regardless of whether the settings file, default airflow_settings.yaml, is present.
​
July 31, 2025

​
Improved Airflow 3 support

Astro CLI 1.35.1 introduces full compatibility with Apache Airflow 3, including support for the Astro Executor and Remote Execution Deployments on Astro. This release also adds the ability to manage connections, variables, and pools for Airflow 3 environments.

​
New flags for astro deployment create and astro deployment update

You can now use the new AstroExecutor option as an executor type for Airflow 3 Deployments. When using AstroExecutor, you can enable Remote Execution by setting the --remote-execution-enabled flag when you use astro deployment create. If Remote Execution is enabled, you can also configure additional Remote Execution mode Deployment settings with the following flags:
  • --allowed-ip-address-ranges: Limit the Deployment’s incoming traffic to the Remote Agents in your environment.
  • --task-log-bucket: Specify the cloud storage bucket for task log storage.
  • --task-log-url-pattern: Specify the URL template to link to task logs stored in an external logging provider from the Airflow UI.

​
Behavior changes

  • Astro CLI 1.35.1 removes support for pools in Airflow Versions 2.6 and below. Airflow 2.6 corresponds to Runtime Version 8, which has reached end of maintenance date.
  • Astro CLI 1.35.1 now interprets --webserver as --apiserver for Airflow 3 environments to reflect the updated component architecture.
​
July 1, 2025

​
Restricted release

The Astro CLI 1.35.0 was restricted from use on July 1, 2025, after its initial release. After upgrading to this version, v1.35.0 caused automatic, unintended updates to worker queues. Astro automatically blocks any requests coming from this CLI version.See the Astro CLI Release and lifecycle policy for more information about different release channels and a list of restricted CLI versions.
​
May 27, 2025

​
Additional improvements

  • Updated the astro dev init command to no longer require a container runtime during project initialization. This means you do not need to have something like Docker or Podman installed locally on your machine to run astro dev init succesfully.
  • Improved project linting.
  • Updated linting in astro dev upgrade-test to lint the entire project, not just the dags/ directory, so issues in other directories like include/ are now also detected.
​
April 22, 2025

​
Airflow 3 support

Astro CLI 1.34.0 adds support for Apache Airflow 3, including local development with Airflow 3 and the ability to test your project locally for upgrade incompatibilities.See Upgrade to Airflow 3 for steps to upgrade your Astro project from Airflow 2 to Airflow 3.

​
Bug fixes

  • Fixed an issue where the appropriate container engine for Airflow objects commands was not being used. Now, logic is in place to dynamically select Docker or Podman for Airflow object handling.
​
March 17, 2025

​
Bug fixes

  • Software users pulling images from internal registries no longer see a warning when their Astro Project’s Dockerfile path differs from the public defaults.
​
February 20, 2025

​
Bug fixes

  • Logs for astro dev parse and astro dev pytest commands are now displayed at the warn log level by default, making them visible without the --verbosity=debug flag for easier troubleshooting.
​
January 16, 2025

​
New flags for astro deploy on Astronomer Software

You can now use the --image flag with astro deploy to trigger an image-only deploy on Astronomer Software.You can also specify an image with the --image-name for a astro deploy on Astronomer Software. If you specify an image, you must also specify the image’s Runtime version with the --runtime-version flag. You can also use the new --remote flag with --image-name to directly point the deployment to the remote image and skip pushing the image.

​
Orbstack Container Runtime Engine Support for Mac

You can now use the Orbstack Container Runtime Engine with the Astro CLI on macOS. If Orbstack is running, containers start seamlessly. If not, the Orbstack app launches automatically, and containers start in the background. You can close the app while it continues running. This feature is available for macOS only. Windows and Linux users will need to start their runtime manually.

​
Additional improvements

  • Introduced a new configuration option sha_as_tag for Astronomer Software to use the SHA Digest value when making a call to the updateDeploymentImage endpoint in Houston, instead of the Runtime version tag.

​
Bug fixes

  • Fixed an issue where deployments list --all would not work on Astronomer Software.
​
January 8, 2025

​
Additional improvements

  • Dag-only and dbt deploys now use gzip compression for tar bundles, significantly reducing deploy times for large bundles to cloud Deployments.
​
December 17, 2024

​
Astro CLI now includes pre-configured Podman container runtime

You can now create local Astro projects without manually installing a container management engine, on all supported operating systems. When you install the Astro CLI with Homebrew or Winget, it includes a pre-configured Podman container runtime. If you don’t want to install Podman with the Astro CLI, you can opt out during installation, allowing the Astro CLI to use your existing runtime setup. See Install the Astro CLI.

​
Additional improvements

  • You can now specify the project name as an optional positional argument in astro dev init, simplifying project initialization by automatically creating and initializing a new directory.

​
Behavior changes

  • Previously in the CLI configuration file, the container.binary parameter for the Astro CLI was set to docker by default. Now, the Astro CLI will attempt to auto-detect the container runtime to use, checking for docker then podman in that order. You can override the auto-detection with astro config set container.binary.
​
November 22, 2024

​
New --from-template flag to setup template based project

You can now specify a template name such as etl, dbt-on-astro, generative-ai, or learning-airflow with the --from-template flag for astro dev init and the CLI sets up an Astro project based on the provided template.

​
New --show-workload-identity flag to fetch workload identity of Deployment

You can now fetch the workload identity value of a Deployment with the --show-workload-identity flag for astro deployment inspect.

​
Additional improvements

  • Added the ability for the CLI to autodetect the container runtime binary to use for the commands that utilize containers.
  • Streamlined the behavior of astro dev start for Podman users.

​
Behavior changes

  • You no longer need to explicitly set Podman as your container management engine for the Astro CLI when you are configuring the Astro CLI to use Podman, as the CLI now autodetects the container runtime binary to use for the commands that use containers.

​
Bug fixes

  • Fixed an issue where Astro created all the worker queues with the configuration of the first queue in the list when using the Deployment config file to create or update a Deployment.
​
October 16, 2024

​
New description flag for deploy on Astronomer Software

You can now add custom deploy descriptions during the astro deploy CLI command on Astronomer Software to enhance traceability and clarity in the deploy process. If you don’t provide a description, the system will automatically assign a default description based on the code deploy type. For example, the default description for a dag-only deploy would be Deployed via <astro deploy --dags>.

​
astro deployment create to create in Azure by default for Astro

Breaking ChangeAzure is now the default cloud provider when creating a deployment on Astro with the astro deployment create CLI command.Use the --cloud-provider flag to specify aws, gcp, or azure as the cloud provider for the Deployment.

​
Additional improvements

  • You can now create Astro Hosted Deployments on Azure via Astro CLI.
​
September 9, 2024

​
New flags for create and update Deployments

  • You can now add Extra Large schedulers to your Deployments when you create or update them with the new extra_large option for the --scheduler flag. This requires a minimum Astro Runtime version of 9.7.0.
  • You can also customize the workload identity when updating (AWS and GCP Hosted only) or creating (AWS Hosted only) Deployments directly with the command line with the --workload-identity flag or by adding it to the Deployment config file with the workload_identity field.
See astro deployment create and astro deployment update for more information.
​
July 25, 2024

​
Bug fixes

  • Fixed a bug where the CLI ignored files when bundling dags for code deploys.
​
July 24, 2024

​
Work with dbt projects on Astro

LabsThis feature is in Labs. Contact your account team to enable this feature.
You can now deploy a dbt project to Astro using the Astro CLI. See the following reference pages for more information:

​
Additional improvements

  • Added the ability to switch Workspaces by using the Workspace name instead of the workspace-id. See astro workspace switch.

​
Bug fixes

  • Fixed a bug where the command astro deployment inspect --key configuration.is_development_mode was printing wrong the value.
​
May 16, 2024

​
Bug fixes

  • Fixed an issue where the API token expiration check was causing login failures with API tokens that did not have an expiration date.
​
May 16, 2024

​
New flags for the Deployment logs commands:

You can now filter logs for specific Deployment components using the following new flags for astro deployment logs:
  • --webserver
  • --scheduler
  • --triggerer
  • --worker

​
Exclude dag files from parse test

You can now exclude dag files from being tested when you run astro dev parse.All new Astro projects that you create with astro dev init now include a file named .astro/dag_integrity_exceptions.txt. Add the names of dags to this file to exclude them from being tested when you run astro dev parse. This allows you to exclude dags that you know will not pass your tests.To use this feature in an existing Astro project, delete the .astro/test_dag_integrity_default.py file in your Astro project, then run astro dev init. After you run this command, the Astro CLI creates a new default test file along with a .astro/dag_integrity_exceptions.txt text file.

​
Additional improvements

  • Astro projects no longer have to include dags in order to run astro deploy --image.
  • You can now append 2>/dev/null | head to commands to disregard upgrade messages. For example, running astro completion bash 2>/dev/null | head ensures that the resulting bash script remains unaffected by the upgrade message.
  • You can now use the --development-mode disable flag with astro deployment update to turn off development mode for an existing Deployment. Note that you still cannot turn on development mode for an existing Deployment.

​
Bug fixes

  • Fixed an issue where you couldn’t create two Deployments with identical names across different Workspaces.
  • The upgrade-test command now returns the correct error code, ensuring accurate feedback during testing and CI/CD.
​
April 24, 2024

​
New commands to assign Organization and Workspace API tokens at different levels

You can now use the Astro CLI to manage Organization and Workspace API tokens at the Workspace and Deployment level using the following commands:For more information about this feature, see:

​
Bug fixes

  • Fixed an issue where existing secret environment variables in a Deployment file could be applied to the Deployment with an empty value. The secret variable value now persists.
  • Fixed an issue where astro deployment inspect generated an incorrect Airflow API URL.
  • Fixed a bug that caused some input checks for astro deployment upgrade-checks to fail against valid inputs.
​
March 28, 2024

​
Manage Deployment API tokens with the Astro CLI

You can now manage Deployment API tokens using the following CLI commands:
  • astro deployment token create
  • astro deployment token list
  • astro deployment token update
  • astro deployment token rotate
  • astro deployment token delete

​
Additional improvements

  • Updated the example dags that the Astro CLI creates when you run astro dev init.
  • The CLI now tells you if your API token is invalid.

​
Bug fixes

  • Fixed an issue with deployment variable create where it would cut off the new variables value at the first ”=” character.
  • Fixed an issue where running a deployment command in a workspace without a deployment caused an error. Now users will be asked if they want to create a deployment if one does not exist.
  • Fixed an issue where astro dev start —deployment-id was not creating local connections correctly in some scenarios.
  • Fixed an issue where astro deployment commands could only list 20 deployments. Now the commands will list up to 1000 for each workspace.
​
February 29, 2024

​
Bug fixes

  • Fixed an issue where the Astro CLI would experience a code panic if you tried to set a hibernation schedule for a Deployment that didn’t exist.
  • Fixed an issue where the Astro CLI would send and retrieve hibernation schedules for non-development Deployments.
​
February 27, 2024

​
Support for hibernating development Deployments

You can now use the Astro CLI to hibernate or wake up a development Deployment. These commands work well in automated processes where a Deployment requires flexibility for when it hibernates. Note that you can hibernate a Deployment only if you enable Development Mode when you create the Deployment.Use the following new commands to hibernate development Deployments regardless of their existing hibernation schedule:Additionally, you can create new development Deployments and configure long-term hibernation schedules for them using astro deployment create.

​
Additional improvements

  • You can now configure a custom workload identity when you create a Deployment using a Deployment file.
  • Added support for the upcoming custom role management feature on Astro

​
Bug fixes

  • Fixed an issue where astro deployment variable list --save didn’t format secret environment variables correctly.
  • Fixed an issue where you couldn’t update a Deployment with a Deployment file using a Deployment API token.
​
February 14, 2024

​
Changes to existing CLI command flags

The following flags have been updated, but will continue to work with a deprecation notice until the v1.25.0 release of the Astro CLI:
  • astro deployment logs --key-word ia a new flag that allows you to search your Deployment’s logs for an exact key word or phrase.
  • astro deployment create --cluster-type is now astro deployment create --type.
  • astro deployment create --enforce-cicd is now astro deployment create --cicd-enforcement.

​
Kubernetes worker configurations are now consistent with the Astro Cloud UI

You can now use Deployment files or the Astro CLI to create or update Kubernetes worker configurations.Deployment files now include some new and updated fields for Deployment configuration to match the options available in the Astro UI. This also allows you to create or update Kubernetes worker configurations directly, instead of requiring you to update the worker resources by changing the Kubernetes worker queue configuration.You can now use the default_task_pod_cpu, default_task_pod_memory, default_worker_type, resource_quota_cpu, and resource_quota_memory fields in a Deployment file to update your Kubernetes workers instead of creating or updating a Kubernetes default worker queue.With this new functionality, the following commands to update a Deployment running the Kubernetes executor continue to work, but display a deprecation notice:
  • astro deployment worker-queue create
  • astro deployment worker-queue update
Instead, you can use the new --default-task-pod-cpu, --default-task-pod-memory, --resource-quota-cpu, or --resource-quota-memory flags with astro deployment create and astro deployment update to edit your Kubernetes worker configuration using the Astro CLI.

​
Changes to Deployment file configurations

The following changes have been made to the format of Deployment files:
  • You no longer have to specify a cluster_name for standard Deployment files.
  • scheduler_size is no longer case sensitive.
  • Possible values for cloud_provider are now gcp, aws, and azure. This input is not case sensitive.
  • Possible values for deployment_type now include standard, dedicated, and hybrid in addition to the existing values of hosted_shared, hosted_dedicated, and hosted_standard. This input is not case sensitive
  • Possible values for for the executor field are now include celery and kubernetes. CeleryExecutor and KubernetesExecutor still work. This input is not case sensitive, so, for example, celeryexecutor still works.
  • (Astro Hosted only) default_task_pod_cpu, default_task_pod_memory, resource_quota_cpu, and resource_quota_memory are new fields for Astro Hosted deployments.
  • (Astro Hybrid only)default_worker_type is a new field for Hybrid deployments that use the Kubernetes executor.

​
Additional improvements

  • You can now trigger a dag-only deploy on Astronomer Software using astro deploy --dags. See Deploy dags on Astronomer Software.
  • astro deployment logs --key-word is a new flag that allows you to search your audit logs for an exact key word or phrase.
  • If you log in to Astro from the CLI, you need to select a Deployment when you deploy code. Previously, the Astro CLI used auto-select to automatically choose a Deployment for code deploys based on the CLI context. Now, by default, the CLI does not auto-selects the Deployments where your code deploys when you use it. However there are the following exceptions:
    • If you log in to Astro with an API token using the ASTRO_API_TOKEN, ASTRONOMER_KEY_ID, or ASTRONOMER_KEY_SECRET environment variables, auto-select is enabled. This is important because it ensures that if you have CI/CD scripts that rely on auto-select, they will continue to work.
    • There is a new config, auto_select. If auto-select is set to true in the config file, auto-select is always enabled.

​
Bug fixes

  • Fixed an issue where astro dev pytest --args and astro dev pytest --build-secrets could fail.
​
January 24, 2024

​
New flag to mount secrets to Astro project image

Use the new --build-secrets flag with the following commands to mount a secret value to an Astro project image:
  • astro deploy
  • astro dev parse
  • astro dev pytest
  • astro dev restart
  • astro dev start
  • astro dev upgrade test
This flag is equivalent to running docker build --secret for your Astro Runtime image build. Use this flag to simplify build steps for customizing the Astro Runtime image, for example when you need to install Python packages from a private source .
​
December 4, 2023

​
New command to deploy only images

You can use the new astro deploy --image command to deploy only the image to you Deployment. Previously, you could either complete a full code deploy with astro deploy or only update your dags with a dag-only deploy. See Trigger an image-only deploy for more information.

​
Bug fixes

  • Fixed a bug so you can now use a deployment file to create a Kubernetes deployment with a custom worker queue.
​
November 8, 2023

​
Bug fixes

  • Fixed an issue where astro deployment airflow-variable, astro deployment connection, and astro deployment pool commands were returning the error failed to decode response from API.
​
November 7, 2023

​
Bug fixes

  • Fixed an issue where astro workspace users list occasionally failed to return a table.
  • Fixed an issue introduced in version 1.19.4 where you could not deploy a custom image to Astro.