Versions and rollback

Each deploy increments a per-project version number by one.

runlot versions

* v3  2026-09-05 14:02  my-app.me.runlot.app
  v2  2026-09-05 11:20
  v1  2026-09-04 22:41

* marks the version currently being served. Pass --json to get the server response in JSON.

Rolling back

runlot rollback 2

You are asked to confirm before the rollback runs.

This rolls me/my-app back to v2. The deploy being served will change. Continue?

In CI, use -y to skip the confirmation step.

Rolling back makes the selected version active again. It does not rebuild the bundle — it reuses the existing artifact, so it finishes faster than a new deploy.

What a version records

When you deploy from a git repository, the CLI reads the folder's git state and sends it along: the HEAD commit, the first line of its message, the branch, and whether there were uncommitted changes. The deployments tab in the dashboard shows who deployed each version and which commit it came from, and marks a deploy that carried uncommitted changes — for that one, the commit hash is not the code that shipped. The control plane records these values as sent and does not verify them.

Deploy history is kept

Deploy history is never deleted, and deploy artifacts are immutable. You can roll back to any version you have deployed before, and there is no limit on how many are kept.

rollback does not create a new deploy; it only changes the active version. That means you can re-activate the version you were on before after a rollback.

runlot rollback 3   # back to v3

The database is not rolled back

A rollback changes only the deployed code; your database schema and data are left as they are. If you need to revert migrations too, see Backup and restore. Restoring a database is a separate operation that returns your data to a point in time.

For migrations that cannot be reversed, such as dropping a column, it is safer not to apply them at the same time as a code deploy.