Last updated 04 May 2018
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.
Your app’s first release is named
v1, and this number increments with each subsequent release.
In this example, a code deploy creates release
$ git push heroku master ... -----> 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
heroku releases command to see your app’s release history:
$ heroku releases Rel Change By When ---- ---------------------- ---------- ---------- v52 Config add AWS_S3_KEY email@example.com 5 minutes ago v51 Deploy de63889 firstname.lastname@example.org 7 minutes ago v50 Deploy 7c35f77 email@example.com 3 hours ago v49 Rollback to v46 firstname.lastname@example.org 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: <email@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: firstname.lastname@example.org When: 6 hours ago Addons: deployhooks:email, releases:advanced Config: MY_CONFIG_VAR => 42 RACK_ENV => production
Rolling back to a previous release does not change the state of add-ons.
heroku rollback command to roll 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.
Rolling back creates a new release. This new release copies the state of the compiled slug and config vars of the release you are rolling back to. The state of your
heroku Git remote, databases, and any external state held in add-ons (for example, the contents of memcache) are not affected. It is your responsibility to reconcile these resources with the rollback.
Running on a rolled-back release is meant as a temporary fix to a bad deployment. If you are running on a rolled-back release, commit a fix to your encountered issue and push it to Heroku. As always, this updates the
heroku Git remote and creates a new release.