跳至主要內容
內容目錄
Zeabur 搬到 Railway 是很多台灣開發者和小團隊這個月最急的工作。Zeabur 在 2026 年 10 月宣布收掉平台：12 月 1 日共享叢集上的服務全部暫停，12 月 31 日所有服務停止，而且 10 月中才發生過環境變數外洩的資安事件。Railway 的操作邏輯和 Zeabur 最像（專案、服務、一鍵資料庫、Volume），也有離台灣最近的新加坡機房，是最省事的搬家去處。這篇整理 Zeabur 搬到 Railway 的完整流程：先盤點什麼、資料庫怎麼備份還原、環境變數怎麼改寫、網域和 Webhook 怎麼切換，照著做可以把停機時間壓在一兩個小時內。
一分鐘看懂：為什麼現在就要搬？
- 12/1 共享叢集暫停：跑在共享叢集的服務會全部停下來，只能手動重新啟動來備份資料，不能再當正式環境用。
- 12/1–12/31 專用主機陸續關機：專用主機不再續約，每台在自己的到期日關機，硬碟資料不會保留。
- 12/31 全面停止：所有服務停止，
*.zeabur.app網址失效，Zeabur 幫你做的每日資料庫備份也會一起消失。 - 資料刪除日還沒公布：官方說刪除日期確定後才會公告，所以不要等，越早搬越安全。
除了停機時間表，另一個要搬的理由是資安。依外部資安媒體整理的事件報告，2026 年 10 月 14–15 日攻擊者拿到 Zeabur 內部金鑰，存取了約 321 萬筆環境變數紀錄與約 32 萬筆帳號資料。如果你的服務在 Zeabur 上設過 API 金鑰、資料庫密碼、OAuth 密鑰，都應該當作已經外洩處理——這也是下面 8 步驟裡第 2 步「先換金鑰」的原因。官方時間表以 Zeabur 官方公告 為準。
Zeabur 替代方案怎麼選？為什麼是 Railway
Zeabur 官方的搬家指南列了四種去處：Railway（託管平台）、Coolify（自架面板）、Docker Compose 和 k3s。差別在於「主機要不要自己顧」。如果你當初選 Zeabur，就是不想管伺服器、只想推程式碼就上線，那 Railway 是最接近的選擇：同樣用專案和服務組織、同樣一鍵開 PostgreSQL、MySQL、Redis，同樣能掛 Volume 和綁自己的網域。
| 方案 | 主機誰顧 | 適合誰 | 搬家難度 |
|---|---|---|---|
| Railway | 平台代管 | 從 Zeabur 來、不想管主機的個人與小團隊 | 低 |
| Coolify | 自己（裝在 VPS） | 想省錢又要有圖形介面、願意顧主機 | 中 |
| Docker Compose | 自己 | 會 Linux、服務數量少、想完全掌控 | 中高 |
| k3s | 自己 | 多台主機、很多服務、有維運人力 | 高 |
Railway 的費用是「月費＋用量」：月費本身會折抵用量，用得少就只付月費。依 Railway 官方方案說明（2026 年 10 月查詢），方案大致如下，實際金額以官網當下公告為準：
| 方案 | 月費 | 含用量 | 單一服務上限 | Volume 上限 |
|---|---|---|---|---|
| Free | $0 | 每月 $1 額度 | 0.5 GB RAM／1 vCPU | 0.5 GB |
| Hobby | $5 | $5 | 48 GB RAM／48 vCPU | 5 GB |
| Pro | $20 | $20 | 1 TB RAM／1,000 vCPU | 1 TB |
用量的計價單位是 RAM 每 GB 每月 $10、CPU 每 vCPU 每月 $20、對外流量每 GB $0.05、Volume 每 GB 每月 $0.15。資料庫超過 5 GB、或是正式營運的服務，建議直接選 Pro，Hobby 的 Volume 上限很容易撞到。
剩不到兩個月，Zeabur 搬到 Railway 時程怎麼排？
真正的期限不是 12 月 31 日，而是 12 月 1 日：共享叢集一暫停，服務就停了，之後只能手動重啟來備份，不能再拿來跑正式業務。再扣掉測試和觀察期，建議用下面的節奏倒推。服務只有一兩個的話可以壓縮成兩週，服務多、有串金流或 LINE 的，最好照四週走。
| 時間 | 要完成的事 | 完成的標準 |
|---|---|---|
| 第 1 週 | 盤點所有服務、整理外部串接清單、在第三方平台產生新金鑰 | 每個服務都有一份「版本、變數、Volume、網域、誰呼叫它」的紀錄 |
| 第 2 週 | 建立 Railway 專案、搬環境變數、用舊備份做第一次還原彩排 | 測試網址打得開，資料筆數和備份一致，知道還原要花多久 |
| 第 3 週 | 完整功能測試：登入、表單、排程、Webhook、寄信 | 所有功能在測試網址跑過一輪，問題都修掉 |
| 第 4 週 | 選低流量時段正式切換，改 DNS 與外部網址，撤銷舊金鑰 | 正式網域指向 Railway，外部串接實際跑過一筆 |
| 11 月底前 | 觀察、修小問題，確認不需要回滾 | Zeabur 上只剩備份用的資料，可以安心等它停止 |
排時程時記得把「別人要配合的事」算進去：例如要請合作廠商改 Webhook、要等網域轉移、要找有權限的人改 Google Cloud 的 OAuth 設定，這些往往比技術本身更花時間。
Zeabur 和 Railway 的設定怎麼對照？
兩個平台的概念幾乎一對一，真正要動手改的只有三件事：變數的參照寫法、對外網址、機房。先把下面這張對照表看熟，等一下搬環境變數時就不會漏。
| 項目 | Zeabur 寫法 | Railway 寫法 |
|---|---|---|
| 參照資料庫主機 | ${POSTGRES_HOST} | ${{Postgres.PGHOST}} |
| 完整連線字串 | ${POSTGRES_CONNECTION_STRING} | ${{Postgres.DATABASE_URL}} |
| 服務對外網址 | ${ZEABUR_WEB_URL} | https://${{RAILWAY_PUBLIC_DOMAIN}} |
| 服務內部網址 | 服務名稱＋內部網域 | ${{服務名.RAILWAY_PRIVATE_DOMAIN}} |
| 共用變數 | 專案層級變數 | Shared Variables：${{shared.KEY}} |
| 機密值 | 一般環境變數 | 可「Seal」封存，之後介面和 API 都看不到值 |
| 離台灣最近的機房 | 台北、東京等 | Southeast Asia（新加坡） |
Railway 變數的完整語法可以看 Railway 官方變數文件。要注意：Seal 之後的變數不能再解封，也不會出現在 railway variables 和 railway run 裡，請先確定值是對的再封存。
Zeabur 搬到 Railway 8 步驟
前 7 步都是在旁邊把新環境蓋好、測好，Zeabur 上的服務照常運作；只有第 8 步需要短暫停機。建議先挑一個不重要的服務完整走一遍，再搬正式系統。
步驟 1：盤點 Zeabur 上的每一個服務
打開 Zeabur 每個專案，逐一記下下面這些資訊。這份清單就是 Zeabur 搬到 Railway 的施工圖，漏一項就可能在切換當天出事：
- 映像檔與版本：是從 GitHub 部署，還是 Docker 映像（例如
postgres:17、某個固定版本的應用程式）。搬家時先用完全相同的版本，穩定後再升級。 - 環境變數：每個服務的變數頁全部抄下來，包含參照其他服務的寫法。
- Volume 掛載路徑與大小：哪個服務掛了 Volume、掛在哪個路徑、目前用了多少空間。
- 網域：用的是
*.zeabur.app還是自己的網域；網域如果是在 Zeabur 買的，要從後台轉出。 - 誰在呼叫你的網址：金流、電商平台、LINE、Google OAuth、Apps Script、前端程式……所有寫死你服務網址的地方，切換時都要改。
- 排程與時區：有排程的服務記下
TZ設定，搬過去時間才不會跑掉。
步驟 2：先換掉所有金鑰與密碼
因為 10 月的資安事件，Zeabur 上的環境變數都要當成已曝光。建議的順序是：在第三方服務（金流、雲端、API 平台）產生新的金鑰，新金鑰只設定在 Railway，切換完成後再撤銷舊金鑰。這樣舊環境在切換前仍能運作，切換後外洩的舊值也失效。
例外是「用來加密資料本身」的金鑰，例如應用程式的加密金鑰、n8n 的 N8N_ENCRYPTION_KEY：這類值一換，資料庫裡已加密的資料就解不開。做法是先用原值搬過去，確認系統正常後，再依該軟體的官方流程重新加密或重新設定授權。
步驟 3：備份 Zeabur 的資料庫與檔案
Zeabur 的每日備份在停機後會消失，一定要自己匯出一份。資料庫打開「公開連線」（或在 Zeabur 服務的連線資訊取得連線字串）後，在自己電腦上執行：
# PostgreSQL（建議 custom 格式，還原最彈性）
pg_dump -Fc --no-owner --no-acl "$ZEABUR_DB_URL" -f backup.dump
# MySQL
mysqldump --single-transaction --routines --triggers \
-h 主機 -P 連接埠 -u 使用者 -p 資料庫名 > backup.sql
# MongoDB
mongodump --uri "$ZEABUR_MONGO_URL" --archive=backup.archive幾個實際搬過才知道的細節：
- 工具版本要大於等於資料庫版本：Zeabur 跑 PostgreSQL 17，本機的
pg_dump至少要 17，否則會直接報錯。 - 資料量大的表可以先不搬：像執行紀錄、log 這種可以重來的資料，用
--exclude-table-data=表名排除，備份檔可能從幾十 GB 縮到幾百 MB，還原快很多。 - Volume 裡的檔案也要帶走：上傳的圖片、SQLite 檔、設定檔，用服務的終端機打包成 tar 下載；Redis 如果只是快取可以不搬。
- 12/1 之後才想到要備份：共享叢集的服務會被暫停，需要手動重新啟動才能匯出，所以別拖到那時候。
步驟 4：在 Railway 建立專案並選新加坡機房
登入 Railway 後新增專案，依步驟 1 的清單把服務一個一個加進來：資料庫用 Railway 的 PostgreSQL／MySQL／Redis 範本，應用程式選 GitHub repo 或 Docker 映像。每個服務都到 Settings → Region 改成 Southeast Asia（Singapore），台灣連線延遲最低；同一個專案的服務放同一個機房，內部連線才快。習慣用指令的話，Railway CLI 也能做大部分操作：
npm i -g @railway/cli
railway login --browserless # 顯示配對碼，到瀏覽器確認
railway link # 選擇剛建立的專案
railway variables # 查看目前服務的變數提醒：Railway 的 PostgreSQL 範本版本可能比 Zeabur 新（例如 Zeabur 是 17、Railway 是 18）。從舊版還原到新版沒問題，反過來不行；如果要求版本完全一致，就改用指定版本的 Docker 映像自己建資料庫。
步驟 5：把環境變數搬到 Railway
在 Railway 服務的 Variables 頁按「Raw Editor」，可以把整份 .env 內容一次貼上。貼上後再對照前面的設定對照表，把 Zeabur 的參照寫法改成 Railway 的：
# Zeabur
DB_HOST=${POSTGRES_HOST}
APP_URL=${ZEABUR_WEB_URL}
# Railway
DB_HOST=${{Postgres.PGHOST}}
APP_URL=https://${{RAILWAY_PUBLIC_DOMAIN}}
TZ=Asia/Taipei步驟 2 換好的新金鑰也在這一步填進去。資料庫連線請盡量用 Railway 的內部網址（*.railway.internal），不走公開網路、也不算對外流量。
步驟 6：還原資料庫並核對筆數
Railway 的資料庫服務可以開啟公開 TCP 連線，從自己電腦還原：
pg_restore --no-owner --no-acl -d "$RAILWAY_DB_URL" backup.dump
# 兩邊各跑一次，數字要一樣
psql "$ZEABUR_DB_URL" -c "SELECT count(*) FROM 重要的表;"
psql "$RAILWAY_DB_URL" -c "SELECT count(*) FROM 重要的表;"不要只看「還原成功」，挑幾張重要的表逐一比對筆數：使用者、訂單、設定、授權資料。第一次建議用前幾天的備份做彩排，記下還原要花多久，切換當天才估得出停機時間。還原完成後，公開 TCP 連線如果用不到就關掉。
步驟 7：掛 Volume、部署，先用 railway.app 網址測試
需要存檔案的服務，在專案畫布上新增 Volume、連到該服務，掛載路徑照 Zeabur 原本的路徑。如果程式寫的是相對路徑 ./data，Railway 上要掛在 /app/data。官方映像用非 root 使用者執行時，Volume 可能沒有寫入權限，加上變數 RAILWAY_RUN_UID=0 即可。
接著到 Settings → Networking 按 Generate Domain，產生一個 *.up.railway.app 測試網址。這時先不要動正式網域，用測試網址把登入、主要功能、排程、對外 API 都跑一遍。有排程或會主動寄信、扣款的系統，測試期間先把排程關掉，避免新舊兩邊同時執行、重複寄信或重複處理訂單。
步驟 8：正式切換網域與外部 Webhook
選一個流量最低的時段，照這個順序做：
- 停掉 Zeabur 的應用服務（資料庫先留著），從這一刻起資料不會再變動。
- 最後同步一次資料：重新匯出 Zeabur 資料庫、還原到 Railway，再核對一次筆數。
- 綁自己的網域：Railway 服務 Settings → Networking → Custom Domain，依畫面到 DNS 加上 CNAME 與 TXT 兩筆紀錄（兩筆都要），SSL 憑證會自動簽發。
- 改外部網址：金流與電商平台的 Webhook URL、LINE Messaging API Webhook、Google／Meta 的 OAuth 重新導向 URI、Apps Script 和前端寫死的 API 網址。
- 打開排程、實際跑一筆：確認新環境收得到 Webhook、寄得出信、寫得進資料庫。
原本用 *.zeabur.app 網址的服務，這次一定要改用自己的網域。以後不管再搬到哪裡，只要改一筆 DNS，所有外部串接都不用再動。
不同類型的服務怎麼搬？
上面的 8 步驟是通用流程，實際做的時候，依服務類型會有不同的重點。把你在 Zeabur 上的服務對照下面幾類，就知道要特別注意哪裡。
從 GitHub 部署的 Node.js、Python、Go 應用
這類最好搬：在 Railway 新增服務時選同一個 GitHub repo 和分支，Railway 會自動偵測 Dockerfile，沒有 Dockerfile 就用內建的建置器判斷語言並安裝套件。要確認三件事：啟動指令和 Zeabur 上一樣（到 Settings → Deploy 設定 Start Command）；程式監聽 Railway 提供的 PORT 變數，而且綁在 0.0.0.0 而不是 localhost；Node.js、Python 的版本用設定檔（例如 package.json 的 engines、.python-version）固定，避免建置環境換了版本導致行為不同。
用 Docker 映像部署的開源工具
n8n、Metabase、Uptime Kuma、Umami 這類用 Docker 映像部署的工具，Railway 選「Docker Image」填同一個映像名稱與完全相同的版本標籤即可，不要用 latest，否則搬家同時升級，出問題時很難判斷是搬家還是升級造成的。這類工具通常都有資料庫和 Volume，兩個都要搬，掛載路徑照該映像官方文件設定。
資料庫：PostgreSQL、MySQL、MongoDB、Redis
| 資料庫 | 匯出工具 | Railway 端 | 特別注意 |
|---|---|---|---|
| PostgreSQL | pg_dump -Fc | PostgreSQL 範本 | 工具版本 ≥ 來源版本；擴充套件（例如 pgvector）要先在新資料庫建立 |
| MySQL／MariaDB | mysqldump --single-transaction | MySQL 範本 | 字元集用 utf8mb4，匯入前確認 sql_mode 一致 |
| MongoDB | mongodump --archive | MongoDB 範本 | 用 mongorestore --archive 還原，索引會一起重建 |
| Redis | 多半不用搬 | Redis 範本 | 只當快取就直接開新的；有存佇列或工作階段，切換前先讓佇列清空 |
架在 Zeabur 上的 WordPress
Zeabur 也有一鍵 WordPress 範本，這類網站要搬的是 MySQL 資料庫加上 wp-content（佈景主題、外掛、上傳的圖片）。技術上可以照同樣流程搬到 Railway，但 WordPress 需要長期更新、備份、資安監控，放在通用的容器平台上其實不好維護。如果網站是公司官網或電商，建議這次直接搬到專門跑 WordPress 的主機，網址、SEO 設定和圖片路徑都會原封不動保留，可以參考我們的 WordPress 主機代管。
靜態網站與前端專案
純前端（React、Vue、Astro 打包出來的靜態檔）在 Railway 一樣可以部署，但這類網站不需要一直開著的伺服器，也可以考慮放到專門的靜態網站託管服務。不管放哪裡，重點都一樣：前端程式裡寫死的 API 網址要改成新網域，重新打包後再部署。
自架 n8n 從 Zeabur 搬到 Railway 要注意的 6 件事
很多人在 Zeabur 上用一鍵範本架了 n8n 自動化，n8n 也是 Zeabur 搬到 Railway 最常見、最容易出錯的服務：它同時有資料庫、加密授權、Webhook 和排程，任何一項沒處理好，搬過去就會出問題。這 6 個重點請逐一確認：
| 重點 | 要做什麼 | 沒做會怎樣 |
|---|---|---|
| 加密金鑰一致 | N8N_ENCRYPTION_KEY 填和 Zeabur 完全相同的值 | 所有授權（Gmail、Google 試算表、API）解不開，要全部重新登入 |
| 先停用工作流程 | 還原後、啟動 n8n 前，先把工作流程設成停用，切換當天再開 | 新舊兩邊同時跑排程，重複寄信、重複處理訂單 |
| 網址變數 | N8N_HOST、WEBHOOK_URL、N8N_EDITOR_BASE_URL 改成新網域 | Webhook 節點顯示的網址錯誤，OAuth 回呼失敗 |
| Volume 路徑 | Zeabur 範本掛 /root/.n8n，官方映像預設是 /home/node/.n8n | 重開機後設定檔不見，或寫入權限不足 |
| 時區 | GENERIC_TIMEZONE 和 TZ 都設 Asia/Taipei | 排程時間差 8 小時 |
| 執行紀錄 | 執行紀錄的資料表只搬結構、不搬資料 | 備份檔大好幾十倍，還原時間拉長 |
另外別忘了 n8n 的 OAuth 授權：Google Cloud Console 裡的 OAuth 用戶端要加上新網址的回呼 URI（/rest/oauth2-credential/callback），舊的先留著，確認不再需要再刪。
搬完出錯怎麼辦？Zeabur 搬到 Railway 常見錯誤與解法
就算照步驟做，第一次部署也很常遇到錯誤。下面是 Zeabur 搬到 Railway 時最常見的狀況，先看 Railway 服務的 Deploy Logs，再對照這張表找原因：
| 症狀 | 常見原因 | 解法 |
|---|---|---|
| 網址打開顯示「Application failed to respond」 | 程式沒監聽 PORT，或綁在 localhost | 改成監聽 process.env.PORT（或對應語言的寫法）並綁 0.0.0.0 |
| 連不到資料庫 | 參照變數的服務名稱打錯（大小寫有差），或還在用 Zeabur 的連線字串 | 到 Variables 確認展開後的值，資料庫主機應該是 *.railway.internal |
| 部署成功但資料是空的 | 程式先啟動、自己建了一個空資料庫，或連到別的資料庫 | 先停服務、清空新資料庫重新還原，確認連線變數指到對的資料庫 |
| 上傳的檔案重新部署後就不見 | 沒有掛 Volume，或掛載路徑和程式寫入路徑不同 | 新增 Volume，路徑對準程式實際寫檔的資料夾 |
| Volume 寫入權限不足 | 映像用非 root 使用者執行 | 加上變數 RAILWAY_RUN_UID=0 |
| 排程時間差了 8 小時 | 容器預設 UTC 時區 | 設定 TZ=Asia/Taipei，應用程式自己的時區設定也一起改 |
| Google 登入出現 redirect_uri_mismatch | OAuth 用戶端沒有新網址的回呼 URI | 到 Google Cloud Console 加上新網域的回呼網址 |
| 外部 Webhook 一直沒進來 | 第三方平台還指向舊網址，或新網域 DNS 尚未生效 | 逐一檢查 Webhook 設定，用 nslookup 確認網域已指到 Railway |
如果錯誤只在正式網域出現、用 *.up.railway.app 測試網址正常，問題幾乎都在 DNS 或 CDN 設定；用 Cloudflare 代理的網域，SSL 模式請設為「完全（Full）」，避免重新導向迴圈。
Zeabur 搬到 Railway 切換當天檢查清單
- Railway 所有服務都在新加坡機房、狀態 Online
- 資料庫最後一次同步完成，重要資料表筆數與 Zeabur 一致
- 新金鑰已填入 Railway，加密用金鑰維持原值
- 自己的網域 CNAME＋TXT 已生效，HTTPS 打得開
- 金流、LINE、OAuth、Apps Script 等外部網址都已改成新網域
- 排程已打開，實際跑過一筆完整流程（收 Webhook、寫資料、寄信）
- Zeabur 應用服務已停止，避免新舊兩邊同時運作
- 第三方平台的舊金鑰已撤銷
搬完之後：備份、回滾與費用
搬完不代表結束，三件事要接著做：
- 設定自動備份：Railway 的 Volume 支援排程備份，每日備份保留 6 天、每週保留 27 天、每月保留 89 天，可以同時勾選多種；也能隨時手動備份。細節見 Railway 官方備份文件。資料庫最好再定期用
pg_dump匯出一份存到外部空間，不要把所有備份放在同一個平台。 - 保留回滾路線：Zeabur 上的資料庫和最後一份備份檔先留著，正式環境穩定跑一到兩週、確認沒有漏掉的外部串接後再刪。要注意 12/1 之後共享叢集會暫停，回滾窗口實際上只到 11 月底。
- 觀察一個月的用量：到 Railway 的 Usage 頁看實際花費，資料庫閒置時的 RAM、對外流量是主要成本；用量穩定後再決定要不要調整方案或資源上限。
如果你的網站本身是 WordPress、只是把 API 或自動化放在 Zeabur，也可以趁這次一併檢查主機與備份策略，參考我們的 WordPress 網站維護服務 與 WordPress 主機代管。
搬到 Railway 後可以多用的 5 個功能
Zeabur 搬到 Railway 不只是換個地方跑，Railway 有幾個功能很適合趁搬家一起設定好，之後維護會輕鬆很多：
- 環境（Environments）：同一個專案可以複製出 staging 測試環境，變數和服務架構一樣，改版前先在測試環境驗證，不用再直接改正式機。
- 部署紀錄與回滾：每次部署都會留下紀錄，新版本出問題時可以從 Deployments 退回上一個正常的版本，比自己重新部署快。
- 排程服務（Cron Schedule）：定時執行的小程式可以設成排程服務，只在執行時計費，不用一整天開著等時間到。
- 日誌與用量圖表：每個服務都有 CPU、RAM、網路用量和即時日誌，出錯時直接看 Deploy Logs，比在程式裡到處加紀錄有效率。
- 用量上限與通知：在帳單設定加上用量警示和上限，避免程式出錯無限重啟或被大量請求時，月底收到意外的帳單。
這幾項都是一次設定、長期受用。特別是用量上限，建議在正式切換前就設好，搬家初期最容易因為設定錯誤讓服務反覆重啟。
常見問題
Zeabur 什麼時候停止服務？
Zeabur 公告 2026 年 12 月 1 日起共享叢集上的服務全部暫停、專用主機停止續約並在各自到期日關機，12 月 31 日所有服務停止。資料刪除日期官方尚未公布，建議在 11 月底前搬完。
Zeabur 一定要搬到 Railway 嗎？
不一定。Zeabur 官方列出 Railway、Coolify、Docker Compose、k3s 四種去處。不想自己管主機、希望操作方式和 Zeabur 接近，選 Railway 最省事；想壓低費用又會 Linux，可以考慮在 VPS 上用 Coolify 或 Docker Compose。
Zeabur 搬到 Railway 會停機多久？
前 7 個步驟都能在 Zeabur 照常運作時完成，只有最後切換需要停機，時間主要取決於資料庫大小。不搬執行紀錄這類可重來的資料、事先彩排過的話，多數小型服務可以在一到兩小時內切換完成。
搬家後原本的 zeabur.app 網址還能用嗎？
不能。Zeabur 停止服務後 *.zeabur.app 網址會失效，所以所有外部串接都要改網址。建議這次改用自己的網域，以後再搬家只需要改 DNS。
Zeabur 的環境變數可以直接照抄到 Railway 嗎？
大部分可以用 Raw Editor 一次貼上，但參照其他服務的寫法要改成 Railway 格式，例如 ${POSTGRES_HOST} 改成 ${{Postgres.PGHOST}}。另外因為 Zeabur 10 月發生環境變數外洩，API 金鑰和密碼應換成新的；只有用來加密資料的金鑰要先維持原值。
Railway 有台灣機房嗎？
目前沒有。Railway 公開的機房有美西、美東、歐洲（阿姆斯特丹）與東南亞（新加坡），從台灣連線以新加坡延遲最低，從 Zeabur 搬過去建議每個服務都選 Southeast Asia。
在 Zeabur 買的網域怎麼辦？
Zeabur 已停止販售網域，在 Zeabur 購買的網域可以從後台自行轉出到其他網域註冊商。建議先完成轉移，再把 DNS 指向 Railway，避免平台停止後網域無法管理。
Railway 的費用怎麼算？
Railway 採月費加用量計費，月費會折抵用量。依官方文件，Hobby 方案每月 5 美元、Pro 方案每月 20 美元，超出部分依 RAM、CPU、流量與 Volume 用量計費。正式營運或資料庫較大的服務建議用 Pro，實際價格以 Railway 官網為準。
不想自己搬？交給 GOT YOU DESIGN
我們熟悉雲端服務搬家的資料庫還原、加密金鑰、Webhook 與 OAuth 切換的每個細節。服務盤點、彩排、切換當天陪跑到穩定運作都可以協助，訊息留言 2 小時內回覆。前往 GOT YOU DESIGN 網站
如果你願意，我們陪你一步一步來
先加入 LINE 跟我們聊聊你的狀況，我們會給你適合的建議；也可以直接看看線上課程內容，選擇最適合自己的節奏。
