ロールバック。ブランチ。共有。すべてのコンテナの基盤となる状態モデル。
5つのファイルシステムプリミティブとBTRFSのコピーオンライトレイヤーにより、コンテナの状態がHTTPを離れることなく、生き残り、タイムトラベルし、サーバー間を移動できます。
/hoody/storage · /hoody/databases · /ramdisk · /hoody/shares · BTRFSスナップショット
/ ├── hoody/ │ ├── storage/ ← persistent, per-container │ ├── databases/ ← concurrent-safe SQLite (FUSE) │ └── shares/ ← inter-container directory mounts ├── ramdisk/ ← RAM-backed, up to 50% of host memory └── ... ← standard Linux FS (ext4, POSIX)
ファイルシステムマップ。
各パスは異なる永続性と同時実行性の特性を持ちます。適切なパスを選ぶことがメンタルモデルのすべてです。詳細は以下のセクションで解説します。
/hoody/storage
コンテナごとの永続ディレクトリ。再起動後も存続し、スナップショットでキャプチャされます。通常のext4ディレクトリ — FUSEなし、アプリが提供する範囲を超える同時実行安全性なし。
/hoody/databases
FUSEマウント。多数のプロセスや複数のコンテナ（同一サーバー）が'database is locked'エラーなしでSQLiteに安全に同時書き込みできます。パスの変更のみ: /app/data.dbから/hoody/databases/data.dbにファイルを移動します。ホストレベルのみ — クロスサーバーレプリケーションなし。
/ramdisk
10〜20 GB/s、<1µsレイテンシーのRAMバックtmpfs。コンテナメモリの50%が上限で、オンデマンド割り当て（空の場合は0バイト使用）。コンテナ再起動後も持続、ホスト再起動でクリア。使用量はアプリケーションメモリと競合します。
/hoody/shares
Storage Shares APIによるコンテナ間ディレクトリマウント。読み取り専用または読み書き、1対1またはプロジェクト全体。クロスサーバー共有は自動NFS使用 — マウント設定不要。ライフサイクル（accept / reject / mount / revoke）は/platform/control-planeにあります。
/ (ext4)
その他すべての標準Linuxファイルシステム。POSIX、ext4、完全なセマンティクス。/hoody/*パス以外はどのVPSとも同様に動作します。
基盤となるBTRFS
ディスクバックアップパス下のコピーオンライトレイヤー。ブロックレベルスナップショット、コンテナ間の重複排除。即時作成、スペース効率の良いリストア。（/ramdiskはRAM内のtmpfsなので対象外）
コピーオンライト、ブロックレベル、即時。
BTRFSはスナップショット時点から変更されたブロックのみを保存します。スナップショットの作成はマーカーを追加するだけで、データは追加されません。コストはコンテナが実際に変更した量に比例 — スナップショットの数やベースイメージを共有するコンテナの数には依存しません。
t0 — スナップショットA
コンテナファイルシステムにブロックa、b、cがあります。スナップショットAは3つすべてを参照します。
t1 — ブロックbが変更
書き込み変更でbをb'にコピー。元のbはスナップショットAから引き続き参照されます。コンテナはa、b'、cを参照します。
t2 — スナップショットB
スナップショットBはa、b'、cをキャプチャ。AとBはaとcを共有。b/b'のみが分岐。ストレージ合計: 6ブロックではなく4ブロック。
実行中か停止中か — コンテナの状態がスナップショットの種類を決めます。
実行中にスナップショットを取ると、ファイルシステムと共にプロセス、メモリ、ターミナル履歴、ブラウザータブ、ネットワーク接続も取得できます。停止中に取るとファイルシステムのみになります。APIコールは同じで、種類は自動的に決まります。
スナップショット → ファイルシステムのみ
ディスク上のものはすべて、メモリ上のものは何も。
- +ファイルシステム ── /hoody/* を含め、/ 配下でディスクに書き込まれたすべて
- +ディスク上のすべてのファイル、パッケージ、インストール済みの依存関係
- +すでにディスクにフラッシュ済みのデータベースとアプリデータ
- +復元するとディスクが巻き戻り、コンテナはそこから新規起動します ── プロセスは再開しません
- +stateful フィールドは常に false ── だからこそスナップショットは速く、小さく、信頼できます
一時停止/再開 → RAM を凍結
メモリを残す必要があるときのための、別の操作。
- ·POST /api/v1/containers/ID/pause — the pause lifecycle operation
- ·コンテナの状態が RAM 内で凍結され、その場で一時停止されます
- ·再開操作で、プロセスが実行途中から復帰します
- ·スナップショットではありません ── ディスク上に復元ポイントは作られません
— リストアは破壊的: 現在のライブ状態を上書きします。現在の状態を保持したい場合は、まずスナップショットを取ってから対象をリストアしてください。
エージェントに試させましょう。アンドゥボタンは手元に。
認証ミドルウェア、データベースマイグレーション、大規模リファクタリングに触れるLLMは、実行前スナップショットパターンから最も恩恵を受けます。取得は低コスト。リストアは高速。各方向へのAPIコールは1回のみ。
スナップショットなし
- 1.エージェントが認証ミドルウェアをリファクタリング。最初のスモークテストは通過。
- 2.マージしてデプロイ。数日間は問題なさそう。
- 3.本番環境でセッションがサイレントにドロップし始める。
- 4.最近のエージェントコミットを二分探索するのに数時間 — 変更は大きなdiffに埋もれている。
- 5.ロールバックには、マージされたすべてのエージェントPRを手動で差し戻して再デプロイが必要。
Hoodyスナップショットあり
- 1.エージェント実行前にコンテナをスナップショット。pre-auth-refactorのようなエイリアスを付ける。
- 2.エージェントに作業させる。ファイルを編集し、サービスを再起動し、スモークテストを実行。
- 3.1週間後に本番環境で何かがおかしいと気づく。
- 4.PATCH /snapshots/pre-auth-refactor — コンテナは5〜15秒でエージェント実行前の状態にリストアされます。
- 5.スナップショットからサービスが復元された後、オフラインで調査するために破損した状態の新しいスナップショットを取ることができます。
セーフティネットパターンがある理由 — コード生成、インフラリファクタリング、データベースマイグレーションなど、すべてのAI支援ワークフローはスナップショット済みコンテナ内で実行すべきです。スナップショットは低コストですが、AIによる誤った変更の発見コストは低くありません。
ワークフローはマシン全体のコミットグラフです。
リスクの高い変更の前にスナップショットを取ります。反復します。結果が良ければ続けます — スナップショットは低コストで有効期限設定可能です。壊れたら、PATCHコール1回でコンテナをRAM、プロセス、オープンファイルすべて含めて元の状態に戻せます。
t0 — ベースライン
POST /snapshots — v1.4.0-preとしてタグ付け
t1 — リスクのある作業
AIエージェントがリファクタリング、マイグレーション実行、サービス再起動
t2 — 何かが壊れた
スモークテスト失敗。戻る必要がある。
t3 — リストア
PATCH /snapshots/v1.4.0-pre — 5〜15秒でリストア
t4 — t0と同一
RAM、プロセス、FSすべてがt0と一致。ドリフトゼロ。
PATCH /api/v1/containers/ID/snapshots/v1.4.0-preSSDがボトルネックになったとき、/ramdiskが答えです。
コンテナメモリの半分が/ramdiskとして利用可能で、オンデマンド割り当て。使えばそこにあり、使わなければ消えます。コンテナ再起動後も持続。ホスト再起動でクリア。
⚠ /ramdiskの使用量はコンテナメモリにカウントされます。コンテナが4 GBでありながら/ramdiskが3 GBを使用している場合、アプリケーションは1 GBで動作します。`free -h`で監視し、慎重な設計で上限を設けてください。
チームが実際に使う5つのスナップショット戦略。
1つ選ぶだけで、状態管理の規律がポリシー文書ではなくワンライン決定になります。多くのチームはこれらのうち2〜3つを並行して実行しています。
1 · 操作前の安全確保
破壊的な操作（マイグレーション、AIコード生成、インシデント対応、手動ホットフィックス）の前にスナップショットを取ります。
2 · バージョン管理されたマイルストーン
リリースポイントでスナップショットにエイリアスを付けます — v1.4.0、v1.5.0-rc。有効期限を数週間先に設定。任意の名前付きバージョンへの即時ロールバック。
3 · 毎日の自動化
自動有効期限付きのcronスナップショット = 自己刈り込み履歴。7日分の昨日、30日分の先月。
4 · Gitスタイルのブランチ
スナップショット + コンテナコピー = 別のプロジェクトやサーバー上の別のタイムライン。コピー上でリスクのあるパスを試す。うまくいけば、そこでベースラインを再構築します。同期は一方向なので、コピーが新しい真実の場所になります。
5 · ゴールデンイメージテンプレート
スナップショットをシードし、新しい開発コンテナごとにスナップショットからコピー。オンボーディングがPOSTコール1回になります。
ボーナス · フォレンジック保存
本番環境が侵害された場合: 調査のために侵害された状態をスナップショット、以前のクリーンなスナップショットから本番環境をリストア、2つをオフラインで差分比較。証拠を失わずにインシデント対応。
本来組み合わせて使うもの。
ロールバック、ステートフルキャプチャ、同時安全SQLite、コンテナ間共有、RAMバックスクラッチスペース — それぞれに従来の答えがあります。正直な並列比較です。
| 懸念事項 | Hoody データと状態 | 従来のスタック |
|---|---|---|
| マシン全体をロールバック | PATCH /containers/ID/snapshots/NAME | タープボール + 手動再デプロイ + 祈り |
| 実行中のメモリ状態をキャプチャ | POST /containers/ID/pause (pause/resume) | VMwareサスペンド + カスタムツール |
| コンテナ間ディレクトリ共有 | /hoody/shares + Shares API | NFSまたはSMBサーバーを自分で実行 |
| SQLiteへの同時書き込み | /hoody/databases (FUSE mount) | データレイヤーをPostgresで書き直す |
| RAMバックスクラッチスペース | /ramdisk (50% of host memory) | tmpfs + 慎重なulimits |
| 類似コンテナ間のストレージ重複排除 | BTRFS copy-on-write (built in) | rsync --link-dest、手動ポリシー |
| クロスサーバー状態レプリケーション | POST /containers/ID/copy + /sync | DIY rsyncループ + サービス再起動 |
特定のワークロードで既にマネージドVMスナップショットシステムを使用している場合は、そのワークロードではそのままにしてください。Hoodyの状態モデルは、求めているプリミティブが実際にコンテナレベルのタイムトラベルである場合にその価値を発揮します。
状態はすでにコミットグラフです。使い方を学びましょう。
ファイルシステムはすでに存在します。スナップショットはすでに存在します。マウントはすでに存在します。コンテナを起動すれば、状態モデル全体がライブになります。
関連情報 — /platform/control-planeでスナップショットとコピー/同期API、/kit/filesでクラウドバックエンド、/kit/sqliteでSQLite as HTTP。