解读 OpenTofu：Terraform 的分支、迁移之路，以及是否值得切换

如今打开一个 Terraform 模块，你会面对一个三年前根本不存在的问题:运行这段代码的二进制文件到底是 terraform，还是 tofu？IBM 已于 收购 HashiCorp 2025 年 2 月 27 日以 64 亿美元完成对 HashiCorp 的收购，OpenTofu 成为了 CNCF Sandbox 项目 2025 年 4 月 23 日成为 CNCF Sandbox 项目，两个工具之间的迁移路径现已被正式记录在案。这个决定不再是假设性的了。

本文从基础设施运维的角度撰写，而非托管 Terraform 平台的角度。目的是把真实的迁移成本与许可和治理方面的噪音区分开来。这意味着我可以坦率地谈谈迁移过程中会出什么问题、哪些治理问题是合理的，以及在哪些情况下继续使用 Terraform 才是正确的选择。

本文涵盖四方面内容：2026 年的 OpenTofu 是什么、Terraform 不具备的功能、实际迁移是什么样子，以及针对常见决策情形给出明确建议。

简短版本

• OpenTofu 是 Terraform 的开源分支，采用 MPL 2.0 许可证，由 Linux Foundation 托管，自 2025 年 4 月 23 日起成为 CNCF Sandbox 项目。它在 HashiCorp 于 2023 年 8 月将 Terraform 改为 Business Source License 之后，从 Terraform 1.5.x 分叉而来。
• 截至 2026 年 7 月 26 日，当前的维护版本是 v1.12.5；GitHub 仓库拥有超过 29,000 颗星， OpenTofu 项目官网 列出了 3,900 多个 provider 和 23,600 多个模块。
• 它提供了 Terraform 目前无法以同样方式匹敌的 OpenTofu 独有或领先的能力：客户端 state 和 plan 加密、provider for_each、提前变量求值、元参数 enabled 以及动态 prevent_destroy。临时资源（Ephemeral resources）并非 OpenTofu 独有；Terraform 自 1.10 版本起就已支持。
• 对于一个使用本地或 S3 state 的小型 Terraform 1.5.x 项目，顺利路径可能是一次简短、可逆的迁移。CI/CD 引用、HCP 专属工作流以及依赖锁文件的更改，才是工作量增加的地方。
• 对于 2026 年的新 IaC 项目，请从 OpenTofu 开始。对于现有的 Terraform 部署，当 BSL 开始限制你、当你需要一个 OpenTofu 有而 Terraform 没有的功能，或者当由 IBM 控制的路线图成为真正的顾虑时，再考虑迁移。否则成本收益并不明显。

2026 年的 OpenTofu 是什么

OpenTofu 是 Terraform 的开源分支，由 Linux Foundation 托管，于 2025 年 4 月 23 日作为 Sandbox 项目被 CNCF 接纳，并采用 Mozilla Public License 2.0 许可。其二进制文件名为 tofu。配置语言是 HCL，与 Terraform 使用的 HCL 相同。对于大多数简单到中型项目，现有的 Terraform 代码库无需修改即可在 OpenTofu 上运行。

该分支始于 2023 年 8 月，起因是 HashiCorp 将 Terraform 从 MPL 2.0 改为 Business Source License 1.1 （2023 年 8 月 10 日）。BSL 属于“源代码可见”而非 OSI 批准的许可证，限制了“与 HashiCorp 商业产品竞争”的生产环境使用。五天之内，OpenTF Manifesto 发布，分支计划也随之公布。Linux Foundation 的公告于 2023 年 9 月 20 日正式推出了 OpenTofu。

Linux Foundation 的公告 将 Harness、Gruntwork、Spacelift、env0、Scalr、Digger、Terrateam、Massdriver 和 Terramate 列为创始支持者，至少 18 名工程师承诺全职投入至少五年。OpenTofu 是从 Terraform 1.5.x（最后一个 MPL 2.0 版本）分叉而来的。

该项目今天的状况：v1.12.5 是当前的维护版本，官方网站列出了 3,900 多个 provider 和 23,600 多个模块。采用信号已不再局限于最初抗议性分叉的势头： Fidelity 迁移案例研究 描述了一个涵盖超过 50,000 个 state 文件和四百万个资源的项目。

相关商业背景：IBM 于 2025 年 2 月 27 日以 64 亿美元完成对 HashiCorp 的收购。Terraform 的路线图现在被置于一个规模大得多的企业供应商之内。这对用户来说未必是好事或坏事，但却是各团队在 2026 年做决策时需要考虑的一部分。

OpenTofu 与 Terraform 的不同之处

自分叉以来，两个项目走上了不同的功能发展道路。下表是简明版；随后的说明解释了每个差异对从业者意味着什么。

客户端 state 加密 （v1.7.0，2024 年 4 月 30 日）。 OpenTofu 可以在工具内部使用 PBKDF2、AWS KMS、GCP KMS 或 OpenBao 对 state 和 plan 文件进行加密。Terraform 通常将静态加密委托给所选的 backend，而本地 state 则保持明文。OpenTofu 的客户端加密可以保护被窃取的 state 对象或缓存的 plan，前提是解密密钥没有随之泄露。它不能取代 TLS、backend 访问控制或密钥管理规范。

配置大致如下：

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

提供商 for_each (v1.9)。 你可以像遍历 resource 一样遍历 provider 配置。对于多区域或多账户设置，这消除了一类长期存在的变通方案。你不再需要为每个区域手动创建一个带别名的 provider；可以从一个 map 驱动单个代码块。

提前变量求值（v1.8）。 变量现在可以在以前受限的位置被引用，包括 backend 和模块 source 参数。当一个根模块驱动多个仅在少量变量上有所不同的环境时，这非常有用。

临时资源与 enabled 元参数（v1.11.0，2025 年 12 月 9 日）。 OpenTofu 1.11 增加了临时资源和 enabled 元参数。临时资源只存在于单一的 plan/apply 周期内，不会持久化到 state 中，这对短期凭证很有用。它们并非 OpenTofu 独有：Terraform 在 1.10 中引入了它们，并在 1.11 中添加了仅写参数。这里 OpenTofu 特有的能力是 enabled，它可以通过表达式切换资源块，而无需借助 count count 的条件游戏。

动态 prevent_destroy （v1.12）。 Terraform 的设置 prevent_destroy 只接受字面量值。OpenTofu 1.12 允许你对其进行计算，因此一个模块可以让 staging 保持可删除，同时保护 production。

许可证这一行是不会以功能形式体现的结构性差异。MPL 2.0 经 OSI 批准，是文件级 copyleft 许可证。Terraform 的 BSL 1.1 许可证属于源代码可见，包含额外的使用限制，并在每部受许可作品发布四年后转为 MPL 2.0。对大多数团队来说，实际影响很小；但对那些构建接近 HashiCorp 商业产品的供应商来说，这正是该分支存在的原因。

迁移：到底什么会出问题

官方迁移指南 刻意保持简短且可逆：备份 state 和代码，安装 OpenTofu，运行 tofu init，比较 tofu plan结果，并测试一个小改动。困难的部分不是命令本身，而是周围的 CI/CD 引用、HCP 专属工作流、依赖锁的变更，以及采用分支所伴随的组织内部审查。

顺利路径

对于不使用 HCP Terraform、且流水线中没有成千上万处引用 terraform的项目来说，迁移非常直接。

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan 应该与 Terraform 生成的 plan 一致。如果出现意外差异，在 apply 之前请检查 provider 版本、backend 设置以及任何 1.5.x 之后新增的 Terraform 功能。

在运行任何操作之前，有两个细节很重要。第一，对于本指南所描述的情形，OpenTofu 与 Terraform 风格的 HCL 在配置上大体兼容，但 Terraform 1.5.x 之后新增的功能仍需检查兼容性。第二， tofu init -upgrade 可能会更新 .terraform.lock.hcl，包括 provider 源地址和校验和条目。请将这些元数据与基础设施漂移分开审查。

真正的障碍

有三件事可能把一次快速的 CLI 迁移变成更大规模的平台项目。它们都不是 bug。

HCP Terraform 工作区。 OpenTofu 包含 cloud 和 remote 集成 以兼容 remote 服务，包括在本地执行和 state 存储场景下的 HCP Terraform。较难的部分是 HCP 专属的远程执行和平台功能：Sentinel、run trigger、动态凭证、Stacks，以及任何 OpenTofu 无法完全测试或支持的服务行为。如果这些是核心需求，先试点一个工作区；如果你要离开 HCP，请迁移 state 并重建这些平台控制机制。

小贴士：如果整个体系依赖 HCP 专属工作流，离开 HCP Terraform 可能是最大的隐性成本。在决定之前，运行 terraform state pull > state.json 并检查规模和资源数量。一个拥有 200 个资源的工作区，与一支拥有 run trigger 和 policy set 的 50 个工作区的“舰队”是完全不同的项目。后者是一次平台工程级别的迁移，而不仅仅是工具替换。

为 terraform. 而硬编码的 CI/CD 流水线。每一处对 terraform plan, terraform apply的引用、二进制路径、Docker 镜像，以及 GitHub Actions 或 GitLab CI 步骤都需要检查。以 GitHub Actions 为例，替换方式大致如下：

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

这是最简单的情况：一个工作流，一个仓库。而在拥有共享 composite action、多条流水线和可复用工作流库的 monorepo 中，审查面要广得多。这项工作是机械性的，但可能比单纯替换 CLI 花更多时间。

依赖锁文件审查。 tofu init 可能会更新 .terraform.lock.hcl更新，包括 provider 源地址和校验和条目。OpenTofu 1.12 还可以添加完整的 h1: h1: 校验和集合。请将这个 diff 视为需要单独审查并提交的依赖元数据，而不是基础设施漂移。

小贴士：首次提交时锁文件的 diff 可能看起来很杂乱。运行 tofu init -upgrade 在一个干净的分支上，只提交 lock 文件，并附上清晰的信息，例如 "review OpenTofu lock-file changes"，然后将功能开发工作 rebase 到它上面。把依赖元数据和功能 PR 混在一起会让两处改动都更难审查。

利益相关者的抵触。 “我们现在跑的是一个分支”在不同组织里的反响并不相同。诚实的反驳是：对于本指南所描述的情形，OpenTofu 在配置上与 Terraform 风格的 HCL 大体保持兼容，因此这种切换通常是可逆的。如果 OpenTofu 明天消失，许多团队完全可以重新安装 Terraform、审查锁文件，并继续使用同样的 .tf .tf 文件。先验证分支后新增的功能；这种保留态度比承诺完美互换更可信。

迁移真正困难的情况

这条顺利路径并不适用于所有 Terraform 体系。

在以下情况下，迁移会明显变得更难：

• state 规模庞大（成千上万个资源、数十个工作区）且存放在 HCP Terraform 中。
• 代码库深度使用仅限 HCP 的功能：与工作区绑定的 Sentinel 策略、run trigger、HCP 管理的动态 provider 凭证。Terraform Stacks 是 HCP 独有的，在 OpenTofu 中没有对应功能，这不在本文讨论范围内。
• 企业审计或合规框架明确将 "Terraform" 列为官方 IaC 工具，这在技术问题之外又增加了采购和文档方面的问题。
• 大型模块库存在内部版本约束，这些约束是依据 Terraform 特有的 registry 行为来解析的。

并不是每个团队都应该迁移。只有当 BSL 的限制确实影响到你的使用场景、某个 OpenTofu 特有功能能解决具体问题，或者 IBM 主导的路线图确实让你的组织担忧时，成本收益权衡才有意义。如果都不符合，继续使用 Terraform 也是完全站得住脚的选择。

你应该切换吗？

这里没有唯一正确的答案。当我为一个团队画决策树时，通常会出现四种常见情形，正确的做法取决于你处在哪一种情形中。

全新采用 IaC（greenfield）。 从 OpenTofu 开始。它的许可证是 MPL 2.0，治理归属 Linux Foundation 和 CNCF，项目发布节奏活跃。它的差异化优势包括客户端 state 加密、provider for_each, enabled，以及动态 prevent_destroy。无需为 BSL 相关摩擦做任何规划。这是本文中最有力的建议。

现有 Terraform 用户，中小型项目。 如果满足以下三个触发条件中的任意一个，就该切换。第一：你正在销售或可能销售一款可能触及 BSL “与 HashiCorp 竞争” 排除条款的产品；在 MPL 2.0 下，法律层面的计算更清晰。第二：你需要客户端 state 加密、provider for_each, enabled，或动态 prevent_destroy ，并且 Terraform 的变通方案已不值得维护。第三：你更偏好多方治理，而不是单一供应商主导的路线图。如果以上都不适用，且 Terraform 运行良好，那就留下来。在许多体系中迁移是可逆的，但不是免费的。

HCP Terraform 重度用户。 把这看作一个平台层面的决策，而不是理所当然的 backend 迁移。OpenTofu 可以使用兼容的 remote backend，但 HCP 专属的远程执行、Sentinel、run trigger、动态凭证和 Stacks 仍需逐项评估。如果这些控制机制是核心需求，先做试点。如果你因许可、成本或治理原因离开 HCP，就把这项工作当作一次平台迁移来规划。

考虑使用 Pulumi 或其他非 HCL 方案。 如果你想保留 HCL 和大部分现有工作流，OpenTofu 是最接近的路径。而 Pulumi 是一个更广泛的平台和语言选择：TypeScript、Python、Go 或 .NET 驱动云 API。转向那里可能涉及转换甚至重写，因此应将其与单纯的 Terraform 到 OpenTofu 二进制切换分开评估。

还有一点值得直接说明：有一种合理的批评认为，OpenTofu 在一定程度上是 SaaS 厂商的对冲手段。一条关于 BSL 变更的 Hacker News 讨论帖提出了这样的担忧：该项目的创始成员是拥有自身许可灵活性诉求的商业化 Terraform 平台。我认真对待这种担忧。缓解因素在于其治理结构——Linux Foundation 托管、CNCF Sandbox 身份、每个文件都采用 MPL 2.0——这使得未来重新授权比单一供应商时要困难得多。这并不意味着不可能，但确实让代价高到足以形成一种真正的制衡。

简要结论。 对于 2026 年的新 IaC 工作，从 OpenTofu 开始。它的许可证、治理、活跃的开发和功能集使其成为强有力的默认选择。对于现有的 Terraform 部署，当上述三个触发条件之一成立时再切换；否则成本收益不明显，继续留下也没问题。

一旦工具选择明确，接下来实际的问题就是 OpenTofu 应该在哪里运行。这个决定会影响密钥处理、成本、可重复性，以及你的团队对执行环境的掌控程度。

自行运行 OpenTofu

OpenTofu 是一个 CLI 二进制文件。你在哪里运行它，很大程度上决定了成本、安全性以及你能用它做什么。大致有三个合理的放置位置。

笔记本电脑或开发机器。 适合一次性 plan、原型开发和小型个人项目。除非已经强制实施了 remote state、锁定和审查规范，否则它对共享的生产工作流来说是个糟糕的默认选择。团队通常更受益于一个规范统一的执行环境，而不是依赖某台“最后一次运行了 tofu apply.

托管 CI runner（GitHub Actions、GitLab CI 等）。 命令”的笔记本电脑。常见路径。 opentofu/setup-opentofu action 是 hashicorp/setup-terraform hashicorp/setup-terraform 的直接替代品。这对大多数团队和项目都很适用。权衡之处：密钥需要经过第三方 CI 服务，免费额度分钟数可能在大型 state 操作中耗尽，而 runner 环境是临时性的，这通常是优点，但有时也是限制。参见 GitHub vs GitLab ，如果你仍在托管 CI 方案之间犹豫，另请参见 Best CI/CD Tools 以获得更全面的了解。

在 VPS 上自托管的 runner。 当托管 CI 的权衡开始行不通时会很有用：密钥必须不经过第三方服务、CI 分钟数变得昂贵，或者你想要持久化的 provider 缓存。设置很简单：一台 Linux VPS、OpenTofu 二进制文件、一个 GitHub Actions 或 GitLab Runner 代理，以及用于任务隔离的 Docker。参见 Install Docker on VPS ，如果这部分对你来说是新领域。对于小团队的 runner，4 GB 内存、2 个 vCPU 和 60 GB NVMe 是合理的起点；针对更大的 plan 和更高的并发量，请相应扩展 CPU、内存和存储。

对于需要更严格控制 runner 密钥、需要持久化 provider 缓存或可预测 CI 成本的团队来说，在 VPS 上自托管 runner 是合理的选择。在这种设置中，优先考虑 root 权限、快速 NVMe 存储、易于调整规模，以及足够的 CPU/内存以应对更大规模的 plan 操作。

Cloudzy Linux VPS 实例正好符合这种自托管 runner 模式：拥有 root 权限、NVMe 存储和灵活的规格调整，因此你可以从小规模起步，随着 OpenTofu 工作负载的增长逐步扩展 runner。

常见问题

OpenTofu 和 Terraform 是一回事吗？

并不完全是。OpenTofu 最初是 Terraform 1.5.x 的一个分支，在配置上仍与 Terraform 风格的 HCL 大体兼容：相同的 .tf .tf 文件、相同的 provider，以及相同的 plan/apply plan/apply 工作流。它们的区别在于许可证以及分叉后新增的功能。OpenTofu 拥有客户端 state 加密、provider for_each, enabled，以及动态 prevent_destroy；而 Terraform 也有自己的分叉后功能，包括临时资源。

OpenTofu 会支持我所有的 Terraform Provider 吗？

对于 AWS、GCP、Azure、Kubernetes 和 Helm 这样的主流 provider，通常是可以的。 OpenTofu Registry 截至 2026 年 7 月报告有 3,900 多个 provider。 tofu init 可能会更新 .terraform.lock.hcl tofu init 可能会更新元数据。对于小众、特定厂商或新发布的 provider，切换前请直接核实其可用性和版本支持情况。

OpenTofu 本身未来会被重新授权吗？

未来重新授权比 Terraform 当年的情况更难，但并非不可能。OpenTofu 采用 MPL 2.0 许可证，由 Linux Foundation 托管，自 2025 年 4 月 23 日起成为 CNCF Sandbox 项目。其治理是多方参与的，许可证也经过 OSI 批准。任何单一创始人单方面重新授权，都将与基金会章程以及现有的 MPL 2.0 贡献相冲突——那些贡献必须被移除或重写。这种担忧是合理的；结构性壁垒也是真实存在的。

IBM 收购 HashiCorp 对 Terraform 的未来意味着什么？

IBM 于 2025 年 2 月 27 日以 64 亿美元完成对 HashiCorp 的收购。Terraform 的路线图现在归属于一个更大的企业供应商。仅凭这次收购本身并不能证明未来的许可或产品走向；应评估当前的发行说明、许可指导以及 HCP 产品变化，而不是把所有权变化当作一种预测。

OpenTofu 在 2026 年是否已经具备生产就绪能力？

是的。v1.12.5 是当前的维护版本，该项目位于 CNCF Sandbox，而 Fidelity 已经描述了在一个拥有超过 50,000 个 state 文件和四百万资源的 IaC 体系中实现生产环境采用的情况。生产就绪并不代表功能完全一致：依赖 Terraform Stacks 等仅限 HCP 能力的团队，仍需单独评估兼容性。