Skip to main content
Deploy rollbacks are an emergency option if a Deployment unexpectedly stops working after a recent deploy. For example, if one of your Dags worked in development but suddenly fails in a mission-critical production Deployment, you can roll back to your previous deploy to quickly get your pipeline running again. This allows you to revert your deployment to a known good state while you investigate the cause of the failure. You can roll back to any deploy in the last three months regardless of your Dag code or Deployment settings. However, rollbacks are only supported for Runtime 5.0.0 and above or its equivalent Airflow version, 2.3.0 and above.

​
Rollback version compatibility

Starting in Astro Private Cloud 1.1, rollbacks are supported across Airflow 3 and Airflow 2 Runtime versions. The following rollback paths are now available:
Astro Runtime versions 3.0-1 through 3.1-1 aren’t supported for automated rollbacks. If either the source or target version is in this range, automated rollback isn’t available.

​
Airflow 3 to Airflow 2 rollback considerations

When rolling back from Airflow 3 to Airflow 2:
  • Dag compatibility: Dags written for Airflow 3 aren’t compatible with Airflow 2. Ensure you roll back your Dags as well, or revert any Airflow 3-specific code changes before rolling back.
  • Longer rollback time: Cross-major version rollbacks take longer than same-version rollbacks due to database schema migrations.
  • UI warnings: The UI displays prominent warnings when attempting cross-major version rollbacks to ensure you understand the implications.

​
Prerequisites

  • You must be at least a Deployment Editor or otherwise have the permission deployment.images.push or deployment.dags.push or both to roll back images and/or Dags, respectively, for a Deployment.
    • If you want to limit users to either rollback images or Dags, you can configure granular rollback permissions for more information on how to modify these values.

​
Enable deploy rollbacks

If deploy rollbacks are configured for your installation, you can enable them in individual Deployments through the Deployment Settings page.
  1. In the Astro Private Cloud UI, open your Deployment.
  2. On the Settings page, toggle Rollback Deploy to Enable.

​
Roll back to a deploy

Astronomer recommends triggering Deployment rollbacks only as a last resort for recent deploys that aren’t working as expected. Deployment rollbacks can be disruptive, especially if you triggered multiple deploys between your current version and the rollback version. See What happens during a deploy rollback before you trigger a rollback to anticipate any unexpected effects.
  1. In the Astro Private Cloud UI, open your Deployment, then go to Deploy History.
  2. Find the deploy you want to roll back to in the Deploys table, then click Deploy.
  3. Write a description for why you’re triggering the rollback, then confirm the rollback.

​
What happens during a deploy rollback

A deploy rollback is a new deploy of a previous version of your code. This means that the rollback deploy appears as a new deploy in Deploy History, and the records for any deploys between your current version and rollback version are still preserved. In Git terms, this is equivalent to git revert. When you trigger a rollback, the following information is rolled back:
  • All project code, including Dags.
  • Your Astro Runtime version. Note that if you roll back to a restricted Runtime version, it might include major bugs and performance issues.
  • Your Deployment’s Dag deploy setting.
The following information isn’t rolled back:
  • Your Deployment’s resource configurations, such as executor and scheduler configurations.
  • Your Deployment’s environment variable values.
  • Any other Deployment settings that you configure through the Astro UI, such as your Deployment name and description.
  • For Runtime version downgrades, any data related to features that aren’t available in the rollback version are erased from the metadata database and not recoverable.
Logs related to the rollback are exported to Elasticsearch.

​
Granular rollback permissions

You might want to enable your users to roll back Dag-only or image-only deploys, without granting them the ability to roll back complete project deploys. This allows you to maintain higher security measures, by limiting who has permission to roll back both image and Dag deploys, or only one of the two.
  • deployment.images.push: Grants permission to roll back just the image of a revision in an imaged-based, Dag-only, and gitSync deployment.
  • deployment.dags.push: Grants permission to roll back only Dags for Dag-only deploys.
Users with both permissions can roll back both images and Dags. If users attempt to roll back a deploy and have limited permissions, they can only choose the type of deploy to roll back that they have permission for. Follow the procedure in Customize role permissions to configure these user permissions.