更新と復元

アプリの変更を反映したり、不具合が起きたときに以前のコードやデータへ戻したりできます。やりたいことに合わせて操作を選びます。

やりたいこと	操作
変更した内容を反映する	再度デプロイする
更新前のコードに戻す	ロールバックする
誤って変更・削除したデータを戻す	DB の復元ポイントを使う
一時的に利用を止める	サスペンドする
アプリを廃止する	削除する

操作には、そのアプリの管理権限（manage）が必要です。データベースの復元とアプリの削除にはブラウザでの承認も必要です。

コードを戻しても、データベースやファイルは以前の状態に戻りません。 詳しい範囲は、後半の何が戻り、何が戻らないかで確認できます。

アプリの変更を反映する

AI エージェントには、変更内容と確認してほしい操作を伝えます。

この変更を Keelson に反映してください。デプロイ前に設定とアップロード対象を確認し、完了後に［操作］ができるか確認してください。

手元の開発環境で変更内容を確認します
エージェントにデプロイを依頼します。CLI では keelson deploy --check --json で設定とアップロード対象を事前確認し、keelson deploy で反映できます
完了したらアプリを開き、変更した操作を確認します。定期実行だけのアプリは実行履歴を確認します（デプロイ後の確認）

切り替え前に失敗した場合、以前のバージョンへのアクセスは維持されます。ただし db.migrate が途中まで実行された場合、その変更は残ります（下の「DB の構造を変える」）。

反映されるもの・されないもの（シークレットは保存後にデプロイまたは「適用」が必要、など）はデプロイするを参照してください。

コードを前の状態に戻す

コードを以前のデプロイに戻す操作を「ロールバック」と呼びます。対象にできるのは、実行用のファイルをまとめた「コンテナイメージ」が残っている、過去の成功したデプロイです。

エージェントには「［不具合］が起きたので、前のコードに戻せるか、データへの影響も含めて確認してください」と依頼できます。CLI の操作は次のとおりです。

keelson rollback                # 直前の成功したデプロイに戻す
keelson rollback <deploy_id>    # 指定したデプロイに戻す

ビルドし直さず、対象デプロイのイメージと keelson.yaml の設定でアプリを起動します
対象にできるのは、イメージを持つ完了済みのデプロイだけです。静的サイト / SPA のデプロイと、古い方式で作られたデプロイはロールバック先にできません
シークレットは現在の値が使われます
対象デプロイの keelson.yaml に db.migrate があれば、ロールバックでも切り替え前に実行されます。DB に一切触れない操作ではありません
データベースは戻りません。 更新時に DB の構造（スキーマ）を変えていた場合、戻したコードがその構造で動くか確認が必要です。列の追加でも制約や既定値によって影響が出るため、エージェントに互換性の確認を依頼します。必要に応じて DB の復元も検討します
デプロイ進行中は実行できません

デプロイの一覧はコンソールの「デプロイ」タブにあり、各デプロイのソースをダウンロードできます。

静的サイト / SPA を戻すには、以前の成果物をもう一度デプロイします。Git で前のコミットに戻して手元でビルドし直すか、「デプロイ」タブから以前のデプロイのソース（assets.dir の中身と keelson.yaml）をダウンロードして、そのまま keelson deploy します。

誤って消したデータを戻す

Managed SQLite（db.mode: libsql）のデータは、コンソールのアプリ画面にある「復元ポイント」から戻します。

復元ポイントのタイムラインから時点を選びます。日次バックアップ、手動で保存した状態（スナップショット）、指定した時刻への復元（PITR）のいずれかです（プランごとの保持世代数と復元窓はプランと制限）
選択した過去の復元ポイントをダウンロードして、中身を確認することもできます。この操作で取得するのは、現在の DB ではありません
復元を実行します。ブラウザでの承認が要ります
復元後、アプリを開いてデータを確認します

復元で起きること:

その時点以降の書き込みはすべて消えます。 消したデータだけを戻す操作ではありません。現在のデータも残しておきたい場合は、復元を実行する前に現在の DB の手動スナップショットを作成し、そのスナップショットをダウンロードします。復元後に必要な変更を移す作業は、エージェントに相談できます
復元前の状態は 72 時間保持され、その間は復元を取り消せます
復元は 1 つのアプリの DB だけに効きます。他のアプリには影響しません
Files / Media のファイルと外部 DB は対象外です

大きな変更の前に手動スナップショットを作ると、戻す時点を残せます（1 アプリ 5 回/日）。

DB の構造を変える

保存する項目の追加など、DB の構造を更新する処理を「マイグレーション」と呼びます。コードを戻したときにも動くよう、エージェントには次の確認を依頼します。

DB の構造を変更する場合は、更新前のコードでも動くか、失敗後に再実行しても問題がないかを確認してください。復元が必要になる変更は、実行前に影響と戻し方を教えてください。

マイグレーションの実装時の注意

db.migrate に書いたコマンドは、デプロイやロールバックで新しいバージョンへ切り替える前に実行されます。

失敗すると以前のバージョンへのアクセスは維持されます。ただし、途中まで実行された DB の変更は自動では戻りません。keelson logs deploy <deploy_id> のログと DB の状態を確認してから修正します
同じ処理を繰り返しても重複した変更が起きないようにします。この性質を「冪等性」と呼びます。適用済みの変更を記録する仕組みや IF NOT EXISTS などを使い、途中で失敗した場合も確認します
列やテーブルを追加する場合も、旧コードとの互換性を確認します。列の削除や型の変更など影響の大きい変更は、直前にスナップショットを作成し、利用の少ない時間帯に行う方法を検討します

アプリを廃止する

「止める」と「消す」は別の操作です。

操作	何が起きるか	戻せるか
サスペンド（アプリ画面の「設定」→「サスペンド」）	アクセス・Webhook・cron のいずれでも起動しない。URL には停止ページが出る。データ・URL・設定は残る	「再開」でいつでも戻せる
削除（「設定」→「危険な操作」）	アプリ本体・URL・デプロイ履歴・シークレットが消える。ブラウザでの承認が要る	戻せない

削除の前に取り出しておくもの:

DB のデータ — 現在のデータが必要なら手動スナップショットを作り、その復元ポイントからダウンロード
Files のファイル — アプリにダウンロード処理を用意して取り出します
Media のファイル — アプリが記録したファイル ID から閲覧用リンクを作り、削除前に保存します。Files / Media とも、コンソールや CLI には一覧・ダウンロード機能がありません（ファイルとメディア）
ソースコード — Git、または「デプロイ」タブの各デプロイからダウンロード
シークレットの値 — 保存後は再表示されません。登録時の保管先や発行元で、必要な値を確認します

削除後、DB のバックアップ・Files・非機密の構成メモ（アプリ名、URL、cron 定義、環境変数とシークレットの名前）は 7 日間隔離保持されますが、これは誤削除への裁量対応であり、復元の保証ではありません。

契約が終了した場合のアプリの扱いは料金と契約の運用を参照してください。

何が戻り、何が戻らないか

表の「ロールバック」はコードを前のデプロイに戻す操作、「DB の復元」は Managed SQLite を復元ポイントに戻す操作です。

対象	ロールバックで戻るか	DB の復元で戻るか	備考
コード（イメージ）	戻る	戻らない	ビルドし直さず、対象デプロイのイメージを起動する。静的サイト / SPA は対象外
`keelson.yaml` の設定（`env`、`crons`、`assets`、`health`）	戻る	戻らない	対象デプロイ時点の設定が使われる
シークレットの値	戻らない	戻らない	常に現在の値が使われる。コンソールで手で戻す
Managed SQLite のデータ	戻らない	戻る	日次バックアップ、手動スナップショット、PITR（時刻復元）
`db.migrate` で加えたスキーマ変更	戻らない	戻る	復元ポイントの時点の DB 構造になる
Files SDK のファイル	戻らない	戻らない	バックアップの対象外。アプリ側で保持する
Media SDK のファイル	戻らない	戻らない	上書き不可。差し替えは新しいファイルを保存する
外部 DB（PostgreSQL など）	戻らない	戻らない	外部サービス側のバックアップで戻す
外部サービスへの変更（Slack 投稿、メール送信、決済）	戻らない	戻らない	ロールバックでは取り消されない。再実行時の重複に注意
アプリ権限、IP 制御、公開 URL	戻らない	戻らない	デプロイと独立した設定。手で戻す