Railway 是以 application project 為中心的 PaaS。Project 裡放 API、worker、database 等 Services，再以 Environments 隔離 production、staging 與 PR。它減少的不是所有維運，而是 build image、安排 container、service discovery、domain、TLS 與設定接線的工作。
Project 是部署拓撲，不只是資料夾
Service 是 deployment target，來源可以是 GitHub、local directory 或 Docker image。Project 則把多個 Services 與 Environments 包在一起。這很適合一個 repository 同時含 web、API、worker 和 migration job；每個 process 有自己的 build/start command、variables、資源與部署歷史。
Environment 不是單純的 variable group，而是一套隔離的 service instances。Persistent environment 可做 staging；PR environment 可在 pull request 期間建立後銷毀。複製環境不代表複製 production data，preview 仍應使用獨立 credential、匿名資料與清除策略。
私有網路讓 service 接線，但不替代韌性設計
同一 project/environment 的 Services 可用 <service>.railway.internal 溝通；private networking 以 internal DNS 與加密 tunnel 隔離流量。Reference Variables 可引用另一個 Service 的位址或 credential，避免手抄連線字串。
這個網路只在 runtime 可用，build step 不能靠它連 database。啟動時也不要假設 database 一定先 ready；Railway 沒有等價於 Compose depends_on 的 readiness 保證，client 要有 retry、timeout 與 idempotent migration。
Volume 和 healthcheck 會改變部署承諾
Service filesystem 預設是 ephemeral；需要保留檔案才掛 Volume。但單一 writable volume 會把 replica、placement 與 rolling deployment 綁在一起，官方 healthcheck 文件也明示掛 volume 的 service redeploy 可能有短暫 downtime。重要資料要另外備份，水平擴展的 database/object storage 優先使用相應服務。
Healthcheck 在新 deployment 回應 200 後才切流量，但上線後不持續 probe。它是 release readiness gate，不是 production monitoring；仍需 uptime check、metrics、logs 與 alert。restart policy 也不能補救永久性設定錯誤。
Railway 適合想快速部署多 service 產品、又不想先維護 Kubernetes 的小型團隊。純 frontend 可比較 Vercel/Netlify；需要精確 global placement 可看 Fly.io；受嚴格 network/IAM/compliance 控制則比較三大雲。驗收時至少測壞版 rollback、PR cleanup、dependency 暫時失聯、volume restore 與環境變數誤接。
參考資料
Loading...