Releases
Last updated December 03, 2024
Whenever you deploy code, change a config var, or modify your app’s add-on resources, Heroku creates a new release and restarts your app. You can view your app’s release history, and temporarily roll back to a previous release in the event of a bad deploy or config change.
Release creation
Your app’s first release is named v1, and this number increments with each subsequent release.
In this example, a code deploy creates release v10:
$ git push heroku main
...
-----> Compressing... done, 8.3MB
-----> Launching... done, v10
http://severe-mountain-793.herokuapp.com deployed to Heroku
As mentioned, releases are also created whenever you modify your app’s config vars or add-on resources.
Listing release history
Use the heroku releases command to see your app’s release history:
$ heroku releases
Rel Change By When
---- ---------------------- ---------- ----------
v52 Config add AWS_S3_KEY jim@example.com 5 minutes ago
v51 Deploy de63889 stephan@example.com 7 minutes ago
v50 Deploy 7c35f77 stephan@example.com 3 hours ago
v49 Rollback to v46 joe@example.com 2010-09-12 15:32:17 -0700
The value of the Change column indicates the cause of each release. For deployments, this value includes the hash of the Git commit that was deployed. Use this hash to correlate changes in a release with changes in your Git repository. For example:
$ git log -n 1 de63889
commit de63889c20a96347679af2c5160c390727fa6749
Author: <stephan@example.com>
Date: Thu Jul 11 17:16:20 2013 +0200
Fixed listing CSS and localization of description.
You can get detailed info on a release with the heroku releases:info command:
$ heroku releases:info v24
=== Release v24
Change: Deploy 575bfa8
By: jim@example.com
When: 6 hours ago
Addons: deployhooks:email, releases:advanced
Config: MY_CONFIG_VAR => 42
RACK_ENV => production
Rollback
If you deploy buggy code to production that you need to roll back, whenever possible, revert the relevant code changes locally with git revert and redeploy.
To roll back a release due to incorrect configuration or other Heroku platform-specific issues, use the heroku rollback command. This command rolls your app back to a previous release:
$ heroku rollback v40
Rolled back to v40
If you don’t specify a release number, your app is rolled back by a single release.
The heroku rollback command creates a new release. This release copies the compiled slug or OCI image and config vars, including add-on-related config vars, of the release you roll back to.
The heroku rollback command doesn’t roll back the state of any of the following:
- Add-on provisioning
- Provisioned add-ons remain provisioned, and deprovisioned add-ons remain deprovisioned.
- Add-on-related config vars do rolled back. Take care to reconcile any add-on-related config var values to not break any add-ons that remain provisioned.
- Your app’s Heroku-hosted Git repository
- Any state stored in add-ons or externally
It’s your responsibility to reconcile these resources after rolling back. Use the heroku rollback command only when absolutely necessary.
Running on a rolled back release serves as a temporary fix to a bad deployment. If you’re running on a rolled back release, commit a fix to your encountered issue and push it to Heroku. As always, this push updates the heroku Git remote and creates a new release.
Release Retention Policy for Fir
For Fir-generation apps, we destroy OCI images associated with releases that are:
- older than 30 days, excluding the last release
- older than 100 releases
The status of a release updates to expired when we destroy its OCI image. Releases without an OCI image aren’t eligible for rollback.