バージョンとロールバック

デプロイのたびに、プロジェクトごとのバージョン番号が 1 ずつ増加します。

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

* は現在配信中のバージョンです。--json オプションを指定すると、サーバーの応答を JSON 形式で受け取れます。

ロールバックする

runlot rollback 2

ロールバックの前に確認を求めます。

me/my-app を v2 に戻します。配信中のデプロイが変わります。続行しますか?

CI 環境では、-y オプションで確認の手順を省略できます。

ロールバックは、選択したバージョンをあらためて有効なバージョンに指定します。バンドルを再ビルドせず既存のアーティファクトを使用するため、新しいデプロイよりも速く完了します。

バージョンに記録されるもの

git リポジトリからデプロイすると、CLI がフォルダの git の状態を読んで一緒に送ります。HEAD のコミット、コミットメッセージの 1 行目、ブランチ、そしてコミットしていない変更があったかどうかです。ダッシュボードのデプロイタブは、各バージョンを誰がデプロイし、どのコミットから来たかを表示し、コミットしていない変更を含むデプロイには印を付けます。そのデプロイでは、コミットハッシュがデプロイされたコードそのものではありません。コントロールプレーンはこれらの値を受け取ったまま記録し、検証はしません。

デプロイ履歴の保持

デプロイ履歴は削除されず、デプロイのアーティファクトも変更されません。過去にデプロイしたすべてのバージョンにロールバックでき、保持件数の制限はありません。

rollback は新しいデプロイを作成せず、有効なバージョンだけを変更します。そのため、ロールバックした後に、それまで使用していたバージョンをあらためて有効化することもできます。

runlot rollback 3   # v3 に戻す

データベースはロールバックされません

ロールバックはデプロイされたコードだけを変更し、データベースのスキーマとデータは維持されます。マイグレーションまで戻す必要がある場合は、バックアップと復元を参照してください。データベースの復元は、特定の時点にデータを戻す別の操作です。

カラムの削除のように元に戻せないマイグレーションは、コードのデプロイと同じタイミングで適用しないほうが安全です。