> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Astro CLI release notes archive: 1.37 through 1.20

> Archived Astro CLI release notes for versions 1.37 through 1.20.

Archived release notes for Astro CLI versions 1.37 through 1.20.

* [Current Astro CLI release notes](/docs/cli/release-notes)
* [Release notes: 1.19 through 1.10](/docs/cli/release-notes-archive-2)
* [Release notes: 1.9 through 0.2](/docs/cli/release-notes-archive-3)

<Update label="Astro CLI 1.37.0" description="October 14, 2025" rss={{ date: "2025-10-14" }}>
  ### Support for Astro Private Cloud 1.0

  Added support for [Astro Private Cloud 1.0](/docs/astro-private-cloud/v-1-x/astro-private-cloud-overview), 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.
</Update>

<Update label="Astro CLI 1.36.0" description="September 10, 2025" rss={{ date: "2025-09-10" }}>
  ### New Astro IDE commands

  <Info>
    **Public Preview**

    This feature is in [Public Preview](/docs/astro/feature-previews).
  </Info>

  Added the following commands so that you can work with the [Astro IDE](/docs/astro/ide-overview) from the Astro CLI:

  * [`astro ide project export`](/docs/cli/v1.46/astro-ide-project-export): Export your current local project to Astro IDE.
  * [`astro ide project import`](/docs/cli/v1.46/astro-ide-project-import): Import an existing Astro IDE project into your local environment for development or editing.
  * [`astro ide project list`](/docs/cli/v1.46/astro-ide-project-list): List all Astro IDE projects you have access to.

  ### 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.
</Update>

<Update label="Astro CLI 1.35.1" description="July 31, 2025" rss={{ date: "2025-07-31" }}>
  ### 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.
</Update>

<Update label="Astro CLI 1.35.0" description="July 1, 2025" rss={{ date: "2025-07-01" }}>
  ### 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](/docs/cli/v1.46/release-lifecycle-policy) for more information about different release channels and a list of restricted CLI versions.
</Update>

<Update label="Astro CLI 1.34.1" description="May 27, 2025" rss={{ date: "2025-05-27" }}>
  ### 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.
</Update>

<Update label="Astro CLI 1.34.0" description="April 22, 2025" rss={{ date: "2025-04-22" }}>
  ### 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](/docs/astro/airflow3/upgrade-af3) 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.
</Update>

<Update label="Astro CLI 1.33.2" description="March 17, 2025" rss={{ date: "2025-03-17" }}>
  ### 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.
</Update>

<Update label="Astro CLI 1.33.1" description="February 20, 2025" rss={{ date: "2025-02-20" }}>
  ### 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.
</Update>

<Update label="Astro CLI 1.33.0" description="January 16, 2025" rss={{ date: "2025-01-16" }}>
  ### New flags for [`astro deploy`](/docs/cli/v1.46/astro-deploy) on Astronomer Software

  You can now use the `--image` flag with `astro deploy` to trigger an image-only deploy on [Astronomer Software](/docs/cli/v1.46/astro-deploy).

  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`](/docs/cli/v1.46/configure-cli) 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.
</Update>

<Update label="Astro CLI 1.32.1" description="January 8, 2025" rss={{ date: "2025-01-08" }}>
  ### Additional improvements

  * Dag-only and dbt deploys now use gzip compression for tar bundles, significantly reducing deploy times for large bundles to cloud Deployments.
</Update>

<Update label="Astro CLI 1.32.0" description="December 17, 2024" rss={{ date: "2024-12-17" }}>
  ### 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](/docs/cli/v1.46/install-cli).

  ### Additional improvements

  * You can now specify the project name as an optional positional argument in [`astro dev init`](/docs/cli/v1.46/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`](/docs/cli/v1.46/switch-container-management).
</Update>

<Update label="Astro CLI 1.31.0" description="November 22, 2024" rss={{ date: "2024-11-22" }}>
  ### 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`](/docs/cli/v1.46/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](/docs/astro/authorize-deployments-to-your-cloud#what-is-workload-identity) value of a Deployment with the `--show-workload-identity` flag for [`astro deployment inspect`](/docs/cli/v1.46/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.
</Update>

<Update label="Astro CLI 1.30.0" description="October 16, 2024" rss={{ date: "2024-10-16" }}>
  ### New description flag for deploy on Astronomer Software

  You can now add custom deploy descriptions during the [`astro deploy`](/docs/cli/v1.46/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

  <Danger>
    **Breaking Change**

    Azure is now the default cloud provider when creating a deployment on Astro with the [`astro deployment create`](/docs/cli/v1.46/astro-deployment-create) CLI command.

    Use the `--cloud-provider` flag to specify `aws`, `gcp`, or `azure` as the cloud provider for the Deployment.
  </Danger>

  ### Additional improvements

  * You can now create Astro Hosted Deployments on Azure via Astro CLI.
</Update>

<Update label="Astro CLI 1.29.0" description="September 9, 2024" rss={{ date: "2024-09-09" }}>
  ### 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`](/docs/cli/v1.46/astro-deployment-create) and [`astro deployment update`](/docs/cli/v1.46/astro-deployment-update) for more information.
</Update>

<Update label="Astro CLI 1.28.1" description="July 25, 2024" rss={{ date: "2024-07-25" }}>
  ### Bug fixes

  * Fixed a bug where the CLI ignored files when bundling dags for code deploys.
</Update>

<Update label="Astro CLI 1.28.0" description="July 24, 2024" rss={{ date: "2024-07-24" }}>
  ### Work with dbt projects on Astro

  <Note>
    **Labs**

    This feature is in [Labs](/docs/astro/feature-previews). Contact your account team to enable this feature.
  </Note>

  You can now deploy a dbt project to Astro using the Astro CLI. See the following reference pages for more information:

  * [astro dbt deploy](/docs/cli/v1.46/astro-dbt-deploy)
  * [astro dbt delete](/docs/cli/v1.46/astro-dbt-delete)

  ### Additional improvements

  * Added the ability to switch Workspaces by using the Workspace name instead of the `workspace-id`. See [astro workspace switch](/docs/cli/v1.46/astro-workspace-switch).

  ### Bug fixes

  * Fixed a bug where the command `astro deployment inspect --key configuration.is_development_mode` was printing wrong the value.
</Update>

<Update label="Astro CLI 1.27.1" description="May 16, 2024" rss={{ date: "2024-05-16" }}>
  ### 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.
</Update>

<Update label="Astro CLI 1.27.0" description="May 16, 2024" rss={{ date: "2024-05-16" }}>
  ### 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](https://docs.astronomer.io/astro/deployment-resources#hibernate-a-development-deployment) 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.
</Update>

<Update label="Astro CLI 1.26.0" description="April 24, 2024" rss={{ date: "2024-04-24" }}>
  ### 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:

  * [`astro deployment token organization-token`](/docs/cli/v1.46/astro-deployment-token-organization-token)
  * [`astro deployment token workspace-token`](/docs/cli/v1.46/astro-deployment-token-workspace-token)
  * [`astro workspace token organization-token`](/docs/cli/v1.46/astro-workspace-token-organization-token)

  For more information about this feature, see:

  * [Assign an Organization or Workspace API token to a Deployment](/docs/astro/deployment-api-tokens#assign-an-organization-or-workspace-api-token-to-a-deployment).
  * [Assign an Organization API token to a Workspace](/docs/astro/workspace-api-tokens#assign-an-organization-api-token-to-a-workspace)

  ### 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.
</Update>

<Update label="Astro CLI 1.25.0" description="March 28, 2024" rss={{ date: "2024-03-28" }}>
  ### Manage Deployment API tokens with the Astro CLI

  You can now manage [Deployment API tokens](/docs/astro/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.
</Update>

<Update label="Astro CLI 1.24.1" description="February 29, 2024" rss={{ date: "2024-02-29" }}>
  ### 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.
</Update>

<Update label="Astro CLI 1.24.0" description="February 27, 2024" rss={{ date: "2024-02-27" }}>
  ### 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](/docs/cli/v1.46/astro-deployment-create).

  Use the following new commands to hibernate development Deployments regardless of their existing hibernation schedule:

  * [`astro deployment hibernate`](/docs/cli/v1.46/astro-deployment-hibernate)
  * [`astro deployment wake-up`](/docs/cli/v1.46/astro-deployment-wake-up)

  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.
</Update>

<Update label="Astro CLI 1.23.0" description="February 14, 2024" rss={{ date: "2024-02-14" }}>
  ### 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](/docs/astro/deployment-file-reference) 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`](/docs/cli/v1.46/astro-deployment-create) and [`astro deployment update`](/docs/cli/v1.46/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](/docs/astro/deployment-file-reference):

  * 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](https://www.astronomer.io/docs/software/deploy-dags).
  * `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.
</Update>

<Update label="Astro CLI 1.22.0" description="January 24, 2024" rss={{ date: "2024-01-24" }}>
  ### 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`](https://docs.docker.com/build/building/secrets/#secret-mounts) 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](/docs/cli/v1.46/private-python-packages?tab=pypi#install-python-packages-from-a-private-pypi-index) .
</Update>

<Update label="Astro CLI 1.21.0" description="December 4, 2023" rss={{ date: "2023-12-04" }}>
  ### 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](/docs/astro/deploy-dags#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.
</Update>

<Update label="Astro CLI 1.20.1" description="November 8, 2023" rss={{ date: "2023-11-08" }}>
  ### 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`.
</Update>

<Update label="Astro CLI 1.20.0" description="November 7, 2023" rss={{ date: "2023-11-07" }}>
  ### 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.
</Update>