GetClaw
GetClaw
Sign inGet started
返回網誌
openclaw部署安全私有AI

如何在私有 VPS 上執行 OpenClaw，而不暴露金鑰或本機檔案

一份實作導向指南，說明如何把 OpenClaw 自架在私有 VPS 上，用更清楚的隔離、金鑰管理與工具邊界來降低風險。

作者 Daniel MercerReviewed by GetClaw Editorial Team12 分鐘閱讀更新於

怎樣才算安全地執行 OpenClaw？

對大多數團隊來說，最實際也最安全的做法，是把 OpenClaw 放在私有 VPS 上，而不是直接跑在每天工作的筆電裡；同時把 API 金鑰留在伺服器端環境變數，收斂網路入口，並只讓 Agent 碰到它真正需要的檔案、工具與通道。

這樣做的核心目的，是縮小 blast radius。若某個 skill、MCP server、prompt injection，或訊息通道整合出現異常，影響範圍就不會直接擴散到你的私人檔案、瀏覽器工作階段與本機憑證。

為什麼不要直接在筆電上跑 OpenClaw？

在 MacBook 或桌機上直接執行 OpenClaw，很適合短時間測試，但通常會把高信任的人類資料與高自治的 Agent runtime 混在一起。

典型風險包括：

  • 個人 SSH 金鑰就放在同一台機器上
  • 瀏覽器登入狀態與 cookie 對本機使用者可見
  • Downloads、Desktop、Documents 與各種原始碼 repo 很容易被碰到
  • 工作與私人通道整合混在一起
  • 臨時安裝外部工具或社群 skill 時，隔離性很弱

拿來做 demo 沒問題，但如果要讓 OpenClaw 長時間持續運作，私有 VPS 通常會是更穩的預設。

比較安全的 OpenClaw 架構長什麼樣？

重點是：專用主機、分離祕密值、窄化網路暴露與明確工作區。

層建議做法為什麼重要
運算層專用 VPS 或私有 VM不讓 Agent runtime 跟日常工作機混在一起
祕密值環境變數或 secrets manager避免把金鑰寫進 repo
網路預設只開 SSH，其他流量逐項放行避免意外對外暴露
儲存僅限指定工作目錄限制 Agent 可讀寫範圍
整合層只接真正需要的通道與工具降低 prompt 或 skill 出錯時的影響
模型層透過 Gateway 或固定供應商設定統一進出比較容易審計與輪替金鑰

一個典型的簡化圖會像這樣：

手機 / Slack / Telegram
         |
         v
     OpenClaw
         |
         v
  私有 VPS 或 VM 邊界
         |
  +------+------+
  |             |
  v             v
受控工具與 MCP   模型 Gateway

第 1 步：先準備一台乾淨的私有伺服器

請為 OpenClaw 準備一台新的 Linux VPS，不要直接重用已經承載其他正式系統、個人備份或內部資料庫的機器，除非你非常清楚自己在做什麼隔離。

最低建議基線：

  • 新的 Ubuntu 或 Debian 主機
  • 一個非 root 的管理者帳號
  • 只允許 SSH 金鑰登入
  • 啟用防火牆
  • 啟用自動安全更新
adduser claw
usermod -aG sudo claw

mkdir -p /home/claw/.ssh
chmod 700 /home/claw/.ssh

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

如果你用的是像 GetClaw 這類私有 AI 主機，這些基線通常更容易建立，因為環境本來就是為 AI 工作負載準備的。

第 2 步：把 OpenClaw 裝在自己的目錄裡

不要把 OpenClaw 隨手丟進一個雜亂的家目錄。建議把 Agent runtime 收斂到專用路徑：

sudo mkdir -p /opt/openclaw
sudo chown claw:claw /opt/openclaw

cd /opt/openclaw
git clone https://github.com/openclaw/openclaw.git .

這樣做的好處是，之後日誌、記憶檔、工具輸出與工作目錄都會集中在可預期的位置，更容易審查、備份與收斂權限。

第 3 步：把 API 金鑰留在 repo 外面

不要把 API 金鑰、bot token、webhook secret 或登入 session 直接寫進 .env 範例並提交到 git。

最低可接受的做法，是讓它們留在伺服器端，例如：

sudo mkdir -p /etc/openclaw
sudo chmod 700 /etc/openclaw

sudo tee /etc/openclaw/openclaw.env >/dev/null <<'EOF'
OPENAI_API_KEY=replace_me
ANTHROPIC_API_KEY=replace_me
SLACK_BOT_TOKEN=replace_me
TELEGRAM_BOT_TOKEN=replace_me
EOF

sudo chmod 600 /etc/openclaw/openclaw.env
sudo chown root:root /etc/openclaw/openclaw.env

若你已有現成 secrets manager，當然更好，但至少不要把祕密值跟程式碼綁死在一起。

第 4 步：限制 Agent 能碰到的內容

OpenClaw 不需要整台機器才有用。請主動建立明確的工作目錄，讓 Agent 只在那些地方活動。

mkdir -p /opt/openclaw/workspace
mkdir -p /opt/openclaw/logs
mkdir -p /opt/openclaw/data

接著把 Agent、skills 與 MCP servers 指向這些路徑，不要預設掛載：

  • 個人 home 目錄
  • 團隊共享硬碟
  • 生產 SSH 金鑰
  • 瀏覽器 profile
  • 密碼管理器匯出檔

想讓 Agent 更安全，最直接的方法通常就是讓它根本碰不到那些不該碰的東西。

第 5 步：只接你真的需要的通道

OpenClaw 能接 Slack、Telegram、WhatsApp、Discord 等通道，這很方便，但不代表你第一天就該全部打開。

比較穩妥的上線順序會是：

  1. 先從一個內部 Slack bot 開始
  2. 驗證 prompts、工具權限與日誌
  3. 穩定後再加入第二個通道
  4. 外部或面向客戶的通道放到更後面

這樣可以減少入口面，同時讓你更容易看出是哪一類訊息把 Agent 帶偏。

第 6 步：把 MCP server 與社群 skill 當成程式執行邊界

MCP 很有用，但也很容易讓團隊在不知不覺中把 blast radius 放大。

啟用任何 MCP server 或第三方 skill 之前，至少先問：

  • 它能呼叫哪些命令或 API？
  • 它是唯讀還是可寫？
  • 它持有哪一組憑證？
  • 它能不能上公開網路？
  • 它會不會把本地檔案暴露超出原本範圍？

到了 2026 年，MCP 安全已經是主流議題。最安全的預設，通常是先唯讀，再按工作流需求逐步放寬，而不是一開始就給廣泛權限。

第 7 步：把 OpenClaw 放在 process manager 後面

請不要讓 OpenClaw 只靠某個 terminal tab 活著。用 systemd 之類的服務管理器，讓它能夠穩定重啟、集中讀取環境變數，也比較容易留下日誌。

[Unit]
Description=OpenClaw
After=network.target

[Service]
User=claw
WorkingDirectory=/opt/openclaw
EnvironmentFile=/etc/openclaw/openclaw.env
ExecStart=/usr/bin/npm run start
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

啟用方式：

sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
sudo systemctl status openclaw

第 8 步：若有多供應商需求，就加一層模型 Gateway

如果你的 OpenClaw 需要接多個模型供應商，請不要把多組金鑰與供應商邏輯散落在各個設定裡。加上一層 Gateway，管理上會清楚很多。

Gateway 可以幫你處理：

  • 金鑰輪替
  • 使用量追蹤
  • 多供應商故障轉移
  • 一致的請求格式
  • 比較清楚的審計邊界

這也是私有 AI 基礎設施有價值的原因之一：Agent runtime、Gateway、日誌與控制面可以留在同一個你能治理的環境裡。

一份實用的部署檢查清單

在你把系統視為正式環境之前，至少確認：

  • OpenClaw 跑在專用 VPS 或 VM 上
  • SSH 只允許金鑰登入
  • 防火牆預設拒絕外部進入
  • 祕密值不在 repo 裡
  • Agent 只碰特定工作目錄
  • 只連接必要訊息通道
  • MCP server 預設唯讀
  • 日誌有集中保存
  • 模型存取走同一條受控路徑
  • 備份不包含不必要的祕密或私人資料

什麼時候該用 GetClaw，而不是自己拼伺服器？

如果你想要的是自架的隔離優勢，但不想把時間花在通用型基礎設施準備上，那麼像 GetClaw 這種私有 AI 主機會更合適。

它尤其適合：

  • 你需要專用 AI 基礎設施，而不是共享主機
  • 你想要 root 權限來跑 OpenClaw、MCP server 或本地模型
  • 你希望模型 gateway 與 Agent runtime 在同一個環境裡
  • 你想要比個人電腦更清楚的安全邊界

結論

OpenClaw 的價值，正在於它可以跨工具、跨通道、跨模型地行動。也正因為如此，你不應該隨便把它放在同一台保存日常金鑰、私人檔案與瀏覽器登入狀態的筆電上。

比較穩健的模式很清楚：把 Agent 放上私有 VPS，把祕密值留在伺服器端，縮小檔案系統範圍，限制整合入口，並把每一個 MCP server 或 skill 都視為信任決策。這樣你才能保留自架自治的好處，而不把自己的工作機變成整套系統最脆弱的一環。

如果你想要一個已經具備 root 權限與私有 AI 基礎設施的地方來跑 OpenClaw，可以從 GetClaw 的私有 AI 雲 開始，再搭配 多模型 Gateway。

FAQ

OpenClaw 放在 VPS 上，真的比放在筆電上安全嗎？

對長時間運作的 Agent 來說，通常是。因為 VPS 讓你更容易建立乾淨的檔案、網路與祕密值邊界。

我應該自架 OpenClaw，還是用託管環境？

如果你只是想快速試用，先本地測試就可以。如果你要正式接通道、掛工具、長時間運行，受控的私有環境通常更合理。

OpenClaw 最常見的安全錯誤是什麼？

通常不是模型本身，而是把 Agent 放進權限太寬的環境裡，讓它能碰到過多檔案、憑證與工具。

來源與補充說明

準備部署你的 AI 雲了嗎？

3 分鐘內啟動你的專屬 AI 基礎架構，無需複雜設定。

開始使用

Not sure which path fits your deployment? Talk to us

Helpful next steps:Author directoryEditorial standardsSupport options

延伸閱讀

同一組 Agent、基礎架構與部署主題下的相關文章。