# Releases and rollback

Source: https://docs.myhub.host/releases

## Find the running release

```sh
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

```sh
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:

```sh
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

```sh
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](https://docs.myhub.host/cli/app/rollback) · [Automate verification](https://docs.myhub.host/automation)