Zeabur 停運遷移指南：如何將網站與服務遷移到其他主機

依 INSIDE 於 2026 年 10 月 17 日轉述的使用者通知信，Zeabur 創辦人林沅霖宣布平台逐步停止營運：專用伺服器 12 月 1 日起停止續費並依到期日陸續關閉，共享叢集同日暫停，12 月 31 日前全面關閉。你的決策底線只有一條：在服務依到期日關閉前，把資料備份與網域切換做完。這份 Zeabur 遷移指南把最優先的行動順序排好了：盤點資產、確認方案備份權限、下載四類資料庫備份、輪替全部機密值，再進行新環境部署與 DNS 切換。

影片版：Zeabur 遷移的關鍵順序

開工前先看清三件事：時間軸、你的資產、被讀走過的機密

這次停運的硬期限比多數人直覺來得早。12 月 31 日是平台完全關閉的最終日，專用伺服器卻從 12 月 1 日起就停止續費並依各自到期日在當月陸續關閉，共享叢集也在同一天暫停。若專用伺服器在 12 月上旬到期，就不能把搬遷排到月底。依 INSIDE 轉述的通知信，共享叢集暫停後使用者仍可手動重新啟動服務備份資料；這可作為補救途徑，主要搬遷仍應提前完成。

計畫的基準日請用專用伺服器的到期時間，主要切換在 12 月 1 日前完成；把 12 月 31 日當成唯一死線、月底才開始動工的人，等到的是搶救，不會是遷移。

盤點資產從專案清單開始，一個服務一個服務列出六項資訊：部署來源（Git 儲存庫或 Docker 映像檔）、資料庫類型與版本、是否掛載持久儲存空間、對外網域清單、排程或背景工作、環境變數裡的機密清單。這份清單就是後續所有步驟的驗收基準。有兩個地方容易漏。Zeabur 對外埠由平台配置，官方文件建議程式監聽 $PORT 環境變數而不要把 8080 寫死，你的程式若有寫死埠的歷史債，趁這次搬遷一併處理；網域若當初是跟 Zeabur 購買的，官方已開放自助轉出，請提早確認移轉授權碼、註冊資料與 DNS 管理權限。換註冊商與切換網站 DNS 是不同作業，先確認各自的操作入口與時程。

機密輪替要立即開始，並確認服務已改用新值，原因寫在官方八月資安事件調查報告裡。8 月 27 日的攻擊鏈從一個使用者部署的 NextChat v2.16.1 服務的遠端程式碼執行漏洞切入，攻擊者取得路由快取中的高權限 Legacy API Key，再拿到 AWS root 金鑰與正式環境資料庫的讀取權，部分帳號資訊與專案環境變數的名稱和值都被讀走，內容涵蓋第三方 API 金鑰、資料庫密碼與各種服務憑證。八月事件狀態頁持續記錄同一事件的調查與處置。十月另一起事件的官方更新於 10 月 15 日 20:48 UTC（台灣時間 10 月 16 日 04:48）確認，部分 Google Cloud 專用伺服器也遭未授權存取，攻擊者取得平台資料庫讀取權限，受影響資料包括服務環境變數、帳號資訊、API token 與 zSend API key。

實務做法是把環境變數全部倒出來，對照下面這張表分成三類處理：

「必須換新」那一類是重點：官方確認部分專案的環境變數值遭讀取，並建議所有曾存放於 Zeabur、目前仍有效的憑證都預防性輪替。逐項到供應商後台重新產生、更新設定並重新部署，也要撤銷重發 Zeabur API token，再核對存取紀錄與費用。十月事件的官方處置清單另要求 Google Cloud 專用伺服器使用者更換 root 密碼，移除不認得的 SSH key，特別是標示 zeabur-pentest 的項目；使用 Zeabur Email／zSend 者也須建立新的 API key。

方案等級決定你能不能用平台的備份機能。官方定價頁列得明白：Free 方案沒有資料庫備份匯出匯入，備份機能從每月 5 美元的 Dev 方案起跳。還在 Free 方案的人有兩條路：花一個月 5 美元升級換取圖形介面一鍵備份，或改用本機資料庫用戶端，透過可連線且有足夠讀取權限的連線字串匯出。還原方式必須跟輸出格式配對，例如 PostgreSQL 平台備份的文字 .sql 用 psql，自行執行 pg_dump -Fc 的 custom archive 則用 pg_restore，不能共用同一條還原指令。

遷移目的地怎麼選：五個常見替代的比較

收到停運信後最常見的兩個誤判，都跟官方的「搬遷專案」文件有關。文件裡的跨區域搬遷走的是「複製專案」功能，把整個專案的服務配置、環境變數與硬碟資料一鍵複製到另一個區域，這條路只解決區域問題，目的地仍然是 Zeabur 自己的機器，平台關了它也跟著關；另一條「跨帳號搬遷」同樣是以另一個 Zeabur 帳號為目的地。真正的遷移是把設定、資料、網域三樣東西搬到你有掌控權的地方，官方跨帳號搬遷文件的七步流程可作為參考：匯出專案配置、備份資料、建立目標專案、重新部署、還原資料、切換 DNS、驗證後清理。跨平台時，要改成目標平台支援的部署與還原方式。

選替代方案時，成本結構比月費數字更需要先看清楚。PaaS 類平台的應用、資料庫、磁碟與流量可能分別計費，靜態站與常駐容器也適用不同計價方式；VPS 路線的機器月費較固定，但你得自己處理系統更新、憑證與監控。常見的替代方案有五個：Railway、Fly.io、Render、自架 VPS 加 Docker Compose，以及 Cloudflare 的邊緣路線。前四個先用同一張表比，資料以各平台官方頁面 2026 年 10 月中旬的公開資訊為準，Cloudflare 放在表後單獨談。

Railway 的 Hobby 方案是使用習慣上最接近 Zeabur 的替代方案：Git 推上去就建置、環境變數在介面裡點開就改、資料庫當成服務開，每月最低 5 美元，含等值用量，超過才按實際資源計費。Render 的定位類似，靜態站與背景工作的支援完整。走到省錢與控制的兩端，一端是 Cloudflare 的邊緣運作體系，靜態資產與 Workers 常有免費額度可用，網站若同時經營內容流量，把 DNS 遷到 Cloudflare 時，也可一併檢查 AI 爬蟲的辨識與存取規則，設定方式可參考我們先前的Cloudflare AI 爬蟲分類與設定整理；另一端是 VPS 上用 Docker Compose 自管，需要依應用記憶體、資料庫容量與尖峰流量選規格，憑證續期、系統更新、日誌輪替也全部回到你手上。

以正式內容網站為遷移目標時，要把 Render 免費層的休眠限制算進去：Free Web Service 閒置 15 分鐘後會休眠，休眠時平台對 /robots.txt 回傳 disallow all，而且這個請求不會喚醒服務。需要穩定提供網頁給使用者與搜尋爬蟲的網站，應評估常駐的付費服務。表內 Fly.io 與 Render 的應用費、資料庫費及磁碟費須分開估算，可對照 Fly.io 資源價格及 Render 官方價格比較。

替代方案建議在 11 月第一週就定案，理由是後面每一步都跟它綁定：資料庫還原指令、環境變數名稱、網域綁定方式全都不一樣。方案還沒定就急著下載備份沒問題，備份格式跟平台無關；但還沒定就開始改程式碼，會出現改完又改的重工。

Step by step 操作截圖：從 Zeabur 搬到 Railway 或 Render

以下主線用「GitHub 原始碼＋一個 PostgreSQL 資料庫、沒有本機上傳檔案」示範，先完成共用準備，再選 Railway 或 Render 其中一條路線。沒有資料庫的網站可略過資料庫步驟；WordPress 常用的 MySQL、MongoDB 與 Redis 請用後面的對應工具處理。有 uploads 或 SQLite 的服務還要另做磁碟檔案還原。這兩條路線都要重新建立服務，不能直接匯入 Zeabur 的 YAML；多個 API 或背景工作也要逐個重建。

以下介面截圖取自各平台官方文件與官方部落格。圖中的儲存庫、網域、區域與版本是示例，請換成自己的專案設定；每張圖下方附有原始來源。

共同準備：先拿到程式、備份與新機密

準備步驟 1：匯出設定清單

在 Zeabur 開啟專案，依序選「設定 → 一般設定 → 匯出」，下載 YAML。另記下 GitHub 儲存庫、branch、root directory、Build Command、Start Command；若用 Docker 映像檔部署，記下完整映像名稱與版本。YAML 可能含機密，保存在受控位置，不要上傳公開 Git 儲存庫。

準備步驟 2：下載資料，記住檔案寫在哪裡

資料庫可到服務的「備份」分頁建立並下載備份；沒有該功能或要做單一 PostgreSQL 資料庫搬遷，可用下方指令自行匯出。另逐項記錄 uploads、SQLite、附件等資料的容器內絕對路徑，下載對應 Volume 備份；沒有本機檔案的服務可略過。

準備步驟 3：準備新環境變數

一般設定值沿用，機密值到各供應商重新產生；資料庫與 Redis 網址等目標服務建好後再填。預演時關閉寄信、付款、排程與 queue worker，避免新舊環境重複執行正式工作。正式切換前還要再停寫並製作最後一份備份。

PostgreSQL 單庫備份可用下列 Bash 範例。先安裝與目標資料庫同主版本的 pg_dump／pg_restore，目標主版本不得低於來源，並核對必要 extensions。從 Zeabur 資料庫的連線資訊取得本機能連線的公開網址與埠；Zeabur 內網 hostname 不能直接供自己的電腦連線。read -r -s 會讀入但不顯示連線字串，貼上後按 Enter，不必把密碼寫進指令歷史。

# 在自己的 Bash 終端機貼上 Zeabur 的來源資料庫連線字串
read -r -s SOURCE_DATABASE_URL

# 一個應用資料庫產生一份 custom archive
pg_dump --dbname="$SOURCE_DATABASE_URL" --format=custom --file=zeabur-app.dump

這份 zeabur-app.dump 要用 pg_restore 還原，與 Zeabur 平台下載的全庫 .sql 格式不同；官方 pg_dump 文件說明了單庫範圍、格式與版本相容條件。先用這份備份演練；正式切換時換用停寫後的新備份。

路線 A：Zeabur → Railway，逐步重建新環境

步驟 A1：連接原來的程式

登入 Railway 建立專案，選 Deploy from GitHub repo，授權正確儲存庫，核對 branch；monorepo 再設定 Root Directory。保留原應用的建置與啟動命令。若應用會自動執行 migration 或 seed，先不要接上目標資料庫，等還原完成才部署。

步驟 A2：在同一專案新增 PostgreSQL

按 + New → Database → Add PostgreSQL 新增資料庫，先確認版本與容量。從自己電腦還原時，到資料庫 Settings → Networking → Public Access 建立公開存取，取得 DATABASE_PUBLIC_URL；它與應用程式使用的私有網址不同，詳見 Railway PostgreSQL 連線說明。

步驟 A3：把備份還原到新的空白資料庫

在本機貼上剛取得的 DATABASE_PUBLIC_URL，執行以下指令。若出現 extension、權限或 SQL 錯誤，先處理錯誤；不要以指令結束代替資料驗收。

read -r -s TARGET_DATABASE_URL
pg_restore --dbname="$TARGET_DATABASE_URL" --no-owner --no-privileges --exit-on-error zeabur-app.dump

還原後對照來源的關鍵資料表筆數、最大 ID 與最新紀錄，確認讀得到原有資料。這個範例不會自動清空已有資料的目標庫。

步驟 A4：填入環境變數

打開應用服務的 Variables → RAW Editor，加入準備好的設定值與新機密。如果資料庫服務叫 Postgres，將應用的 DATABASE_URL 設為 ${{Postgres.DATABASE_URL}}；服務名不同就用介面提示選實際名稱。這樣應用會走私網，不必長期用公開代理。檢查變更並 Deploy 才會套用，操作可對照 Railway 環境變數文件。

步驟 A5：需要保存檔案，就掛 Volume 並還原

替原本有本機資料的服務新增 Volume，Mount Path 必須對上程式實際寫入的絕對路徑。使用 Railpack 且程式寫 ./data 時通常是 /app/data；自訂 Dockerfile 要以自己的 WORKDIR 為準。磁碟不會自動帶入 Zeabur 檔案，依平台支援的檔案傳輸方式另行還原後，抽查檔案可下載。Volume 文件也提醒磁碟在 runtime 掛載，不能把還原安排在 build 階段。

步驟 A6：用測試網址驗收功能

Deploy 後看 Logs，確認服務監聽 0.0.0.0 與平台的 PORT。到 Settings → Networking → Public Networking → Generate Domain 取得測試網址，檢查登入、讀寫與檔案；有 OAuth 時另設測試 callback。

步驟 A7：加入正式網域，準備 DNS 切換

通過後在 + Custom Domain 加入正式網域，記下畫面提供的 CNAME 與 TXT；等到下方正式切換階段才改指向。Railway 網域文件目前要求這兩筆記錄，不能只填 CNAME。

路線 B：Zeabur → Render，先建資料庫再建網站

步驟 B1：先建立 Postgres

在 Render 選 New → Postgres，挑與應用相同的 region，核對資料庫版本及容量。正式承接資料時要選可長期運作的方案：依 Render 免費方案限制，Free Postgres 在建立 30 天後到期且沒有備份；Free Web Service 也不能掛 Persistent Disk。

步驟 B2：用 External URL 還原

到資料庫頁的 Connect 複製 External Database URL，在自己的 Bash 終端機執行下方指令，把備份還原到新空白資料庫。外部連線需要 TLS；同帳號、同 region 的 Render 應用稍後使用 Internal Database URL，詳見 Render Postgres 連線文件。

read -r -s TARGET_DATABASE_URL
PGSSLMODE=require pg_restore --dbname="$TARGET_DATABASE_URL" --no-owner --no-privileges --exit-on-error zeabur-app.dump

確認還原沒有未處理錯誤，再比對關鍵資料表與原有紀錄。

步驟 B3：建立 Web Service 並連 GitHub

選 New → Web Service → Git Provider，指定原儲存庫與 branch，填入應用實際使用的 Root Directory、Build Command 與 Start Command，region 與資料庫一致。只有輸出靜態 HTML／CSS／JS 的站才選 Static Site；SSR 或 API 要用 Web Service。欄位可對照 Render 首次部署流程，不要把別的框架的啟動指令照抄過來。 若原應用沒有 Pre-Deploy Command，先留空；不要照抄圖中的 migration 範例。

步驟 B4：加入變數，必要時加磁碟

在建立服務表單的 Environment Variables 區塊，或既有服務的 Environment 頁面，按 Add from .env 加入新設定，DATABASE_URL 填同區域資料庫的 Internal Database URL；Render 不會解析 Railway 的 ${{...}} 語法。儲存時選擇重新部署，才能套用新值，見 環境變數設定。若有 uploads 或 SQLite，使用付費服務到 Disks 新增 Persistent Disk，再還原檔案；只有 Mount Path 下的檔案會保存，細節見 磁碟文件。

步驟 B5：用測試網址驗收功能

部署顯示 Live 後，開啟服務的測試網址，檢查登入、資料讀寫及附件。若出現 port 錯誤，確認監聽 0.0.0.0 並讀取 PORT，可參考 Web Service 網路設定。

步驟 B6：加入正式網域，準備 DNS 切換

驗收後到 Settings → Custom Domains → + Add Custom Domain，依提供的 DNS 記錄準備切換；正式切換後回來按 Verify，確認 HTTPS 憑證正常，流程見 自訂網域文件。

若服務有本機上傳檔案，完成磁碟掛載後再接著做下面的傳檔步驟；沒有本機檔案的專案可直接進入正式切換。

有 uploads 的服務：把備份傳進新磁碟

1. 在本機解開備份。確認檔案實際位於 ./uploads，沒有多包一層目錄。以下範例假設新平台磁碟掛在 /var/data，目的地尚無正式資料、且目前使用者可寫入；傳檔會覆寫同名檔，請先確認目標是這次新建的環境。
2. 啟用平台支援的 SSH 連線。Railway 先依 SSH 文件完成 CLI 登入、專案連結與 SSH key 登記；Render 的付費服務則先在帳號登記 SSH 公鑰，再從 Connect → SSH 複製連線帳號與主機，條件見 Render SSH 文件。
3. 選對平台的指令傳入目錄。下列 Railway 網域、Render 帳號與區域主機都要換成自己服務的實際值。兩條指令擇一執行；目標會得到 /var/data/uploads。

   # Railway
   scp -s -r ./uploads [email protected]:/var/data/
   
   # Render
   scp -s -r ./uploads [email protected]_REGION.render.com:/var/data/

   若自己的掛載點不同，連同指令目的地一起修改。
4. 修改應用的上傳路徑並抽查。讓程式讀寫 /var/data/uploads，確認執行帳號有權限；挑舊附件下載，再上傳一張測試圖片，重新啟動服務後確認仍可讀取。SQLite 要使用一致性備份並傳成新的檔名，驗證後再切換應用的資料庫路徑，不能覆寫程序正在使用的主檔。

做到這裡，新環境應已能用測試網址運作，正式流量還在 Zeabur。正式切換時，先停新舊兩端的寫入，重做最後備份，還原到另一個新的空白正式資料庫，再把應用的 DATABASE_URL 改到正式庫並 Deploy、對帳；有檔案的服務也要補上最後一份檔案備份。不要將目前的 pg_restore 直接重跑到已有演練資料的庫。多個 API、worker、cron 或資料庫要逐一套用；完整切換順序接下方「網域與 DNS」一節。

資料庫搬移：四種資料庫的備份格式與還原指令

備份保留時間要先確認。官方備份與還原文件寫明，平台端備份只保留 7 天，超過自動刪除；下載到自己儲存空間的副本不受這條保留規則限制。從現在到切換完成前，依資料變動頻率定期下載新備份，正式切換則必須另做停寫後的最終備份。文件同時提醒：沒有掛載持久儲存空間的服務根本不會顯示備份功能，資料庫服務預設有儲存空間，但自建容器若沒掛 Volume，未持久保存的資料可能在服務重新啟動或更新時遺失。

四種資料庫的輸出格式各不相同。Zeabur 的 PostgreSQL 平台備份用 pg_dumpall 建立，輸出涵蓋服務內所有資料庫的文字 .sql；MySQL 與 MariaDB 輸出同樣是 .sql，範圍是所有非系統資料庫；MongoDB 備份是一個目錄裡的多個 .bson 檔案。PostgreSQL 遷往受管資料庫時，可優先針對每個應用資料庫各自用 pg_dump -Fc 匯出 custom archive，再還原到目標平台的空資料庫；它與平台全庫 SQL 的格式、範圍不同。下方指令中的來源與目標連線資訊都要分開設定。Redis 的整份 RDB 匯入方式則須先確認目標平台支援，不能把整份 .rdb 當成單一 key 交給 RESTORE。

# PostgreSQL 有兩條獨立路徑，依備份格式擇一，不要連續執行兩種還原
# 路徑 A：每個要搬的應用資料庫各匯出一次 custom archive
pg_dump --dbname="$SOURCE_DATABASE_URL" --format=custom --file=zeabur-app.dump

# custom archive 用 pg_restore；目標必須是專用的空資料庫
pg_restore --dbname="$TARGET_DATABASE_URL" --no-owner --no-privileges --exit-on-error zeabur-app.dump

# 路徑 B：平台下載的 pg_dumpall 文字 .sql 才用 psql
# 先確認全庫 SQL 中的角色、CREATE DATABASE 與連線目標符合新平台權限
psql -X --set=ON_ERROR_STOP=on --dbname="$TARGET_DATABASE_URL" --file=zeabur-postgres-backup.sql

# MySQL / MariaDB：此例限不含 CREATE DATABASE／USE 的單庫 SQL
# 先在新環境建立空白 yourdb，並核對 SQL 內容後匯入
mysql -h your-new-host -u admin -p yourdb < single-database.sql

# MongoDB：yourdb 須對應備份目錄中的原資料庫名稱
# 將指定資料庫還原到空白目標，遇錯停止
mongorestore --uri="mongodb+srv://new-cluster/" --nsInclude="yourdb.*" --stopOnError ./zeabur-mongo-backup/

上面的 MySQL 指令只適用於不含 CREATE DATABASE／USE 的單庫 SQL。Zeabur 平台下載的 SQL 涵蓋所有非系統資料庫，命令列的 yourdb 不會阻止檔案內的 USE 切換資料庫；匯入前須檢查庫名、建庫語句與目標權限，必要時改用單庫備份，詳見 MySQL 官方還原說明。MongoDB 則先核對來源與目標的主版本／FCV，範例的 yourdb.* 對應原資料庫名稱；要更名時使用 --nsFrom／--nsTo，依 mongorestore 文件調整，並核對還原結果。

兩個實務細節要分開處理。Redis 的 RESTORE 接受 DUMP 產生的單一 key 序列化值，TTL 單位是毫秒，0 代表永不過期；DUMP 本身不帶到期時間，逐 key 搬移時需另外讀取 PTTL 並保留原本的到期語意。可重建的快取可在新環境重建，不能把仍有效的 session 或未完成工作一概當成快取丟掉。PostgreSQL 的 --no-owner --no-privileges 是上方 pg_restore 的選項，不能加在 psql 後面處理已下載的 SQL。平台全庫 SQL 可能包含角色建立、資料庫建立與切換連線，受管平台帳號未必有權執行；請先檢查內容與目標權限，或改用逐庫的 custom archive。完整說明見 PostgreSQL 官方備份文件與pg_restore 文件。

資料庫之外的持久儲存空間走另一套操作。官方文件的做法是先把服務暫停，到備份分頁按下備份，等背景工作跑完，下載整個掛載目錄的打包內容；演練完成後可重新啟動服務，正式切換的最終備份則要維持停寫，直到新環境接手。檔案量少的時候，直接用檔案管理介面逐個拉下來也行。上傳端看新環境的對應機制：PaaS 平台各有自己的 Volume 設計，VPS 就是 scp 或 rsync 進目錄。圖片上傳資料夾、SQLite 資料檔這類資產最常在這一步被漏掉，因為所有人的注意力都在資料庫，應用程式自己寫進磁碟的東西沒人點名。

等不了平台備份排程、或想在兩輪備份之間多抓一份的人，可從資料庫服務的連線資訊自行匯出。PostgreSQL 的 pg_dump --format=custom 與 pg_restore 是一組，支援平行還原與選擇性還原；每次只匯出一個資料庫，不包含其他資料庫或 cluster 級角色。Redis 的 redis-cli --rdb 會下載整份資料集 RDB，必須透過目標平台支援的 RDB 匯入方式還原；若需逐 key 搬移，SCAN 只負責列舉 key，還需要搭配序列化值與到期資訊的處理。官方持久化文件說明 RDB 與 AOF 的差異；搬遷前先判斷 Redis 是可重建的快取，還是存有必須保留的資料，再決定匯入方法。

版本相容是 PostgreSQL 搬遷的隱形門檻。先確認來源與目標伺服器的主版本，目標不得低於來源；pg_dump 與 pg_restore 使用和目標相同主版本的用戶端，避免匯出工具比目標更新。pg_dump 不能匯出比自身主版本更新的伺服器；還原到較舊主版本也不保證相容，例如來源為 PostgreSQL 16、目標為 14 時，應先調整目標版本再演練。擴充套件與平台權限也要逐項核對，不能只看主版本相同就當作一定能還原。

抓備份的時間點也有講究。官方搬遷文件建議在搬遷期間暫停對舊專案的寫入操作，避免資料不一致。正式切換時，先讓新舊兩端進入維護或唯讀模式，暫停背景工作、排程、webhook 等寫入入口，等待進行中的交易完成，再製作最終資料庫與檔案備份。還原到新建的空白正式資料庫，將新站 app 的 DATABASE_URL 指向它並重新 Deploy，在維持停寫的狀態下完成對帳，再切換 DNS。舊環境要持續停寫，直到新環境接手；只在新環境恢復寫入，避免備份完成後舊站又產生新資料。維護時間應依實際演練所需時間安排，不能預設十分鐘就能完成。

線上備份能提供資料庫在特定時間點的一致性內容，但不會自動包含備份之後的新訂單。正式切換必須以所有寫入入口停妥、交易完成後的最終備份與對帳結果為依據，不能只看備份下載成功就切換。

服務定義與環境變數：把匯出的 YAML 當成重建清單

服務設定的搬移起點是官方的匯出功能。到專案設定的一般設定點匯出，會拿到一份描述整個專案的 YAML 檔，內容涵蓋 Docker 映像檔引用、Git 儲存庫位置、環境變數清單與硬碟掛載資訊。文件在頁面最上方用提示框反覆強調一件事：匯出不包含資料。YAML 給你的是骨架，血肉（資料庫內容、Volume 檔案）要靠上一節的備份補，兩條線不能互相替代。

拿到 YAML 不等於搬完家，資料還留在即將關閉的平台上；把它當重建清單用，資料交給備份與還原，兩邊各自到位，遷移才算完成。

若只是要在 Zeabur 帳號之間搬，可以用 CLI 把 YAML 匯回：npx zeabur@latest template deploy -f 專案.yaml，指令會引導你選目標專案或建新專案，這是跨帳號搬遷的官方路徑。遷往其他平台時這個指令用不上，YAML 的價值變成對照文件：逐段把服務定義翻譯成新平台的等價物，映像檔引用變成 Docker 服務宣告，硬碟掛載變成 Volume 或磁碟區，環境變數逐欄搬進新平台的變數管理介面。翻譯過程最大的坑是跨帳號文件裡那句提醒，含機密值的環境變數需要手動重新設定，即使目標平台能匯入變數清單，曾存放於 Zeabur、目前仍有效的憑證也應依官方建議預防性輪替，搬過去的應該是新值。

排程與背景工作是翻譯時最容易被略過的一段。cron 定義與 worker 設定照著 YAML 逐項搬到新平台，真正的麻煩在時區：Zeabur 的自動備份時段以 UTC 標示，官方文件提醒要自行換算當地時間，你自建的排程搬到目標平台後，對方的時區預設不會跟你打招呼，差八小時的報表寄送或凌晨清理任務就這樣上線。把時區明寫進排程定義、統一用 Asia/Taipei，或全隊約定一律以 UTC 標示並寫進文件，兩者擇一貫徹到底。

環境變數的驗收有個省力的辦法：在新環境先把服務跑起來但不對外開網域，打內部健康檢查端點，讓程式在啟動時就對每個外部依賴做一次連線測試並把結果吐進 log。資料庫連不上、Redis 沒權限、第三方金鑰無效，這三類錯誤會在第一時間浮出來，而不是等真實流量進來後才爆。

網域與 DNS：切換與回滾的執行順序

先完成新環境演練，再排正式切換。DNS 快取更新有時間差，因此舊站與新站不能各自接受寫入；照以下順序操作：

1. 確認網域與 DNS 控制權。網域註冊商、DNS 代管與網站主機是三件事。若現有 DNS 可繼續使用，搬主機時可直接修改記錄，不必先換註冊商。若網域向 Zeabur 購買，另行提早辦理轉出，確認授權碼與註冊資料；不要把這項手續留到切換當天。
2. 需要搬 DNS 代管時，先完成這一步。在新 DNS 代管端完整建立 A、AAAA、CNAME、MX、TXT 等現有記錄，尤其是郵件使用的 SPF、DKIM、DMARC，並檢查 DNSSEC／DS；若舊 DS 不再適用，須依新代管商指引處理後才能更換 nameservers。用 dig 比對新舊權威 DNS 的記錄，驗證新代管已生效，再處理網站指向。以 Cloudflare 為例，官方移轉流程要求先啟用 Cloudflare DNS，再移轉註冊。
3. 降低網站記錄 TTL，並讓新環境完成預演。在平台允許的範圍內將網站 A、AAAA 或 CNAME 的 TTL 降到約 300 秒，並至少等原 TTL 經過後再切換；提前一天安排可留出檢查時間。先用測試子網域（例如 staging.你的網域）驗證登入、下單、API 認證與上傳，並在新平台加入正式網域、確認驗證與 TLS 憑證所需步驟。低 TTL 有助縮短快取時間，但不能保證所有使用者五分鐘內看到新站。
4. 停寫、最終還原並切換 app 資料來源。暫停新舊兩端所有寫入入口、排程與背景工作，等待進行中的交易完成，再製作 final dump 與持久檔案備份。建立新的空白正式資料庫並還原，不要直接把最終備份重跑到有演練資料的資料庫；還原檔案後，將新站 app 的 DATABASE_URL 與檔案路徑改為正式目標，重新 Deploy，並維持停寫。比對停寫後的關鍵資料與檔案，確認 app 已連到正確的正式資料庫，通過後才切換 DNS。
5. 切換網站記錄，只讓新環境恢復寫入。依目標平台指示修改相關 A、AAAA 或 CNAME，確認沒有殘留指向舊站的記錄；檢查正式網域的 TLS 憑證、解析結果與新站 log。先做一筆可辨識的測試寫入，確認確實進入新資料庫，再恢復新站流量與背景工作。舊站維持唯讀或維護模式，避免尚持有舊 DNS 快取的用戶寫入舊庫。
6. 觀察並保留有條件的回滾方案。可依流量與舊平台到期日保留舊環境至少 48 小時，但它要持續停寫。新站尚未產生新資料時，可評估恢復舊站；新站已接受寫入後，必須先停寫、把新資料同步回預定接手的資料庫並驗證，再切回，不能只改 DNS。沒有可行的反向同步方案時，應保持維護狀態修復新站，避免新舊資料分叉。

Render 範例：改完 DNS，回控制台完成驗證

使用 Render 的人，先照控制台列出的記錄完成 DNS 修改，再按 Verify。若仍顯示 DNS update needed，核對記錄名稱、值與快取；通過後也要確認 Certificate Issued，並實際開啟正式 HTTPS 網址。

切換後除了測試交易是否真正完成，也要逐一檢查關鍵路徑的 HTTP 回應與 301、302 去向；單看 200 不能證明資料已正確寫入。狀態碼判讀的完整對照可以看我們先前的HTTP 狀態碼整理。

若你的服務主要面向亞太使用者，可優先比較目標平台提供的東京、新加坡等區域，讓應用與資料庫位於相近位置，再從實際使用者網路測試往返延遲、登入與 API 回應時間，決定部署位置。

上線驗證與退場收尾的最終檢查點

切換完成後的驗證清單，按「資料、功能、流量、搜尋」四層收斂。資料層先跟停寫完成後的來源基準比對關鍵表筆數、最大 ID、最新紀錄時間與必要的抽樣內容，並核對上傳檔案；功能層用正式網域重走關鍵路徑，做一筆可辨識的測試寫入，確認交易進入新資料庫，將這筆切換後測試與原始對帳基準分開；流量層看新環境的 log 確認請求真的進來了、背景工作只在新環境運作；搜尋層到 Search Console 看索引狀態有無異常，搬遷後的排名波動有前例可循，處理方法整理在網站改版排名下滑的補救筆記；技術面的健檢項目則套用技術 SEO 檢查清單跑一輪，從 sitemap、robots、canonical 到結構化資料一次驗完。

舊環境的退場按部就班拆四件事。服務與專案在驗證全綠、回滾期結束後刪除；Zeabur 帳號裡的 API token 全部撤銷，避免任何殘留憑證在平台關閉後變成無人看管的風險；帳戶餘額的退款與資安事件的損失賠償是兩條不同的申請流程，都透過 Zeabur Support 提出，別混成一封信；依停運信的媒體轉述，資料實際刪除日期仍待公告；備份與遷移應在自己的服務到期前完成，不能把 12 月 31 日全面停止服務後仍可取回資料當成計畫。

整個遷移的終點檢查項：把過程中產生的備份檔集中到一個你擁有的儲存位置，加密後留一份異地副本。這些備份檔裡全是你的使用者資料與機密，放在本機下載資料夾裡裸奔，比留在要關閉的平台上更糟；收尾的同時把它們安置好，這次遷移才算真正結束。

常見問題（FAQ）

共享叢集 12 月 1 日暫停後，我的服務還救得回來嗎？

依 INSIDE 轉述的停運通知信，共享叢集暫停後使用者仍可手動重新啟動服務來備份資料，但不能保證任何個別服務都能成功恢復。這條路要承擔兩個風險：12 月 31 日全面關閉後就沒有這個機會了，且搶救期限內平台狀態不明，隨時可能再出狀況。把它當成來不及搬完時的補救手段，主要搬遷計畫別押在這上面。

我在免費方案上，不用付費能拿到資料庫備份嗎？

可以。Free 方案沒有圖形介面的備份匯出功能，但只要取得可從本機連線、且具備足夠讀取權限的資料庫連線資訊，就可用標準用戶端自行匯出。PostgreSQL 例如 pg_dump --dbname="$SOURCE_DATABASE_URL" --format=custom --file=zeabur-app.dump，每個資料庫各執行一次，再用 pg_restore 還原；它與平台 pg_dumpall 產生的文字 .sql 不同，不能交給 psql。MySQL 用 mysqldump，MongoDB 用 mongodump，還原工具也要依實際輸出格式選擇。想用介面一鍵備份的人，可評估升級一個月 5 美元的 Dev 方案。

匯出的專案 YAML 可以直接丟到 Railway 或 Fly.io 執行嗎？

不行，格式是 Zeabur 專屬的。這份 YAML 的價值在於它是完整的設定清單：每個服務的映像檔或儲存庫、環境變數名稱、Volume 掛載全在一個檔案裡，翻譯成新平台的等價設定時照著逐段搬，遺漏的機率比自己憑記憶重建低很多。官方的匯回指令 npx zeabur@latest template deploy 只對 Zeabur 帳號之間的搬遷有效。

Redis 裡的資料有必要跟著搬嗎？

先分清楚內容性質再決定。確認可重建的 session、API 回應快取、Rate limit 計數可在新環境重建，session 重建通常會讓使用者重新登入；若 Redis 存有未消化任務或唯一一份資料，就必須保留。整份 RDB 要依目標平台支援的匯入流程還原，不能把整份 RDB 直接交給單 key 的 RESTORE。逐 key 搬移才使用 DUMP、PTTL 與 RESTORE，並保留到期語意；RESTORE 的 TTL 單位是毫秒，0 代表永不過期。

網域當初跟 Zeabur 買的，現在怎麼處理？

依 INSIDE 轉述的停運通知信，向 Zeabur 購買的網域已開放自助轉出。先確認註冊資料、到期日與 DNS 管理權限，再取得移轉授權碼，依新註冊商流程辦理。授權碼用於換註冊商，不是改 nameservers 或網站 A、AAAA、CNAME 記錄；如果現有 DNS 可繼續使用，網站主機切換不必等註冊商移轉完成。若也要搬 DNS 代管，先完整複製記錄並處理 DNSSEC／DS，再更換 nameservers、驗證解析。註冊商移轉可能受驗證或鎖定狀態影響，建議提早安排，不要留到切換當天。

帳戶餘額可以退嗎？跟資安事件賠償是同一件事嗎？

可以退，且兩者是分開的申請流程，都透過 Zeabur Support 受理。餘額退款按帳戶剩餘額度處理；資安事件的損失賠償是另一軌，需要提供個案事證。INSIDE 報導引述台北市消保官說明，Zeabur 登記於美國、未在台灣設立分公司，相關案件屬跨境消費爭議；若向平台申訴仍未獲妥適處理，可循跨境消費爭議管道求助，或向發卡銀行洽詢信用卡爭議款申請。

環境變數全部要換新，工作量大，有沒有判斷標準？

用三欄分類法收斂工作量。第一欄純設定值（語系、Feature flag、LOG 等級）直接搬；第二欄任何形式的憑證（資料庫密碼、第三方 API 金鑰、簽章密鑰）全數重新產生，因為官方確認部分專案的環境變數名稱和值遭讀取，並建議所有曾存放於 Zeabur、目前仍有效的憑證都預防性輪替；第三欄平台注入變數對照新平台重寫。

遷移後搜尋排名會掉嗎？

操作得當，風險可控。DNS 切換期間的停機與舊網址消失都可能影響搜尋流量：切換前降低 TTL、新環境預演通過後再切，切換後舊站保持停寫並保留一段觀察期；網址不變時保留原路徑，有更動的舊路徑才 301 到對應新位置。新站已產生資料時，回滾前要先完成資料同步與驗證。切換後一至兩週每天看 Search Console 的索引與點擊變化，有異常先檢查狀態碼與 canonical，再考慮提交 sitemap 加速重新收錄。

12 月 31 日之後，我的資料會被怎麼處理？

依 INSIDE 轉述的停運通知信，資料刪除的具體日期、最晚匯出期限與客服停止服務日期仍待公告，平台將在 12 月 31 日前全面停止服務。備份、驗證、轉移應排在自己的服務到期前完成，不要把全面停止服務後仍能搶救資料當成前提。