Skip to main content
A release publishes a dev-validated commit to production. A rollback moves traffic back to an earlier deploy.

​
Start with deploy history

Deploy history shows what is live and which deploy IDs are valid rollback targets.

​
Promote a release

Publish a GitHub release on your repo:
For a floo-hosted project or an app with no repo, use floo releases promote --app my-app. See Environments for source selection.

​
Roll back to a previous deploy

Roll back when the live deploy must be replaced now:
The rollback target must come from floo deploys list --app my-app. A rollback lands in the target deploy’s own environment; a multi-service preview rollback is rejected with ROLLBACK_PREVIEW_UNSUPPORTED. It needs a WRITE-scoped floo API key, like any release. A rollback re-points traffic at the earlier image and does not run migrate_command; it is not a schema downgrade. It reverts code, not config: env vars and secrets come from the environment’s current values.

​
Which one should you use?

If production is unhealthy:

​
Dashboard surface

The app detail view’s Versions tab lists promoted releases, and admins can roll back to one from there. Rolling back to any other deploy ID, including a dev deploy, takes floo deploys rollback or POST /v1/apps/{app_id}/rollback.

Logs and debugging

Read build and runtime logs before deciding whether to roll back.

Environments

Dev vs prod, promotion, and per-environment overrides.