把 Infrastructure as Code 寫成自動化流程的人，這兩年大概都被 Terraform 的授權變動弄得很不安。2023 年 8 月 HashiCorp 把 Terraform 從 MPL 2.0 換成 Business Source License，2025 年初 IBM 完成對 HashiCorp 的收購，整套生態系從一家獨立公司的開源工具，變成了一家雲端巨頭旗下的商業產品。OpenTofu 在這段時間從一個帶有抗議性質的 fork，逐步累積出自己的版本節奏、自己的功能優先順序，到 2026 年中已經很難再用「Terraform 替代品」一句話帶過。
這場分裂的重點不在「誰才是正版」，而在兩條路線實質上做出了不一樣的選擇。對任何還在用 Terraform 管基礎設施的團隊，這個時間點該重新評估手上的 IaC 工具到底走在哪一條路上。
BUSL 不是技術問題，是合規問題
HashiCorp 在公告裡強調，BUSL 對絕大多數使用者沒有影響——只有把 Terraform 包裝成「與 HashiCorp 競爭的商業服務」才會受限。乍看之下這個限制很窄，但實務上它在幾個地方產生了真實的摩擦。
歐盟有不少公部門與大型企業的採購政策要求使用 OSI 認證的開源授權，BUSL 不在這份名單裡。GitLab 在 2025 年 5 月的 18.0 版本直接停用了內建的 Terraform CI/CD template，理由就是授權合規問題。CNCF 也明確表態，只有 OpenTofu 能進入孵化流程，BUSL 版本的 Terraform 從一開始就不在考慮範圍。
對自架 VPS、自己維運基礎設施的中小團隊來說，這些政策層面的限制看起來離自己很遠。但只要團隊規模成長到需要跟客戶簽 SOC 2、ISO 27001 這類合規文件，授權清單就會被法務一行一行檢查。BUSL 不是不能用，但每多一份非 OSI 授權就多一份解釋成本。OpenTofu 把這個成本一次清零。
分家兩年後，功能差距已經實質形成
OpenTofu 在 2024 到 2026 年的版本演進，路線跟 Terraform 不太一樣。Terraform 把重心放在 HCP Terraform、Stacks、Sentinel policy 這些跟 HashiCorp Cloud Platform 緊密綁定的功能上，社群手上的 CLI 工具反而沒怎麼動。OpenTofu 走的方向相反，把社群長期想要但官方一直沒排上的功能優先做掉。
State 加密是最具代表性的例子。Terraform 的 state file 預設明文儲存，裡面常常包含資料庫密碼、API key、IAM role 等敏感資訊。多年來社群一直要求加密選項，HashiCorp 的態度是「state file 應該存在安全的 backend，不需要在 client 端加密」。OpenTofu 1.7 直接內建 client-side state encryption，1.11 又加入了 ephemeral values 機制，讓敏感變數可以只在執行期存在、不寫進 state。
Ephemeral values 解決的是另一個老問題：Terraform 的 plan 跟 apply 階段，敏感資料會在 state 跟 plan file 裡留下痕跡。對需要符合資料保護規範的環境，這個設計一直很尷尬。OpenTofu 的做法是讓變數標記為 ephemeral，整個 IaC 流程裡這個值只存在記憶體，結束就消失。
Backend 設定區塊裡能不能用變數，這也是社群長年呼聲。Terraform 一直擋著理由是「backend 必須在所有變數解析之前確定」，OpenTofu 1.8 找到了 early variable evaluation 的解法，現在可以用變數動態切換 backend，多環境部署的腳本變得乾淨很多。
S3 backend 的 state lock 過去必須搭配 DynamoDB，這對只用 AWS 一兩個服務的小團隊是不必要的負擔。OpenTofu 1.10 改用 S3 自家的 conditional write 達成 lock 機制，DynamoDB 整個可以不用建。OCI registry 的支援也在同一版本進來，意思是 provider 跟 module 可以放進 ghcr.io、自架的 Harbor 或任何相容 OCI 的 registry，不必透過 Terraform Registry 中轉。
這些功能單獨看都不算革命性，但加總起來就是一條越走越遠的分支路線。Terraform 1.14 沒有任何一項對應實作。
Terraform Stacks 跟 OpenTofu 的差距該怎麼看
Terraform 這邊也不是停滯。Stacks 在 2025 年 9 月正式 GA，定位是把多元件的部署編排做進 Terraform 本身，類似於 CDK 的 stack 概念但語法仍然是 HCL。對於管理幾十個微服務、每個都有自己 Terraform 模組的大型工程組織，Stacks 確實補上了過去要靠 Terragrunt、Atmos 之類第三方工具才能做到的事。
但 Stacks 在實際使用上有兩個限制。一是這個功能在 CLI 端是免費的，但完整的執行體驗綁定 HCP Terraform——遠端執行、state 管理、policy 評估都需要付費的 HashiCorp Cloud Platform。對自己跑 IaC 的團隊，Stacks 提供的價值會打折扣。二是 Stacks 採用了新的 .tfdeploy.hcl 與 .tfstack.hcl 檔案結構，跟既有的 .tf 檔不能無縫共存，等於要求團隊額外學一套語法。
OpenTofu 對 Stacks 的回應比較保守，目前沒有對等實作的計畫，傾向讓 Terragrunt 跟 Atmos 繼續扮演 orchestration 層。這個選擇有其道理：Terragrunt 已經在生態系裡用了多年，與其重新發明，不如把 OpenTofu CLI 本身做得更好，讓外部工具用得更順。
遷移其實只有四步，麻煩在週邊
技術層面的 Terraform 到 OpenTofu 遷移流程，意外地直接：安裝 tofu CLI、執行 tofu init 重新初始化、跑 tofu plan 確認 state 相容、把 CI/CD 的 terraform 指令換成 tofu。OpenTofu 對 .tf 檔的相容性保持得很好，多數 1.5 以前寫的設定可以直接吃。
Fidelity Investments 在 2025 年公開分享過他們把 2000 多個應用、5 萬份 state file 遷移到 OpenTofu 的過程。他們的結論是 CLI 切換很快，難的是整個週邊生態：CI runner 的 image、Atlantis 之類 PR 工具的設定、自家寫的 Terraform module 在 Registry 上的發布管道、各種 IDE 整合。這些東西沒有立刻支援 OpenTofu 的話，遷移完當天工程師會發現自動補全壞了、PR comment 沒了、template 跑不起來。
Spacelift 在 2026 年初的數據顯示，他們平臺上的 OpenTofu 部署量已經佔到一半。這個比例的背後其實是大型企業遷移完成後帶動的，獨立開發者跟小團隊的轉換速度反而沒這麼快——他們手上的 Terraform 1.5 還在跑，沒有立即遷移的迫切性。
對還在 Terraform 0.12、0.13、0.14 這些老版本上的環境，建議反而不是急著遷 OpenTofu。先把 HCL 語法升到 1.x 相容的程度，再決定要往 Terraform 1.14 或 OpenTofu 1.12 走，比一次跨越多個版本邊界穩定得多。
哪一邊適合自架基礎設施
如果只是管幾臺 VPS 上的 Docker 容器、DNS 紀錄、雲端 storage bucket，OpenTofu 是更合理的選擇。理由不是因為「開源比較好」這種立場性的講法，而是 OpenTofu 在小型自架場景該有的功能更完整：state 加密讓 backend 不用太挑、S3 lock 不必另外開 DynamoDB、OCI registry 讓 module 可以直接放進已經有的 container registry。維運成本更低，需要的雲端服務更少。
如果團隊已經在用 HashiCorp Cloud Platform 的完整堆疊——Vault、Consul、Nomad、Boundary 都接好了，搭配 HCP Terraform 的 workspace 跟 Sentinel 跑 policy——那繼續用 Terraform 是合理的，分裂出去會打破整套產品線的整合性。但這種規模的團隊，通常也已經有專職的 platform 工程師處理授權合規問題了。
中間地帶最尷尬：用了 Terraform 多年但沒有重度綁定 HCP，這時候真正該問的問題是「未來三年想要哪一種更新節奏」。OpenTofu 的釋出週期更短、社群修補更積極；Terraform 的步調受 IBM 商業策略主導，方向上會偏向跟 watsonx、OpenShift 整合，跟單純的 IaC 場景關係越來越遠。
部署這條路線的選擇
OpenTofu 用兩年時間證明了一件事：開源 IaC 不一定要綁定在原本的維護方身上。授權變動是觸發點，但讓 fork 真正立得住的是 CNCF 的治理、廣泛的廠商支持、跟一份持續往社群長期需求走的路線圖。
把 OpenTofu 接進部署流程其實不複雜，CI runner 拉個新 image、CD pipeline 換個指令名稱，State backend 用既有的 S3 或 OpenBao 就能搞定。NCSE Network 在臺灣是方電訊機房提供搭載 Intel Gold CPU 與 NVMe SSD 的 VPS 主機，跑 CI runner、Atlantis、self-hosted state backend 這類 IaC 週邊服務的延遲跟頻寬條件都很穩，把整套 OpenTofu 工作流搬回自家機房是合理的下一步。
