# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Railway (@Railway) · 平台：X (Twitter) · 日期：2026-05-28

> 原始來源：https://x.com/Railway/status/2059771207784833241

## 中文摘要

# Railway 的現狀與未來展望（2026 年夏季）

## 簡短摘要 (TL;DR)

接下來內容較多，先為你整理重點：

這一年來，Railway 在現有架構下取得了實質的產品突破，並迎來了超過百萬名新開發者，但也經歷了影響客戶信任的可靠性挫折。

我們正全力投入，目標是贏回這份信任，並打磨我們一直以來所描述的平台。許多工作已經展開，未來還會有更多進展。

在本季剩餘時間及下一季，我們將專注於兩個關鍵領域：信任與核心產品循環。

關於第一部分：

- 我們將推出第二代 Metal，這是我們的第二代硬體平台，整合了我們兩年來運作自有站點的經驗。
- 新增 4 個資料中心容量站點。
- 改進備份體驗。
- 擴充 Postgres 產品功能，使其更具備「開箱即用」的特性。
- 透過我們原生的 CDN 與網路基礎設施，強化邊緣網路以抵禦 DDoS 攻擊。
- 我們正著手進行 ISO27001 認證，以服務對合規性有更高要求的客戶。

我們也將持續建構核心產品：

- 讓 Agentic Railway 的體驗更加優雅（沙盒 primitive、遠端 MCP server、能建立模板的 Agent）——敬請期待。
- 透過真正的 CDN 改進前端體驗。
- Railway 自動修復部署 (Self-healing deploys)。
- 模板 (Templates) 的復興，提供更好的發現機制並支援創作者。
- 透過 SDK 改進 API 體驗。
- 更優雅的 IaC 體驗。
- 透過功能旗標 (Feature flagging) 實現更安全的發布。
- 行動應用程式正式發布 (GA)（我們沒忘記 Android 手機使用者）。
- 重塑 O11y（可觀測性）體驗。
- 擴充 AI Guardrails 以防止更具破壞性的操作。

其他亮點，由支援與解決方案團隊努力推進：

- Railway 儀表板中的支援 Agent 將於第二季進入 Beta 階段。我們也一直在重塑回應式 AI。
- 將所有產品回饋直接對接給負責該功能的工程師。我們稱之為「優先登機 2 (Priority Boarding 2)」。
- 我們正在重新設計 Demo 流程，讓企業的購買體驗變得更好、更順暢。你可以從通話到簽約在 30 分鐘內完成。
- 你將看到我們在 AEO（AI 引擎優化）方面對模型可發現性的重大投資（不客氣/抱歉了）。
- 2026 年第二季是可靠性基礎建設期，2026 年第三季是產品循環的成熟期，2026 年第四季至 2027 年則是生產級 Agent 原生雲端成為預設標準的時刻。
- 我們將研究並改進圍繞 Agent 流程的定價與包裝方案。

如果這個摘要引起了你的興趣，請繼續閱讀下方關於這些主題的更多資訊。

---

## 啟動六年後

首先，重新自我介紹一下，我是 Angelo，Railway 的解決方案工程師。在加入 Railway 之前，我曾在 Citrix 工作，協助為 Verizon 和 Lockheed 等公司運作關鍵任務的雲端環境。委婉地說，我花了多年時間深入參與他人的基礎設施決策，在那些會議中，我的工作是誠實地說明平台哪些地方做得好、哪些地方不行。早期的許多文件、客戶對話和支援工作都是由我推動的。五年過去了，我們擁有了一個很棒的團隊，以及更多你可能已經交流過的夥伴。（你之後會見到更多他們的身影。）

即將邁入在 Railway 的第五個年頭，我接聽了數百通與生產環境中使用我們的團隊的電話，參與了數千則討論串，並參與了許多內部的產品決策。我們一直以來都在分享我們的路線圖，但現在的 Railway 產品比以往任何時候都龐大，隨著我們成長以服務下一個 1 億名開發者，我們希望能更清楚地讓你了解我們對產品未來的規劃。

儘管有 AI，但開發者的需求現在比以往任何時候都更迫切。

我們對目前運作良好的部分感到興奮：從 git push 到上線 URL 的速度，以及平台處理那些沒人想去思考的部署細節的方式。雖然許多人還在爭論開發的未來，但我們內部一直在「吃自己的狗食 (dogfooding)」一種全新的體驗，迫不及待想向你展示。

然後是另一部分。

那部分是有人告訴我——有時小心翼翼，有時則不然——他們看到了當機事件，不確定是否還能信任我們，或者有人說他們喜歡這個平台，但需要 Railway 目前還沒有或解決得不夠好的功能。

這篇文章就是為了回應上述這些聲音。它的長度比我預期的要長。

我們計劃的其餘工作規模很大，與其發送一封寫著「令人興奮的變革即將到來」的行銷 email，我更願意帶你走過這些內容。如果你想要簡短版本，請捲回上面的 TL;DR。如果你想要全貌，請跟著我走。

## 過去

當我們創立 Railway 時，賭注很簡單：開發者應該推送程式碼，然後讓它運作。

這份契約可以追溯到 2007 年的 Heroku（推送程式碼，平台處理執行環境，資料庫是旁邊託管的 primitive，buildpack 處理其餘部分），這至今仍定義了我們是誰。我們增加的一切都是對此的延伸。

我深信 Railway 是唯一一個正在建構以 Agent 為中心的開發者人體工學，以滿足真實企業需求的平台。顯然，模型也喜歡這一點。

我傾向於強調 2014 年到 2020 年之間那「失去的十年」，那段時間讓開發者遠離了 git push，轉而投入 Helm charts、IAM 綁定，以及分散在三個雲端帳號中的託管服務。

我們想把你帶回來，擴展這份工作契約的定義：包含真實資料庫的全端應用程式、預設多區域部署，以及越來越多在迴圈中的 Agent。

由此產生的核心賭注：

- 最快的循環勝出。Postgres、MySQL、Redis、Mongo，全部在同一個專案中、同一個私有網路中、同一張帳單上。不計代價地減少上下文切換。
- 推送程式碼，取得 URL。Git 是部署契約。CI/CD 是平台的工作，而不是你的。
- 為你使用的部分付費。基於用量的定價，當流量停止時，計費也隨之停止。
- 多區域部署是基本門檻。選擇 us-east-1 就像判死刑的日子已經過去了。為每個服務選擇一個區域；平台會處理路由。
- Agent 是一等公民。MCP server 不是外掛的整合。Stripe APP 不只是行銷，Agent 需要更好的 primitives。
- 可靠性是一種態度，而不是一種功能。我們會在本文中多次討論這一點。

## 哪些做得好

流經 Railway 的專案數量（每月超過 5,000 萬次建構，每天超過 12,000 名新使用者，同時為數千億次生產環境請求提供動力）所帶來的激勵感難以言喻。

我們所建立的產品獲得的喜愛意義重大。當客戶聯繫我們不是因為需要什麼，而是想告訴我們我們做對了什麼時，感覺真的很棒。對於這一切以及更多，我們心存感激。你們是我們做這件事的原因。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779947112965-iaHJXF1hfW8AAsFmXjpg.jpg)

在上圖中，你可以看到平台上部署量的成長。人們正以驚人的速度發布產品。（順便一提，你可以在 https://www.railway.com/stats 即時查看。）

在過去的三個月裡，我們也一直在鍛鍊肌肉，以提供一個與你實際工作節奏相匹配、反應更靈敏的平台。

- 在 GCP 當機事件後，我們完成了向全分散式網路路由器的切換，這意味著如果單一雲端供應商當機，我們可以透過 Metal/AWS/GCP 之間的備份連結來路由流量。
- 我們發布了一個與雲端無關 (cloud-agnostic) 的新建構器，這也讓我們的內部建構速度顯著提升。
- 我們在 CLI 和資料庫 UI 中發布了真正的 SSH，淘汰了舊的 SSH 代理，並解鎖了一類以前無法實現的 Agent 驅動除錯功能。
- 我們於 2026 年 3 月在 Patroni 上發布了一鍵式高可用 (HA) Postgres。區域內副本、自動故障轉移，終於勾選了「無需工單即可故障轉移的託管資料庫」這個選項。
- 我們在 Stripe 的 APP 協議上發布了 Stripe APP，用於 Agentic 配置。AI Agent 現在可以在一個連續的循環中為你註冊、付款並建立一個運作中的 Railway 堆疊。
- 我們發布了顯著改進的模板搜尋功能。這裡還有更多工作要做（稍後詳述）。

隨著每一次發布，我們都在改進並實戰驗證這個即時平台，並在看到機會的地方進行升級。然而，過去的一年並非沒有波折和挑戰，讓我們來討論一下。

## 我們學到了什麼

從哪裡開始呢？

我們可以將面臨的挑戰歸咎於「網路正在燃燒」，但這並不符合我們公司（以及個人）的價值觀。

一個數千家公司信任其生產工作負載的服務，背後有數百個運作中的組件。除此之外，產品在某些方面還需要滿足你的期望。以下是我們觀察到的關於平台和社群的三個主題。

1. 我們經歷了可靠性挫折，這讓我們付出了客戶信任的代價

想像一下最糟糕的週日下午。

你對一個小修復進行了 main 分支推送，健康檢查沒有通過，然後你看到了那個你最不想看到的橫幅。每次事故在我們的公開狀態頁面上都有事後檢討 (postmortem)。去讀讀看。它們很誠實。但顯然，這些事故本不該發生。

我們現在是這樣思考的。

當部署因為我們上游的問題而失敗時，你無法分辨是「供應商今天狀況不好」還是「Railway 今天狀況不好」。從你的角度來看，這一切都是 Railway。我們是你信任用來讓應用程式運作的平台。如果我們底下的層級崩潰了，那是我們必須吸收的問題，而不是你需要去除錯的問題。即使根本原因不在我們，責任也在我們，過去六個月我們比過去幾年任何時候都更堅定地以這種方式運作。

最近，我們針對能識別到的每一個單點故障進行了壓力測試，從註冊層到網路控制平面，再到我們依賴的第三方整合。未來還會有更多的桌面演練。因此，我們將每一個依賴項都視為隨時可能出問題，我們寧願在問題發生前就知道它看起來是什麼樣子，而不是在發生時才手忙腳亂。

溝通方面是一項平行的投資。

如果你有在關注，你可能已經注意到狀態頁面的更新速度變快了（團隊推出了一個全新的狀態頁面），事後檢討發布得更早，客戶影響摘要也用淺顯易懂的語言說明了發生了什麼事。你們中的一些人注意到了。

你們中的一些人在討論串中告訴我，我們的溝通明顯變好了。這正是我們一直期待的回饋，這也告訴我們這項投資正在發揮應有的作用。

信任既是領先指標，也是滯後指標。我們必須把它贏回來。

2. 前端體驗尚未完整。

如果你是從 Heroku 來到 Railway，你是為了後端而來的。我們在這方面很強。推送一個 Rails 應用程式、一個 Node API、一個 Python worker，平台都能搞定。但試著推送一個需要在首爾、馬德里和聖保羅快速載入的行銷網站，我們的回答一直禮貌地是：「你有考慮過把前端託管在 Vercel，後端託管在我們這裡嗎？」

這是一個不錯的搭配模式。

但這對那些更希望擁有一個平台、一張帳單的客戶來說是一種稅。

你可以在 Station 的討論串中看到這一點。亞洲和南美洲的客戶在後端請求到達後，雖然速度很快，但 TTFB（首字元時間）卻高達 5 秒。客戶透過將 DNS 記錄從 CNAME 切換到 A 記錄來修復效能，因為邊緣層仍然透過第三方路由，而不是與 Metal 託管在同一地點。

這些是同一個問題的縮影，透過不同的團隊反映出來，這些都是沒人應該做的權宜之計。

我們正在製作一個真正的 CDN。它目前正在測試中。

好消息是，端到端的邊緣測試套件已經上線，我們正在驗證 CDN 行為、WebSockets、SSE 和標頭，涵蓋了測試環境和生產環境。Railway Websites 即將到來，我們正在努力填補這一空白。

……我們正在我們自己的 Railyard 中追蹤這項擴展。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779947113005-iaHJXGFtaWEAIWXfNjpg.jpg)

3. 產品必須要能「唱歌」

在你的終端機中打開 Claude Code。

要求它啟動一個新的 Railway 服務。大多數時候，它能運作。要求它在該服務旁邊設定一個 Postgres 並執行遷移。大多數時候，這也能運作。要求它開啟一個帶有種子資料的預覽環境，針對變更執行整合測試套件，並且只有在套件通過時才通知你。

我們還沒做到那一步。

我們已經發布了 MCP server。我們已經發布了 Stripe APP 協議。我們已經談論 Agentic Railway 超過一年了。從我們今天所處的位置到「Agent 可以端到端完成所有事情」的路徑是真實存在的，但尚未完成。我們還沒有一個基礎的沙盒 primitive，這是 Agent 安全驗證自身工作所需要的。遠端 MCP server 還沒達到應有的水準。願景很明確。執行正在進行中，我們欠你一份透明度。

你也可以在討論串中看到這些未完成的邊緣。

編碼 Agent 因為在太短的時間內進行了太多 CLI 呼叫而自我限流（順便一提，已修復）。另一個例子是，客戶對帳單上的「Agent 使用量」感到困惑，因為我們沒有在 Railway 自身的 AI 功能（AI 診斷、儀表板支援 Agent）與客戶自己執行的 Agent 之間劃清界線。

在學習這些教訓的同時，我們也一直在進行實驗，並注意到關於什麼有幫助的早期訊號：

- 建構不再緩慢，這些工作的模式開始出現在面向客戶的建構時間中。
- Stripe APP 整合讓更多客戶比我們預期的更快地從「對 Agent 好奇」轉變為「執行真實堆疊的 Agent」。
- 第一天就設定支出警報的客戶幾乎從未經歷過「你的 5 美元應用程式花了 40 美元」的情況。那些沒設定的人，有時會遇到。最近的一個討論串中，一個 Datadog Agent 被悄悄留在專案中執行，將每月 40 到 60 美元的帳單變成了 544 美元，直到客戶發現。我們將讓警報變得更顯眼。

感謝你們所有人的回饋、客戶通話和平台資料，我們今年吸收了太多東西。有時這讓我們頭暈目眩。如你所見，我們確實有點暈。

## 我們想去哪裡

當我們著手建立現今的 Railway 時，願望很簡單：開發者應該推送程式碼，然後讓它運作。現在，我們想納入大多數人編寫程式碼的方式，那就是透過 Agent。我們想給人們速度，以及他們需要的驗證，這樣他們就可以在任何需要我們的地方使用 Railway。

我們未來一年的計畫是更堅定地投入這一使命，透過深化我們已經在做的事情，並填補我們上面誠實指出的空白。

為此，我們現在開始走兩條主要路徑，並將在 2026 年第三季落地：

可靠性

這是基礎工作。它不會全部以華麗的發布形式呈現。（但這裡面有很多內容。）

最大的一塊是 Gen2 Metal 的推出。

我們正在轉向我們的第二代硬體平台，包括支援它的網路工作，以及解鎖一直阻礙它的區域設定。這是今年最大的基礎設施投資，它決定了我們後續一切的可靠性態度。我們已經規劃好了一切：更好的 CPU、記憶體、儲存架構。我們迫不及待想談論更多細節。

我們也正在讓新的資料中心容量上線，這也是我們大部分基礎設施投資的去向。

還有一些內部工作，即使你從未直接看到，也很重要。例如改進我們的 SOP，並重組我們處理頁面、升級和從事故到行動的回饋循環的方式。

第二季之後，軌道將繼續延伸。隨著客戶成長，我們將擴大我們的足跡和合規性範圍。請注意，這些方向仍在成形中，隨著我們深入，細節會更加清晰：

- 在更多區域提供更多的資料中心容量，在我們地圖上尚未覆蓋的地方進行建設。
- 認真推動 ISO27001，為那些客戶要求達到該合規水準的團隊服務。
- 一旦第一波在生產環境中驗證成功，Gen2 Metal 將在整個機群中全面推廣。

當出現故障時，我們也將研究更乾淨的部署日誌。在部署進行時，更易讀地顯示平台代表你正在做什麼。這引導我們來到……

產品循環

這是讓 Railway 變得更好的工作。

我最興奮的部分是 Agentic Railway 的故事。

三件相關的事情：

- 一個基礎的沙盒 primitive，讓 Agent 有一個安全的地方在推送到生產環境之前驗證自己的工作。
- 讓 Agent 在儀表板或終端機體驗中更加原生（例如將 Railway 交給你現有的 AI 編碼工具，如 Claude、Codex 或 Cursor）。
- 遠端 MCP server，這樣 Agent 就不必在本地端才能驅動平台（今天已上線），以及 Agent 像人類一樣建立模板的能力（今天也已上線）。

我們也正在發布對「Railway 不是託管前端的好地方」這一說法的回應。真正的 CDN 是其中的一部分。Railway Websites 是其中的一部分。最終狀態是，你可以在 Railway 上發布 Next.js 或 TanStack 應用程式，而不必拆分你的程式碼託管位置。

這裡的目標是，你可以將電腦或 MCP 交給你偏好的 harness，並透過你需要部署的程式碼將你的意志印刻在世界上。這就是我們的願景。

我們也在關注那些長期以來一直被要求的細節：範圍限定的 API token、更優雅的 IaC 體驗、一個旗標 primitive，這樣你就可以將變更發布到一定比例的流量，而無需外掛第三方供應商。

第二季之後，我們正在開發一種產品體驗，你可以在產品內直接請求並建構變更，然後發布出去。這很有野心，但我們正努力實現它。

就在我們說話的同時，Jared 和 Lucas 一直在努力，讓你能夠 fork 一台正在運作的機器，即時編輯它，然後將其合併回去。但我們不僅僅是在看大動作，我們也在全面審視其他許多生活品質的改進。

我們正在考慮的其他事項：

- 圍繞 Agent 流程的定價和包裝，反映團隊在 Agent 執行工作時如何實際使用 Railway，而不是 2018 年定價頁面的舊模式。
- 重塑可觀測性體驗，以便 Agent（和你）可以詢問平台為什麼某個東西很慢，並得到有用的答案。
- 擴充我們的 AI Guardrails，以便平台拒絕 Agent 本不該進行的破壞性操作。
- 模板不再只是靜態食譜，而是 Agent 可以組合成真實堆疊的生產級 primitives。

## 現在與未來

如果這是一部發布影片，我會暫停音樂，再點擊一次 Railway 儀表板，對著鏡頭眨眨眼，在繼續之前望向窗外一分鐘。

今天我們結束了 Railway 這種形式的一年，但我們的目光投向了從現在到 2026 年底以及 2027 年的路程，我們的手正在鋪設這些軌道（聽懂了嗎？）。未來的旅程將看到平台變得更可靠、更有能力、更由 Agent 驅動，這一切都是為了我們最初做出的那個簡單賭注：開發者應該推送程式碼，然後讓它運作。

更直接地看看我們接下來要去哪裡：

2026 年第二季是關於在上面建立任何新東西之前，先把基礎打好。機群、區域、備份、邊緣、值班節奏。這是今年其餘時間所依賴的無聊、不光鮮的基礎設施工作。我們本季不會發布什麼值得上頭條的東西。我們正在為 2026 年其餘時間能夠雄心勃勃創造條件。

2026 年第三季，產品循環將明顯趕上我們一直在講的故事。前端差距將縮小。模板的復興讓社群創作者能像第一方團隊一樣發布產品。平台開始擅長客戶禮貌地指出我們還不擅長的部分，以及我們之前不太禮貌地告訴他們要搭配 Vercel 使用的部分。

2027 年及以後，我們將能夠對當前路線圖無法容納的專案說「好」。我們私下裡一直在思考一些想法（不劇透），還沒準備好公開發布。

隨著一年的展開，我們會寫更多像這樣的文章，包括那些不再是關於贏回信任，而是關於讓你發布你需要發布的工作，同時感覺緊湊、精緻，最重要的是，有趣的部分。

## 結語

對於那些從一開始就與我們在一起，或者 2025 年加入，或者剛剛註冊的你們，謝謝。你們的回饋、在困難時期的耐心、願意在我們搞砸時告訴我們，以及（同樣重要地）願意在我們做對事情時告訴我們，這些都是我們努力發布、誠實發布並在過程中享受樂趣的原因。

我們將繼續圍繞你以及你所建立的社群和企業來建構 Railway，我們致力於在這樣做的同時贏回我們欠你的信任。

對於那些還在猶豫 Railway 是否適合你的平台的人，也謝謝你。我們寧願你讀了這篇文章，等準備好後再來，也不願你感覺被一個沒有實現的故事所推銷。當我們在接下來的兩季發布產品時，請回來看看我們。如果你心動了，我們會非常高興你的加入。

好了。這就是我停止的地方。我寫了很多字。

Happy Shipping,

Angelo + The Railway 團隊

（我們正在查看所有回覆，我們的請求是：如果你發現 Railway 不符合你的使用案例，請告訴我們，我們想為你打造完美的平台。在這裡留言：https://station.railway.com/community/where-railway-is-and-where-it-s-going-7e26f044 或在 X 上回覆這裡）

## 標籤

功能更新, 新產品, 產業趨勢, 硬體, Railway