Releases and rollback

Find the running release

hub app my-app releases

Releases appear newest first. * marks the running release.

New rollback entries show the selected release, such as rollback to #3. In JSON, rollbackTarget is that release number; buildNumber identifies the build it reused. These can differ when the selected release was itself a rollback or a configuration change. Historical rollbacks whose target was not recorded show rollback to build #N when the build is known, or target unavailable otherwise.

Undo a code change

hub app my-app rollback
hub app my-app status

Without a number, Hub selects the newest successful release older than the currently serving release and creates a release from its build. Open the app and check it after the rollback.

Failed releases and attempts superseded before they ran are skipped. If release 2 fails while release 1 still serves, there is no earlier successful release to select; release 1 keeps serving and the error names it.

To select a successful release explicitly:

hub app my-app rollback 3

Hub reports the selected target. If it uses the same build as the serving release, Hub warns that the rollback reuses that build. JSON and MCP include rollbackTarget and, when applicable, warning in the result. Check the new release before treating the rollback as complete.

Rollback keeps current environment variables and data. It does not undo database migrations. Hub retains five builds per instance.

Build again

hub app my-app redeploy

This rebuilds the connected GitHub branch or the last uploaded source. To upload changed local files, run hub deploy from your project folder.

The app's Releases tab has the same history and rollback controls.

Choose a specific release · Automate verification