把 OpenClaw 架到雲端 VM 上的維運踩坑紀錄
最近在實驗把 OpenClaw 跑在獨立的雲端 VM 上,而不是本機,主要是想解決兩個問題:本機給 high permission 一直讓我不太安心,加上想讓它能 24/7 穩定跑。
架在 EC2 上(我用 t4g.small,ARM64)之後整體比想像中穩定,但有幾個維運面的東西值得記下來。
openclaw.json 損毀問題
最頭痛的是某些 model 在特定狀況下會把 openclaw.json 搞壞,然後整台機器就起不來了。我在 staging 踩過這個坑之後才在 production 加上備份機制——現在是每次 config 更新前先 cp openclaw.json openclaw.json.bak,另外 cron 每小時抄一份到 S3。
一旦 openclaw.json 壞掉,機器等於是磚,SSH 也進不去(因為 gateway 沒起來)。解法是用 AWS SSM,不需要 SSH 就能進 instance 修。這個在上 production 之前一定要測過,不然深夜接到警報才在研究 SSM 怎麼用,會很痛苦。
安全性怎麼設計
我把 EC2 放在 private subnet,不對外開 port。OpenClaw gateway 走 internal load balancer,只允許特定 IP 進來。
有一個安全面要特別注意:機器上載入的 keys 要謹慎設定。建議是在放任何高權限 key(特別是能寄信的 credential)之前,先想清楚最壞狀況是什麼。Email 這個 attack surface 很容易被忽略,但一旦被利用影響會很大。
維運自動化
目前我在 AGENTS.md 裡把一些 AWS Linux 的 best practice 直接寫進去,讓 agent 知道這台機器的操作規範。比如不要直接 rm,要先 mv 到暫存再確認,disk 快滿前先發警報,之類的。
Health check 這塊搭了一個簡單機制:外部每分鐘 ping 一次 gateway,fail 超過 3 次就自動觸發修復流程。修復流程本身也是一個 OpenClaw agent,用另一組低權限 credential 進去跑,所有動作都有 log 留存,方便事後 review。
這個 self-healing 架構跑了一個月,目前救了 4 次——都是 openclaw.json 損毀或 process 被 OOM kill 的情況。
有在搞類似雲端部署架構的人嗎?想交流一下各家的設計方式。
作者:Bo-Han Chen