這篇是〈Zeabur 搬家前先換金鑰〉的 AI 服務專篇。停止營運的時程、退款、網域轉出的共通部分請看那篇，這裡只講 Dify、OpenClaw、One-API、LobeChat 這類 AI agent 與 LLM gateway 特有的地方。
文中 Zeabur 模板的內容引自模板頁公開的原始 YAML，各專案的做法引自各自的官方文件或 GitHub，文中官方資料的查詢日期是 2026 年 10 月 18–19 日；自家測試機的實測在 10 月 19 日進行。
先看你部署的是哪個模板
2026 年 10 月 19 日查詢時，Zeabur 模板市集共有 1,826 個模板。這四類服務裡，部署次數排前面的模板如下：
| 模板（代碼） | 發布者與部署次數 | 服務與映像 | 資料存在哪（Volume） |
|---|---|---|---|
| OpenClaw 🦞（VTZ4FX） | Zeabur，40,815 次 | OpenClaw：ghcr.io/openclaw/openclaw:2026.9.7 | /home/node |
| LobeChat（VZGGTI） | Lobehub，5,285 次 | lobechat：lobehub/lobe-chat（沒寫版本） | 沒有 Volume |
| One-API（7Q0KO3） | Zeabur，4,777 次 | MySQL：mysql:8.0.33；One API：justsong/one-api | MySQL 的 /var/lib/mysql |
| Dify（1D4DOW） | Zeabur，3,615 次 | 12 個服務，見下方 Dify 一節 | 6 個 Volume |
另外，名稱含 Dify 的模板共有 15 個，例如社群的〈Dify v1〉（ZDUBV4，304 次）；One-API 的衍生版〈New API〉（6FI58K，2,729 次）結構和 One-API 相同，只是映像換成 calciumion/new-api；伺服器資料庫版的〈LobeHub〉（FGYYQW，189 次）另外有 PostgreSQL 和 MinIO。社群模板的結構各不相同，先到 Zeabur 主控台確認你的專案實際有哪幾個服務、各自掛了哪些 Volume，再往下做。
要人代搬，可以看我們的PaaS 停運搬家與資安檢查服務。
為什麼要先換模型金鑰
Zeabur 官方狀態頁寫明，10 月這次事件中，攻擊者取得了平台資料庫的讀取權限，可能外洩的項目包括服務的環境變數、帳號資料、API token 與 zSend API key。狀態頁列出要用戶做的事，開頭就是輪換存在環境變數裡的所有密鑰。
AI 服務的環境變數裡，通常就放著會直接產生費用的模型 API key。搬家不會讓外洩的金鑰失效，把同一組金鑰貼到新平台，等於把外洩的鑰匙一起帶過去。所以順序是：先到模型供應商建新金鑰、換上、確認正常、撤銷舊的，再開始搬。
照這四個模板的 YAML，要換的金鑰如下：
| 服務 | 放在環境變數裡的金鑰 | 另外存在服務裡的金鑰 |
|---|---|---|
| OpenClaw | LLM_API_KEY（模型 API key）、OPENCLAW_GATEWAY_TOKEN（登入 Control UI 用）、有設的 TELEGRAM_BOT_TOKEN 等頻道 token | 模型金鑰也寫在設定檔 openclaw.json 與 SQLite 認證資料裡 |
| Dify | SECRET_KEY 等內部金鑰、資料庫、Redis、MinIO、Weaviate 的密碼 | 模型供應商金鑰是在 Dify 後台輸入，由 Dify 加密保存 |
| One-API | MySQL 密碼（SQL_DSN 裡） | 「渠道」裡的上游模型金鑰、「令牌」頁發出的存取令牌 |
| LobeChat | OPENAI_API_KEY（模板變數 API_KEY）、ACCESS_CODE | 使用者在自己瀏覽器裡填的金鑰 |
有三點要特別看：
1. OpenClaw 改環境變數不夠。 模板的啟動腳本只在設定檔不存在時，把 LLM_API_KEY 的值寫進 /home/node/.openclaw/openclaw.json（models.providers.custom.apiKey），之後改環境變數不會自動更新這個檔。模板說明也寫，要改模型設定是到「檔案」分頁或 Control UI 編輯 openclaw.json，再重啟服務。換金鑰時兩邊都要改。
2. Dify 的模型金鑰不在環境變數裡，但建議一樣換。 依 Dify 官方文件，模型供應商金鑰由每個工作區的 RSA 金鑰加密，解密用的私鑰放在檔案儲存裡；而這個模板的檔案儲存是同專案的 MinIO，MinIO 和資料庫的密碼都在環境變數裡。保守的做法是模型金鑰一律到供應商那邊換新。
3. 還在用 Zeabur AI Hub 的要改掉。 OpenClaw 模板早期版本接過 Zeabur AI Hub（變數 ZEABUR_AI_HUB_API_KEY）。Zeabur 9 月 22 日公告 AI Hub 正式停止服務，原句是「Existing API keys can no longer be used to send model requests」。設定裡還指向 AI Hub 的，換成你自己的模型供應商。
OpenAI、Anthropic、Gemini 等各家怎麼換、去哪看用量有沒有異常，見〈Zeabur 金鑰外洩後要換哪些？〉，這裡不重寫。
搬家順序：照 Zeabur 官方的跨帳號搬遷 7 步
Zeabur 官方〈搬遷專案〉文件寫了跨帳號搬遷的 7 個步驟，搬到別的平台也適用，AI 服務要多注意的地方寫在旁邊：
| 步驟 | 官方寫的 | AI 服務要多注意 |
|---|---|---|
| 1 | 匯出專案配置（YAML） | 匯出的 YAML 含環境變數，當成機密檔案保存 |
| 2 | 備份資料 | 資料庫用線上備份；Weaviate、MinIO、OpenClaw 等 Volume 要先暫停服務再備份 |
| 3 | 在目標建立新專案 | 新環境先用和 Zeabur 相同的版本 |
| 4 | 重新部署服務 | 內部金鑰在新環境重新產生，模型金鑰用搬家前已換好的新金鑰 |
| 5 | 還原資料 | 資料庫、向量庫、檔案儲存要是同一個時間點的備份 |
| 6 | 切換 DNS | 搬遷完成前先降低 DNS TTL |
| 7 | 驗證、清理舊資源 | 照文末的驗收表驗完，再停 Zeabur 上的服務 |
官方也提醒，搬遷期間暫停對舊專案的寫入，避免資料不一致。另外，依官方〈備份與還原〉文件，Zeabur 的備份只保留 7 天，按完備份一定要下載，存到 Zeabur 以外的地方。
Dify：12 個服務、6 個 Volume
官方 Dify 模板（1D4DOW）的 YAML 有 12 個服務：nginx、redis、db、minio、api、worker、worker-beat、web、weaviate、sandbox、ssrf-proxy、plugin-daemon。api、worker、worker-beat 用同一個映像 langgenius/dify-api:1.13.0，web 是 langgenius/dify-web:1.13.0。要帶走資料的是下面這幾個：
| 服務 | 資料在哪 | 怎麼匯出 | 要換的金鑰 |
|---|---|---|---|
| db（postgres:16） | /var/lib/postgresql/data；資料庫名稱 zeabur、帳號 root | Zeabur 線上備份（pg_dumpall 產生的 .sql） | POSTGRES_PASSWORD |
| weaviate（1.27.0） | /var/lib/weaviate；知識庫的向量資料 | 暫停服務後做 Volume 備份 | WEAVIATE_API_KEY |
| minio | /data；bucket 名稱 dify，存上傳檔案與工作區私鑰 | 暫停服務後做 Volume 備份 | MINIO_ROOT_PASSWORD |
| api | /app/api/storage | 暫停服務後做 Volume 備份 | SECRET_KEY 與內部金鑰（見下段） |
| plugin-daemon（0.5.3-local） | /app/storage；已安裝的外掛 | 暫停服務後做 Volume 備份 | PLUGIN_DAEMON_KEY |
| redis（redis-stack-server:7.4.0-v8） | /data | 見下方說明 | REDIS_PASSWORD |
nginx、web、worker、worker-beat、sandbox、ssrf-proxy 沒有掛 Volume，在新環境重建即可。
這個模板的金鑰是怎麼來的
模板裡 SECRET_KEY 沒有寫死，而是取自 api 服務的 API_SECRET_KEY，值是 Zeabur 為每個服務產生的隨機密碼 ${PASSWORD}。同一個值也拿來當 INNER_API_KEY、INNER_API_KEY_FOR_PLUGIN、PLUGIN_DAEMON_KEY，以及 plugin-daemon 的 SERVER_KEY 與 DIFY_INNER_API_KEY。資料庫、Redis、MinIO、Weaviate 的密碼也是各服務的 ${PASSWORD}。這些都在環境變數裡，屬於這次外洩範圍。
有一個值是固定的：sandbox 的 API_KEY 用的是 Dify 官方文件列出的預設值。新環境順手換成自己產生的值，官方文件寫明 api 端的 CODE_EXECUTION_API_KEY 和 sandbox 端的 SANDBOX_API_KEY 要一致。
SECRET_KEY 能不能換？
Dify 官方〈環境變數〉文件寫明，SECRET_KEY 用在 session cookie 簽章、JWT 登入權杖、檔案網址簽章，以及加密第三方 OAuth 憑證。官方警告原句是：「Changing this key after deployment will immediately log out all users, invalidate all file URLs, and break any plugin integrations that use OAuth—their encrypted credentials become unrecoverable.」
模型供應商的金鑰則不是用 SECRET_KEY 加密。同一份文件的 KEY_PROVIDER_TYPE 一段寫明，模型供應商 API key、工具憑證等工作區機密，由每個工作區的 RSA 金鑰對加密，預設私鑰存在 STORAGE_TYPE 指定的檔案儲存裡。官方文件把這兩件事分開說明，但換 SECRET_KEY 對模型金鑰有沒有影響，官方沒有直接寫。所以保守做法是先沿用舊值、搬完確認正常再換。
真正不能弄丟的是那組私鑰。官方〈Common Issues〉寫明，換部署方式或刪掉 api/storage/privkeys 後會出現加密金鑰找不到的錯誤，修復指令 flask reset-encrypt-key-pair 是不可逆的，所有工作區的模型與工具憑證都會被清掉、要重新輸入。所以檔案儲存（這個模板是 MinIO）一定要完整搬過去。
建議順序：新環境先沿用舊的 SECRET_KEY 還原，確認登入、應用、知識庫都正常後，再依官方說明換一組新的，換完通知大家重新登入，並把用 OAuth 的外掛重新授權一次。
新環境的版本要先對齊
- Dify 本身：官方 FAQ 寫了安裝指定版本的方法，用
git clone https://github.com/langgenius/dify.git --branch 1.13.0裝和模板相同的 1.13.0，資料還原確認後再升級。 - PostgreSQL：模板是 postgres:16，而 Dify 1.13.0 官方 docker-compose 預設是 postgres:15-alpine。PostgreSQL 官方文件寫明，pg_dump 的輸出不保證能載入比較舊的主版本，所以新環境的資料庫映像要改成 16 以上再還原。還原 pg_dumpall 的 .sql，官方寫法是
psql -X -f 檔名 -d postgres。 - 還原後改資料庫密碼：pg_dumpall 預設會連資料庫帳號與密碼一起匯出（官方另有
--no-role-passwords選項不匯出），還原後舊密碼仍然有效，記得改掉。新環境.env的 DB_DATABASE 要對上模板的資料庫名稱 zeabur；外掛服務用哪個資料庫，以 dump 裡實際的資料庫清單為準。 - Weaviate：模板和 Dify 1.13.0 官方 compose 都是 1.27.0，可以把 Volume 備份放進新環境的
./volumes/weaviate。之後要升到 Dify 1.17.1 時，官方〈Weaviate Server Upgrade Path〉寫明，Weaviate 會從 1.27.0 升到 1.39.2，既有資料無法一次跨過去，要照官方的版本階梯一個小版本一個小版本升，升級前先備份。 - 檔案儲存：模板把 STORAGE_TYPE 設成 s3、指向同專案的 MinIO；官方 compose 預設是本機檔案。比較單純的做法是新環境也用 S3 相容儲存（自架 MinIO 或雲端的物件儲存），把 dify bucket 整個複製過去，例如用 MinIO 的
mc mirror。官方文件只寫了「本機搬到雲端」的指令，沒有寫「S3 搬回本機」的做法，要搬回本機請以官方說明為準。 - 新環境的內部金鑰：Dify 1.13.0 官方的 docker-compose.yaml 裡，DB_PASSWORD、REDIS_PASSWORD、WEAVIATE_API_KEY、PLUGIN_DAEMON_KEY、PLUGIN_DIFY_INNER_API_KEY 都附了預設值。官方文件提醒 INNER_API_KEY_FOR_PLUGIN 的預設值公開在 Dify 的 repo 裡，要換掉。這幾個一律自己產生新的。
Redis 要不要搬，Dify 官方沒有單獨說明；官方的備份範圍是整個 docker/volumes 目錄。模板的 Redis 是 redis-stack-server 7.4，和官方 compose 的 redis:6-alpine 版本不同，舊資料檔不保證能讀。我們的建議是停機前先讓排隊中的工作跑完，新環境用空的 Redis 啟動，搬完照文末的表驗一次。
新機器要準備多大：我們實際裝了一次
我們在自己機房的一台測試虛擬機（4 核 CPU、8 GB 記憶體、60 GB 磁碟，Debian 13）上，用 Dify 官方的 docker compose 從頭裝了一次。版本是官方 compose 當時指定的 1.17.1，不是模板的 1.13.0，也只建了管理員、沒有放知識庫，所以下面的數字當作新機器的起跳量：
| 項目 | 實測結果 |
|---|---|
| 預設起幾個容器 | 15 個，向量庫是 Weaviate |
| 冷啟動（含下載映像） | 第 517 秒安裝頁打得開，第 564 秒可以建立管理員 |
| 磁碟 | 12 個映像共 11.23 GB；整台機器的已用空間多了約 11.5 GB |
| 記憶體 | 穩定後整台機器用掉 2,783 MiB，容器合計 2,460 MiB；8 GB 沒有出現記憶體不足 |
| 對外連接埠 | 80、443，另外開了 5003（外掛遠端除錯用） |
裝的過程裡，有三件事跟搬家有關：
- 用 release 版本，不要直接用 main。我們 clone 的是 main 分支，結果
local_sandbox容器一直重啟，錯誤訊息是flag provided but not defined: -require-auth-token：main 上的 compose 檔傳了 1.17.1 映像不認得的參數。這也是上面建議用--branch指定版本的原因。 - 官方 compose 的金鑰檔和私鑰都在
volumes/app/storage。.env的 SECRET_KEY 預設留空，Dify 會自己產生一組，存在volumes/app/storage/.dify_secret_key；檔案儲存預設也是這個目錄，每個工作區用來加密模型金鑰的私鑰在裡面的privkeys/底下。所以新環境要沿用舊的 SECRET_KEY 時，記得在.env明確填上，不要留空；之後備份或再搬家，這個目錄要整個帶走，只搬資料庫不夠。 - 5003 要收掉。外掛遠端除錯的連接埠由
.env的EXPOSE_PLUGIN_DEBUGGING_PORT設定，預設就對外開著，正式機器要用防火牆擋掉。
另外，冷啟動要下載約 11 GB 的映像，磁碟小的 VPS 要先留好空間。
知識庫要換向量資料庫的話
如果想趁搬家把 Weaviate 換成別的向量資料庫，官方〈Storage & Migration〉寫的做法是先改 VECTOR_STORE，再執行 flask vdb-migrate（Docker 是 docker exec -it docker-api-1 flask vdb-migrate），官方列出測試過的是 Qdrant、Milvus、AnalyticDB。建議先原樣搬過去、確認正常，再另外做這一步，不要兩件事一起做。
OpenClaw：整個 /home/node 都要帶走
OpenClaw 模板（VTZ4FX）只有一個服務，Volume 掛在 /home/node。依 OpenClaw 官方〈Where things live on disk〉，資料都在 ~/.openclaw：
| 項目 | 資料在哪 | 怎麼匯出 | 要換的金鑰 |
|---|---|---|---|
| 主設定 | ~/.openclaw/openclaw.json | 跟著 state 目錄一起備份 | 檔案裡的 apiKey |
| 認證、對話、agent 狀態 | ~/.openclaw/state/openclaw.sqlite、agents/ 底下的 SQLite | openclaw backup create | 模型與 OAuth 認證 |
| 頻道狀態 | ~/.openclaw/credentials/ | 同上 | Telegram、Discord 等 bot token |
| 工作區 | ~/.openclaw/workspace（AGENTS.md、MEMORY.md、skills） | 同上；官方建議另放私有 git repo | — |
官方〈Migration guide〉特別提醒，只複製 openclaw.json 不夠，模型認證存在 SQLite、頻道狀態存在 credentials/，要用備份與還原流程搬整個 state 目錄。
在 Zeabur 上備份，模板說明列了三種方式：用 Zeabur 的 Volume 備份；在主控台「命令」執行 openclaw backup create（2026.3.8 以上），再到「檔案」分頁從 /home/node 下載；或執行模板內建的 backup 指令。可以用 openclaw backup verify <檔名> 檢查備份檔。官方的搬機步驟是先停 Gateway 再備份，因為 SQLite 在寫入中直接複製可能不一致；在 Zeabur 上停 Gateway 等於停服務，所以排在沒人用的時段做。
在新機器還原，照官方〈Migration guide〉：
openclaw backup restore <archive.tar.gz> --target ~/openclaw-restored
openclaw doctor
openclaw gateway restart
openclaw status官方寫明還原不會直接覆蓋現有資料，要依還原出來的 manifest.json 把 state 與 workspace 放到位，或把 OPENCLAW_STATE_DIR 指向還原的目錄，並確認檔案擁有者是執行 Gateway 的使用者。指令以你安裝版本的官方文件為準。
備份檔本身就是機密。官方原句：「The state directory contains auth profiles, channel credentials, and other provider state. Store backups encrypted, avoid insecure transfer channels, and rotate keys if you suspect exposure.」下載後不要放在共用資料夾或聊天軟體裡。
名稱補充：Zeabur 模板頁寫 OpenClaw「原 Clawdbot、Moltbot」；OpenClaw 官方〈Uninstall〉文件也提到，很早期安裝升級上來的機器，可能還留著改名前的 clawdbot-gateway.service，openclaw uninstall 會自動偵測並移除。搜尋舊教學時看到這兩個名稱，指的是同一個專案。
One-API：資料都在 MySQL
One-API 模板（7Q0KO3）是 MySQL 8.0.33 加 justsong/one-api，One API 本身沒有掛 Volume，用 SQL_DSN 連到 MySQL 的 zeabur 資料庫，帳號是 root。
| 服務 | 資料在哪 | 怎麼匯出 | 要換的金鑰 |
|---|---|---|---|
| MySQL | /var/lib/mysql | Zeabur 線上備份（.sql）或 mysqldump | MySQL 密碼（新環境的 SQL_DSN 一起改） |
| One API | 沒有 Volume，資料在 MySQL | 不用搬，新環境重建 | 「渠道」裡的上游金鑰、「令牌」頁發出的令牌 |
One-API 的 GitHub README 寫明：不設 SQL_DSN 時用 SQLite，官方部署指令把 /data 掛到主機，資料庫檔案是 one-api.db；設了 SQL_DSN 就用 MySQL（或 PostgreSQL），使用 MySQL 升級不會丟資料。README 也寫明 root 初始密碼是 123456，登入後務必修改；搬家時順手確認有沒有改過。
金鑰的處理：上游的 OpenAI 等金鑰是在「渠道」頁設定，先到供應商換新，再到渠道更新。下游應用拿來呼叫 One-API 的「令牌」存在資料庫裡，資料庫密碼在環境變數裡，保守做法是重發令牌、更新到各個應用。New API（6FI58K）的結構相同，做法一樣。
LobeChat：先分清楚是哪一版
LobeChat 的資料存在哪，要看你跑的是哪一種：
| 版本 | 資料在哪 | 怎麼匯出 | 要換的金鑰 |
|---|---|---|---|
| 模板 LobeChat（VZGGTI），沒有資料庫 | 每位使用者自己的瀏覽器 | 每位使用者在舊網址的設定裡匯出資料 | OPENAI_API_KEY、ACCESS_CODE |
| 伺服器資料庫版（例如 LobeHub 模板 FGYYQW） | PostgreSQL；檔案在 S3 相容儲存（模板是 MinIO） | 資料庫 dump，加 MinIO 的 Volume 備份 | 資料庫與 MinIO 密碼、AUTH_SECRET |
VZGGTI 的伺服器上沒有對話紀錄。 這個模板只有一個服務，沒有 Volume，也沒有設定資料庫，映像沒寫版本。10 月 19 日查詢時，Docker Hub 上 lobehub/lobe-chat 的 latest 標籤對應 1.143.3，屬於 v1。LobeChat v1 官方文件寫明「LobeChat defaults to using a client-side database (IndexedDB)」，也就是對話存在使用者自己的瀏覽器裡。
要注意的是，瀏覽器的資料是依網址分開存的。MDN 文件寫明 IndexedDB 遵守同源政策，不同網域之間不能讀取彼此的資料。如果你原本用 xxx.zeabur.app 網址，搬到新網域後，新網址看不到舊對話。要請每位使用者在舊網址還連得到時先匯出。LobeHub 官方的 2025 年 4 月更新紀錄寫明資料匯出功能已上線；官方的 v1 搬到 v2 文件寫的位置是 Settings → Data Storage → Export Data（那份文件寫的是桌面版），網頁版的選單名稱以你那個版本為準。
這個模板的 ACCESS_CODE 寫了一組固定的預設值。官方說明這是進入 LobeChat 服務的密碼，沒改過的話，搬家時換成自己產生的長密碼。伺服器上的 OPENAI_API_KEY 在環境變數裡，一樣要先換。
要升到 v2 的話：LobeHub 官方〈2.0 Breaking Changes〉寫明，2.0 只支援伺服器資料庫模式，移除了瀏覽器端資料庫，也移除了 ACCESS_CODE，改用 Better Auth。官方的搬家文件也寫明，API key 這類機密不會跟著匯入，要在 v2 重新輸入。
伺服器資料庫版的 KEY_VAULTS_SECRET 不要換。 LobeHub 官方文件寫明，這個值用來加密使用者存在資料庫裡的 API key，原句是「Once set, do not change it, otherwise encrypted data cannot be decrypted.」搬家時沿用舊值；使用者存的模型金鑰，請大家到供應商換新後，在新環境重新填一次。
搬完要驗的 8 件事
| 檢查 | 怎麼看 |
|---|---|
| 1. 登得進去 | 用管理員帳號登入；Dify 換過 SECRET_KEY 的話，所有人都要重新登入一次 |
| 2. 歷史對話都在 | 抽 3 個舊對話打開；OpenClaw 看 Control UI 有沒有既有 session |
| 3. 知識庫完整 | Dify 知識庫的文件數、分段數和搬家前對得上 |
| 4. 向量檢索正常 | 用 Dify 的知識庫檢索測試，拿搬家前試過的問題問一次，看有沒有找回相同的段落 |
| 5. 模型呼叫成功 | 每個應用發一則測試訊息；到供應商後台確認是新金鑰有用量 |
| 6. 上傳與外掛正常 | 上傳一個小檔案；Dify 的外掛能列出、能呼叫；OAuth 外掛重新授權 |
| 7. 頻道還連著 | OpenClaw 跑 openclaw status，Telegram、Discord 等頻道不用重新配對 |
| 8. 舊環境已停 | 舊金鑰已撤銷；Zeabur 上的服務已暫停，Zeabur 的網址連過去不再回應 |
第 5 項很容易漏：服務能回話，不代表用的是新金鑰。到 OpenAI、Anthropic 等後台看用量，確認舊金鑰已撤銷、沒有新的呼叫。
揭露
火曜領航有提供 AI 服務的搬家、主機代管與金鑰輪換服務。這篇的步驟不需要找任何人也能自己做。
如果您的服務還在 Zeabur 上，需要人幫忙盤點、搬遷或輪換金鑰，可以到〈PaaS 停運搬家與資安檢查服務〉看四種做法，或直接填寫詢價表單，我們會在一個工作日內回覆搬遷順序建議。
常見問題
Dify 搬家要停機嗎？
要。Zeabur 官方文件寫明，Volume 的備份要先暫停服務；官方搬遷文件也建議搬遷期間暫停對舊專案的寫入。資料庫可以線上備份不用停，但 Dify 的資料分在資料庫、Weaviate、MinIO 幾個地方，要是同一個時間點的備份才對得上，所以整體還是要排一段停用時間。時間長短看資料量，排在沒人用的時段。
Dify 的知識庫（向量資料）要怎麼搬？
知識庫的資料分在三處：向量資料在 Weaviate 的 Volume（/var/lib/weaviate），上傳的原始檔案在檔案儲存（這個模板是 MinIO），其餘資料在 PostgreSQL。三者要在同一個停機時段備份，一起還原。Zeabur 模板和 Dify 1.13.0 官方 compose 的 Weaviate 都是 1.27.0，可以把 Volume 原樣放回。要換成別的向量資料庫，官方的做法是改 VECTOR_STORE 後執行 flask vdb-migrate。
自架 Dify 要多大的機器？
我們在一台 4 核 CPU、8 GB 記憶體的測試機上，用官方 docker compose 裝 Dify 1.17.1：預設 15 個容器，穩定後整台機器用掉 2,783 MiB 記憶體，沒有出現記憶體不足；映像佔 11.23 GB 磁碟。這是只建了管理員、沒有知識庫與使用者的起跳量，正式使用要再看知識庫大小與同時使用的人數。
OpenClaw 可以裝在自己的電腦或 VPS 嗎？
可以。OpenClaw 官方 FAQ 寫：「OpenClaw runs on macOS or Linux (Windows via WSL2).」也寫一台小 VPS、家用伺服器或 Raspberry Pi 等級的機器都可以。官方的建議是：要 24 小時穩定運作就用 VPS；可以接受電腦休眠、重開機會中斷的話，裝在自己的電腦上門檻低。搬家方式一樣，都是用 openclaw backup create 備份、在新機器 openclaw backup restore 還原。
換了模型 API key，Dify 裡要在哪裡更新？
Dify 官方〈Model Providers〉文件寫的位置是 Integrations → Model Provider：在供應商卡片按 Configure 管理金鑰；自己加的自訂模型，在那個模型上按 Configure。只有工作區的擁有者與管理員能管理供應商。介面名稱以你安裝的版本為準。
LobeChat 的對話紀錄存在哪？
看版本。沒有接資料庫的 LobeChat v1（例如 Zeabur 的 LobeChat 模板），官方文件寫明預設用瀏覽器端資料庫（IndexedDB），對話存在每位使用者自己的瀏覽器裡，伺服器上沒有；換網域後新網址讀不到，要在舊網址先匯出。伺服器資料庫版與 LobeHub 2.0 則存在 PostgreSQL，檔案存在 S3 相容儲存。
參考來源
- Zeabur 模板：OpenClaw 🦞（原始 YAML）
- Zeabur 模板：Dify（原始 YAML）
- Zeabur 模板：One-API（原始 YAML）
- Zeabur 模板：LobeChat（原始 YAML）
- Zeabur 模板：LobeHub、New API
- Zeabur Status：Unauthorized Access to Zeabur Infrastructure and User Data（2026 年 10 月事件）
- Zeabur 部落格：Zeabur 停止營運公告與服務遷移安排（2026-10-17）
- Zeabur Changelog：We’ve Shut Down AI Hub and Refunded（2026-09-22）
- Zeabur 文件：搬遷專案（2026-06-22 更新）
- Zeabur 文件：備份與還原（2026-05-08 更新）
- Zeabur 文件：環境變數（2026-03-19 更新）
- Dify 文件：Deploy Dify with Docker Compose、FAQs
- Dify 文件：Environment Variables（SECRET_KEY、KEY_PROVIDER_TYPE、VECTOR_STORE、STORAGE_TYPE）
- Dify 文件：Common Issues、Storage & Migration、Weaviate Server Upgrade Path
- Dify 文件：Model Providers
- Dify GitHub：docker-compose.yaml（1.13.0）
- OpenClaw 文件：Migration guide、Where things live on disk、openclaw backup
- OpenClaw 文件：FAQ: providers, hardware, and hosting、Uninstall
- One API：GitHub README
- LobeHub 文件：Build Your Own LobeHub、LobeHub 2.0 Breaking Changes、Migrate from v1.x Local Database to v2.x、環境變數
- LobeChat v1 文件（GitHub v1.149.0）：Server Database、Local / Cloud Database、環境變數 ACCESS_CODE
- Docker Hub：lobehub/lobe-chat
- PostgreSQL 文件：pg_dump、pg_dumpall
- MinIO 文件：mc mirror
- MDN：IndexedDB key characteristics and basic terminology
以上資料皆於 2026 年 10 月 18–19 日查詢。
最後更新：