2026年版 Linux VPS 上の OpenClaw Gateway：GitHub Actions CI/CD と手動 Docker デプロイ──意思決定マトリクス、再現手順、FAQ

小さな Linux VPS で OpenClaw Gateway を動かすのは単純に見えて、アップグレード・TLS・チャネルトークンが絡むと分岐が増えます。2026年現在、本質のフォークは「Docker を使うかどうか」ではなく、タグ付きイメージと設定を再現可能に押し出す自動化（GitHub Actions）にするか、SSH・compose・手動ロールバックに寄せて運用の透明さを取るかです。どちらも成立しますが、嫌がる障害モードが違います。上流での TLS 終端やプロキシ／NO_PROXY の切り分けが絡む場合は、2026 OpenClaw Linux クラウドVPSと社内／ローカルOllama接続：Gateway上流、TLS終端分離、SSHトンネルとNO_PROXYマトリクス——再現手順と502／タイムアウト層別排障FAQ のマトリクスもあわせて見てください。

意思決定マトリクス：Actions が勝つ場面／SSH が勝つ場面

チェックリストとして使ってください。「◎」は必須ではなく、その懸念がインシデントで顔を出したときの後悔が少ない、という意味です。

再現手順（GitHub Actions → Linux VPS）

概要のみです。レジストリやパスは環境に差し替えてください。狙いは「不変な成果物」と明示的なバージョン固定です。

1. ビルド──ワークフローがイメージをビルドし（タグ＋ digest）、レジストリへ push。本番では匿名の latest だけに依存しない。
2. シークレット──SSH_PRIVATE_KEY、ホストフィンガープリント、デプロイ用トークンを Actions の secrets に格納し、デプロイジョブの承認者を絞る。
3. リモート適用──ジョブが VPS に SSH し、ビルドした digest を pull、Git 外の小さな env を書き、docker compose up -d（または同等）を実行。
4. ヘルスゲート──ループバックまたは逆プロキシ越しに Gateway のヘルスを curl。TLS や上流ソケットが未準備ならジョブを失敗させる。
5. Webhook の対称性──Git 起点の自動化がネイティブビルド側にも連鎖するなら、コールバック URL と検証まわりは 2026年、LinuxクラウドVPSでのOpenClaw × Slack：Botトークン、イベント購読、ゲートウェイへのコールバックURL──再現手順と403／リプレイの段階的FAQ の段階整理と同じ規律で揃えるとハマりが減ります。

# VPS に SSH したあと:
export GATEWAY_IMAGE_DIGEST="sha256:…"
docker compose pull
docker compose up -d
curl -fsS http://127.0.0.1:<health-port>/health

再現手順（VPS 上の手動 Docker）

自動化よりも「何がどこに載っているか」の理解を優先するとき向きです。TLS 終端、systemd ユーザユニット、ボリュームマウントの感触を取りにいくフェーズに合います。

1. ホスト下地──必要なら 22/443 を許可、Docker と Compose プラグインを入れ、非 root のデプロイユーザを用意。
2. ピン留めイメージ──明示的 digest を pullし、compose の横に versions.txt などで記録。
3. 永続パス──トークン／セッション系ディレクトリを上流ドキュメントに沿ってマウントし、アップグレード前にボリュームをスナップショット。
4. 逆プロキシ──nginx や Caddy で TLS 終端。意図しない公開がなければ Gateway はループバック側に置く。
5. スモーク──バージョンを上げたあと openclaw doctor 相当を実行。systemd 利用時は journalctl --user にログを残す。

FAQ

CI/CD がバックアップの代替になるか

なりません。自動化は成果物を載せ替えますが、壊れた状態ディレクトリを蘇らせません。マウントデータのファイルシステムスナップショットや rsync 系の退避を別スケジュールで。

どちらが安いか

GitHub Actions は分数課金とレジストリ保管が乗ります。手動はインシデント時のエンジニア時間がコストになります。デプロイ頻度が週次を超える前は手動も現実的です。

混在──Actions でビルドだけし適用は手動でよいか

問題ありません。CI がイメージを push し、レビュー後に SSH で digest を昇格させる形なら、レジストリには監査痕が残りつつリモート compose 自動化は後回しにできます。