Gitpod 改名 Ona 之後留下的自架真空：Coder 用 Terraform 把開發環境變成基礎設施，讓 AI Agent 跟工程師共用同一套 workspace

Cloud Development Environment 這個賽道在 2025 年下半年出現了一次結構性的洗牌。Gitpod 在 9 月改名 Ona，把重心從人類開發者的雲端 IDE 全面轉向 AI agent 編排；10 月 15 日 Gitpod Classic 的 pay-as-you-go 方案直接下線，原本靠這條線把 workspace 跑在 Gitpod 雲端的團隊，一夜之間要嘛遷到 Ona 的 agent 導向產品、要嘛自己找去處。取代 Classic 的 Gitpod Flex 名義上支援自架，但只跑在 AWS 上、必須自己維運底層，且被使用者反映穩定性遠不如以往。這個空缺留給了 Coder——目前唯一還在正常迭代、開源版本沒有 seat 限制、可以真正跑在自家 VPS 或 Kubernetes 上的完整 CDE 平台。

Coder 由同名公司開發，AGPLv3 授權，社群版本沒有節點數上限；企業版加上 SSO、RBAC 稽核、多區域佈署等治理功能，但核心的 workspace 生命週期、模板系統、agent 通訊全部在開源版本裡。GitHub 上超過 8000 顆星，跟 DevPod、openvscode-server 一起被列在自架 CDE 的第一梯隊，但架構取向完全不同。

為什麼雲端 IDE 這個市場只剩它還活著

雲端開發環境的商業邏輯一直有兩個難題卡在中間。第一個是資源成本：每個工程師都得配一台隨時 warm-up 的容器或 VM，就算閒置也得付錢，SaaS 業者只能靠時段計費把成本轉嫁，一旦使用者行為稍微改變（例如常常掛在後台跑 test），毛利就崩掉。第二個是安全邊界：真正在乎程式碼外洩的公司不會願意把 source 送去第三方 SaaS，而這批客戶恰好是願意付錢的那批。Gitpod、GitHub Codespaces 都在這兩個難題中間找平衡點，走到 2025 年的結果是 Gitpod 直接放棄純 SaaS 模式，Codespaces 則靠著 GitHub 的訂閱綁定勉強維持。

Coder 從一開始就繞開這兩個難題。它不做 SaaS——所有 workspace 都跑在使用者自己的基礎設施上，Coder 本身只是控制平面。這個定位讓成本結構跟安全邊界的問題直接留給使用者自己處理，也讓 Coder 可以專心把控制平面做深，不必分心經營雲端算力。當 Gitpod 決定退出這個市場，Coder 反而成為預設答案。

Terraform template 是這套系統的核心抽象

Coder 最關鍵的設計決定是把 workspace 定義寫成 Terraform template。每個 workspace 背後就是一份 .tf 檔，裡面用 coder_agent、coder_app 這幾個自訂 provider resource 描述工程師要用的環境——OS 映像、CPU/RAM、要開哪些 port、要跑什麼啟動 script、要接哪個 IDE。當工程師在 UI 按下「建立 workspace」，Coder server 就把這份 template 丟給 Terraform，套用到指定的基礎設施上，可能是一個 Kubernetes pod、一台 Docker container、一台 EC2 VM，甚至是一台 bare metal 主機。

這個抽象層的好處在實務上很明顯。工程平台團隊寫一份 template 就能同時支援不同組別的需求：資料組要跑 Jupyter，用一個 template；後端組要 Docker-in-Docker，用另一個；ML 組需要 GPU，把 template 的 instance type 換成 g5.xlarge 就好。所有 template 存在 Git 裡走 PR review，跟其他 IaC 資產一致。換基礎設施——從 AWS 遷到 Hetzner、從 Kubernetes 換成單機 Docker——只是換掉 Terraform provider，workspace 使用者感受不到差別。

跟這個模型對比，DevPod 走的是「每個開發者本機一份 CLI」的路線，適合個人使用但缺乏集中治理；openvscode-server 只提供 Web IDE 本身，workspace 生命週期跟資源配置得自己想辦法。Coder 的定位剛好卡在「有平台團隊、有多個開發者、有多套基礎設施」的組織空缺。

resource "coder_agent" "main" {
  arch = "amd64"
  os   = "linux"
  startup_script = <<-EOT
    set -e
    curl -fsSL https://code-server.dev/install.sh | sh
    code-server --auth none --port 13337 &
  EOT
}

resource "kubernetes_pod" "main" {
  metadata {
    name      = "coder-${data.coder_workspace.me.owner}-${data.coder_workspace.me.name}"
    namespace = "coder"
  }
  spec {
    container {
      name  = "dev"
      image = "codercom/enterprise-base:ubuntu"
      command = ["sh", "-c", coder_agent.main.init_script]
    }
  }
}

這段是精簡過的最小 template，實際生產環境還會加上 persistent volume claim、coder_metadata 顯示資源狀態、以及不同 IDE 的 coder_app 定義。

Dev Container Builder 補齊了跟 VS Code 生態的相容性

Coder 從 2.20 版之後把 devcontainer.json 支援直接內建，命名叫 Dev Container Builder。工程師如果專案裡已經有 .devcontainer/devcontainer.json——這是 Microsoft 從 Codespaces 時代推出來的標準——Coder 可以直接讀這份設定去建 workspace，不用另外寫 Terraform template。

實務上這個功能解決了一個很現實的問題：多數 open source 專案已經附帶 devcontainer 設定，工程師來新公司也希望「clone 專案就有可以跑的環境」。Coder 用一份 template 去 wrap 這個機制，讓 Docker、Kubernetes、OpenShift 三種底層都能吃同一份 devcontainer 定義。這件事讓 Coder 跟 Codespaces 之間的遷移成本降到極低——原本綁在 GitHub 上的 devcontainer 環境，改跑在自架 Coder 上不必動一行專案設定。

AI Agent 跟工程師共用同一套 workspace 系統

2026 年 CDE 產品討論度最高的功能是 AI agent 的隔離執行環境。當 Cursor、Claude Code、Aider 這類 coding agent 開始能在背景長時間跑任務，「agent 要在哪裡跑」變成一個工程議題。跑在工程師本機會搶資源、跑在 SaaS 上有資料外洩風險、跑在共用開發機會互相干擾。

Coder 的解法是讓 agent 直接用同一套 workspace 模板系統。平台團隊定義好 template，agent 跟人類工程師走同一條 provisioning 路徑，拿到同樣配置的隔離環境——同樣的網段、同樣的 secret 管理、同樣的 audit log。差別只在觸發者是 API 呼叫還是 UI 按鈕。這個設計避免了「為 agent 蓋另一套沙盒」的複雜度，也讓治理策略——例如「所有 agent workspace 不能存取生產環境 KMS」——用同樣一組 RBAC 就能表達。

Gitpod 在 Ona 上做的其實是類似的事，但 Ona 只提供 SaaS，agent 執行環境跑在 Gitpod 雲端。對於在意程式碼邊界的公司，這個差異是決定性的。

部署時要注意的幾個坑

自架 Coder 本身不算難，官方 Helm chart 或單一 binary 都可以跑起來，但生產環境有幾個實務細節值得先想清楚。

Workspace 佈署後端的選擇會決定運維模型。跑在 Kubernetes 上治理最完整，pod eviction、resource quota、network policy 全部沿用叢集現有機制；缺點是叢集本身就要一組人維護。跑在單機 Docker 上運維最簡單，適合 20 人以下的團隊，但沒有跨機器排程能力，機器壞掉就得手動遷移。跑在 VM（EC2、Hetzner Cloud、Vultr）上介於兩者之間，配合 Terraform 的 count 機制可以做出簡易的橫向擴展，但 workspace 啟動時間會比容器慢很多——EC2 從冷開機要 60 秒起跳，容器 5 秒內就能就緒。

Persistent volume 是另一個容易踩到的地方。Coder 預設會把 workspace 資源刪掉以節省成本（stop workspace），如果 template 沒有明確定義 persistent volume claim 或者 EBS volume 是 lifecycle 綁在 workspace resource 上，工程師的未 commit 變更會消失。標準做法是把 /home/coder 掛到獨立的 PVC，並在 terraform 的 lifecycle 區塊加 prevent_destroy = true。

網路連線走 Tailscale 底層的 WireGuard tunnel。工程師從本機透過 coder ssh workspace-name 連進去，或是用 VS Code Remote SSH 直接接。這個機制不需要 workspace 有 public IP，只要 workspace 能出站到 Coder server 就能反向連通，非常適合放在 NAT 後面的 VPS。

這個東西適合誰、不適合誰

Coder 的甜蜜點是 20 人以上、已經有 Kubernetes 或至少多台 VPS 的工程組織，且對「程式碼不能離開自家基礎設施」有明確要求。這個組合下 Coder 幾乎是唯一選項——Codespaces 綁 GitHub 雲、Ona 走 AWS-only、DevPod 沒有集中治理、openvscode-server 只是 IDE 沒有 workspace 概念。

不適合的場景也很清楚。個人開發者用 DevPod 或 direct SSH 就夠，架 Coder 是殺雞用牛刀。10 人以下的小團隊不見得撐得起專門的平台維運，這時直接用 Codespaces 或本機開發反而划算。專案高度依賴 macOS/Windows 特定工具鏈的團隊也不適合，Coder workspace 目前只有 Linux 完整支援。

從 2026 年當下的產業格局看，Gitpod 的退場讓自架 CDE 這件事的選項變少但也變單純——想自己控制程式碼跟基礎設施，答案就是 Coder。剩下的問題是把 template 寫好、把底層基礎設施養好。

想在臺灣機房跑穩定的 Coder workspace，硬體規格會直接影響工程師的體感——編譯專案要 CPU、開多個容器要 RAM、cache 要 NVMe。NCSE Network 提供臺灣是方電訊機房的 VPS，Intel Xeon Gold 處理器搭配 NVMe SSD 儲存，適合承載多人共用的開發環境；如果需要跑跨機器的 Kubernetes 叢集或直接跟 AWS 拉專線接 Coder 控制平面，可以參考 NCSE Network 的機房代管與 IP Transit 方案。