OpenClawは常駐プロセスと、セッションやトークンを失わない永続ストア、そして各チャット基盤から到達できる単一のHTTPS URLが前提です。2026年時点で現場で多いのは、Fly.ioのマシンにボリュームとマネージドTLSを載せる形か、汎用LinuxクラウドVPSでsystemdとリバースプロキシ、データ用ディレクトリのバインドマウントを組む形です。ここでは「どちらが速い」より、本番で折れる軸──状態の置き場、デプロイ時の公開URLの挙動、SlackやTelegramの再送とゲートウェイの相性、再起動でペア済みチャネルが壊れないヘルスチェックの配線──を整理します。
意思決定マトリクス（俯瞰）
ローリングデプロイ・エニキャスト経路・証明書更新をプラットフォーム任せにしたいならFly.io。固定のエグレスIP、任意カーネルモジュール、同一ホスト上の別エージェント、またはコンプライアンス境界を端から端まで握りたいならVPSです。ゲートウェイをループバックに閉じ、SSHや分割HTTPSで公開面を最小化するパターンは、OpenClaw on Linux：最小露出・ファイアウォールと入口のマトリクスFAQと併読すると判断が早いです。
| 観点 | Fly.io マシン | Linux VPS（systemd＋プロキシ） |
|---|---|---|
| 永続状態 | 同一リージョンのボリュームをアタッチし、OpenClawが期待する設定・セッション格納先にマウント。無いと再起動で揮発します。 | ディスク上の専用ディレクトリ（多くは/var/libやDockerボリューム）。スナップショットが移行の物語です。 |
| パブリックHTTPS入口 | FlyプロキシがTLS終端。内部待受とfly.tomlのサービス定義を揃えます。 |
ホスト上のCaddyやNginx。DNS・ACME・OCSPは自前運用です。 |
| Webhookコールバック | アプリごとに安定したホスト名。デプロイ順序で、SlackがURLを不健全と判定する前にリスナーが立っているか注意。 | URL規律は同様。ベンダー公開IP帯があればエッジでWAFや許可リストを足しやすいです。 |
| ヘルスチェック | 軽量な/healthzなどへのHTTPチェック。失敗時にマシンが差し替わります。 |
systemdのRestart=on-failureに加えUptime Kuma等。チャネル認証必須のパスをプローブにしないこと。 |
永続化：ボリュームとバインドマウント
Flyではマシンと同じリージョンにボリュームを宣言し、コンテナのエントリポイントが使う資格情報・チャネルメタデータ・ローカルキャッシュのパスへマウントします。共有ストレージなしでマシンを複数にスケールすると状態が分岐します。OpenClawは、マルチノードの公式意味が文書化されるまでは書き手インスタンスは一つが無難です。VPSでは非rootのサービスユーザー所有のバインドマウント先を一つにし、SQLite系ストアに耐える程度にクラッシュ整合なファイルシステムバックアップを取ります。ランタイム導入の前段チェックはLinuxクラウドVPSでのcurlインストールとDockerがそのまま効きます。
入口・Webhook・再送圧
各ベンダーは再送と短いレイテンシ予算を前提にイベントを届けます。ゲートウェイは速く応答し、可能ならエッジで署名検証し、重いモデル呼び出しはインラインでなくキューへ。Flyでは内部HTTPタイムアウトがベンダークライアントより長いと、重複配送が「リプレイ不具合」に見えます。NginxやCaddyではTLSハンドシェイク失敗と上流の500をログで分離し、証明書更新問題をアプリ障害と取り違えないようにします。開発ワークフロー側のOpenClaw利用はMCPサーバーとしてのトークン認証とセッション隔離も参照ください。
ロールアウトを生き残るヘルスチェック
プローブごとに第三者APIを叩かず、設定パースとボリュームマウントへの書き込み可否を確認する安いGETを用意し、「仕事をキューに積めるか」は観測基盤の合成チェックへ。Flyでは近傍ノイズで一時的にCPUが奪われてもマシンが入れ替わらないよう間隔を調整。systemdではバイナリがsd_notifyに対応していなければType=notifyに頼らず、終了コードとバックオフ上限で再起動嵐を避けます。stdoutだけを集めるコンテナでは、状態ディレクトリ配下のファイルログのローテーションや転送も揃えないと、ディスク満杯まで浅いヘルスは緑のままです。デュアルスタックではヘルスクライアントがIPv4かIPv6か既定でどちらを使うかも確認し、AAAAが死んだリスナーを指していてもループバックだけ緑、というすれ違いを防ぎます。
1. curl -v https://your-host/healthz # TLS と経路 2. ls -la $OPENCLAW_STATE_DIR # ボリュームはマウント済みか 3. journalctl -u openclaw -b # または fly logs --app … 4. WebhookシークレットとプロバイダUIの差分 # 401/403の黙殺ループ
FAQ：再現しやすい障害
Q: デプロイのたびにSlackのEvents URLが不健全になる。 トラフィックを切り替える前にリスナーを起動。プレビューと本番でパスを同一に。プロバイダUIの署名シークレットと実行環境変数を突き合わせます。
Q: 一晩でセッションが消えた。 多くは未マウントのボリュームか、イメージ層へ状態を書いたコンテナ。実行中タスク内でマウントを確認し、Dockerfileだけ見ないこと。
Q: ヘルスは緑だが利用者はタイムアウト。 プローブがlocalhostだけで、WebhookはTLSフロントが飽和しているパターン。VPC外からの合成チェックか外部監視を追加します。
Q: Flyでスケール後にマシンが複数。 リーダー選出や共有キューを設計するまでは水平スケールしない。さもないと重複Webhookが同じ下流自動化を競合させます。
長寿命の自動化と、本物のAppleワークフローを隣に置く
OpenClawのLinuxゲートウェイやFlyマシンは優れた置き場ですが、多くのプロダクトチームはXcodeや署名、ネイティブCLIのために静かで常時オンなmacOSの錨もまだ必要にします。クラウドMac mini M4ならUnix操作感に加え、待機電力わずか約4W、GatekeeperとSIPの多層防御、統合メモリ帯域でローカルエージェントを素早く保ちつつ、Linux側のエッジでWebhookを受けられます。
流用したWindows箱と比べると、Apple Siliconは長時間スクリプトでも温度が穏やかで、無人ジョブ中のクラッシュ率が低く、VPSと同じSSH鍵やHomebrewの流儀で運用を一本化できます──オペレータの頭の中のモデルを二重にしなくて済みます。
OpenClawと同じ信頼性バーでmacOS容量を足したいなら、VPSSparkのクラウドMac mini M4が現実的な次の一手です——プランを今すぐ確認し、ボット・ビルド・署名を一日中回せるハードに載せましょう。