Mở một module Terraform hôm nay và bạn sẽ đối mặt với câu hỏi không hề tồn tại ba năm trước: tệp nhị phân chạy đoạn mã này là terraform, hay là tofu? IBM đã hoàn tất thương vụ mua lại HashiCorp vào ngày 27 tháng 2 năm 2025 với giá 6,4 tỷ đô la, và OpenTofu đã trở thành dự án Sandbox của CNCF vào ngày 23 tháng 4 năm 2025, và lộ trình di chuyển giữa hai công cụ này đã được ghi lại chính thức. Quyết định này không còn là giả định nữa.
Bài viết này được viết từ góc nhìn vận hành hạ tầng, không phải từ góc nhìn của một nền tảng Terraform được quản lý. Mục tiêu là tách bạch chi phí di chuyển thực sự khỏi những ồn ào về giấy phép và quản trị. Điều đó có nghĩa là tôi có thể nói thẳng về những gì sẽ hỏng trong quá trình di chuyển, những câu hỏi quản trị chính đáng, và những trường hợp mà việc tiếp tục dùng Terraform mới là lựa chọn đúng.
Bài viết này đề cập đến bốn vấn đề: OpenTofu là gì vào năm 2026, những tính năng mà Terraform không có, quá trình di chuyển thực tế diễn ra như thế nào, và một khuyến nghị rõ ràng cho các tình huống quyết định phổ biến.
Phiên bản ngắn gọn
- OpenTofu là bản phân nhánh mã nguồn mở của Terraform, cấp phép theo MPL 2.0, được Linux Foundation lưu trữ, và là dự án Sandbox của CNCF kể từ ngày 23 tháng 4 năm 2025. Nó được tách ra từ Terraform 1.5.x sau khi HashiCorp chuyển Terraform sang giấy phép Business Source License vào tháng 8 năm 2023.
- Tính đến ngày 26 tháng 7 năm 2026, bản phát hành bảo trì hiện tại là v1.12.5; kho lưu trữ trên GitHub có hơn 29.000 lượt gắn sao, và trang web dự án OpenTofu liệt kê hơn 3.900 provider và hơn 23.600 module.
- Nó cung cấp các tính năng chỉ có ở OpenTofu hoặc do OpenTofu dẫn đầu mà Terraform hiện chưa có tương đương: mã hóa state và plan phía client, provider
for_each, đánh giá biến sớm,enabledmeta-argument, vàprevent_destroy. Ephemeral resources không phải là tính năng riêng của OpenTofu; Terraform đã hỗ trợ chúng từ phiên bản 1.10. - Với một dự án nhỏ trên Terraform 1.5.x dùng state cục bộ hoặc S3, con đường thuận lợi có thể là một cuộc di chuyển ngắn gọn và có thể đảo ngược. Khối lượng công việc tăng lên ở các tham chiếu CI/CD, quy trình đặc thù của HCP, và các thay đổi trong tệp khóa phụ thuộc (dependency-lock).
- Với một dự án IaC mới vào năm 2026, hãy bắt đầu với OpenTofu. Với một hệ thống Terraform đang triển khai, hãy chuyển đổi khi BSL gây khó khăn thực sự, khi bạn cần một tính năng mà OpenTofu có còn Terraform thì không, hoặc khi lộ trình phát triển do IBM kiểm soát là một mối lo thực sự. Nếu không, lợi ích so với chi phí là khá mỏng.
OpenTofu là gì vào năm 2026
OpenTofu là bản phân nhánh mã nguồn mở của Terraform, được Linux Foundation lưu trữ, được CNCF chấp nhận làm dự án Sandbox vào ngày 23 tháng 4 năm 2025, và cấp phép theo Mozilla Public License 2.0. Tệp nhị phân có tên là tofu. Ngôn ngữ cấu hình là HCL, cùng loại HCL mà Terraform sử dụng. Với hầu hết các dự án đơn giản đến trung bình, mã nguồn Terraform hiện có chạy trên OpenTofu mà không cần thay đổi.
Bản phân nhánh này bắt đầu vào tháng 8 năm 2023 sau khi HashiCorp chuyển Terraform từ MPL 2.0 sang Business Source License 1.1 vào ngày 10 tháng 8 năm 2023. BSL là giấy phép source-available chứ không được OSI phê duyệt, và hạn chế việc sử dụng trong môi trường sản xuất mà "cạnh tranh với các sản phẩm thương mại của HashiCorp." Trong vòng năm ngày, OpenTF Manifesto đã được công bố và một bản phân nhánh được thông báo. Thông báo của Linux Foundation chính thức giới thiệu OpenTofu vào ngày 20 tháng 9 năm 2023.
Thông báo của Linux Foundation đã nêu tên Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver, và Terramate trong số các bên ủng hộ sáng lập, với ít nhất 18 kỹ sư cam kết làm việc toàn thời gian trong tối thiểu năm năm. OpenTofu được tách ra từ Terraform 1.5.x, nhánh cuối cùng theo MPL 2.0.
Dự án hiện đang ở đâu: v1.12.5 là bản phát hành bảo trì hiện tại, và trang web chính thức liệt kê hơn 3.900 provider và hơn 23.600 module. Các tín hiệu về mức độ áp dụng không còn giới hạn ở đà phản đối ban đầu nữa: nghiên cứu tình huống di chuyển của Fidelity mô tả một chương trình bao trùm hơn 50.000 tệp state và bốn triệu resource.
Bối cảnh kinh doanh liên quan: IBM đã hoàn tất việc mua lại HashiCorp vào ngày 27 tháng 2 năm 2025 với giá 6,4 tỷ đô la. Lộ trình phát triển của Terraform giờ đây nằm trong tay một nhà cung cấp doanh nghiệp lớn hơn nhiều. Điều đó không tự động tốt hay xấu cho người dùng, nhưng đó là một phần trong phép tính mà các đội ngũ đang cân nhắc vào năm 2026.
OpenTofu khác Terraform ở điểm nào
Kể từ khi phân nhánh, hai dự án đã đi theo những hướng phát triển tính năng khác nhau. Bảng dưới đây là phiên bản tóm tắt; các ghi chú tiếp theo giải thích ý nghĩa thực tế của từng khác biệt đối với người dùng.
| Tính năng | OpenTofu | Terraform | Từ phiên bản |
|---|---|---|---|
| Mã hóa state phía client | Tích hợp sẵn (PBKDF2, AWS KMS, GCP KMS, OpenBao) | Do backend quản lý khi lưu trữ (at rest) | v1.7 (tháng 4/2024) |
| Đánh giá biến sớm | Có | Không được hỗ trợ | v1.8 |
Nhà cung cấp for_each | Có | Không có tương đương tích hợp sẵn | v1.9 |
| Ephemeral resources | Có | Có, từ Terraform 1.10 | OpenTofu v1.11 / Terraform v1.10 |
enabled meta-argument | Có | Không được hỗ trợ | v1.11 (tháng 12/2025) |
Động prevent_destroy | Có | Chỉ tĩnh | v1.12 (tháng 5/2026) |
| Giấy phép | MPL 2.0 (được OSI phê duyệt) | BSL 1.1 (chưa được OSI phê duyệt) | Không áp dụng |
Phía client mã hóa state (v1.7.0, 30 tháng 4 năm 2024). OpenTofu có thể mã hóa các tệp state và plan ngay trong công cụ bằng PBKDF2, AWS KMS, GCP KMS, hoặc OpenBao. Terraform thường giao việc mã hóa khi lưu trữ (at rest) cho backend đã chọn, trong khi state cục bộ vẫn ở dạng văn bản thuần. Mã hóa phía client của OpenTofu có thể bảo vệ một đối tượng state hoặc plan bị đánh cắp, miễn là khóa giải mã không bị lộ cùng với nó. Nó không thay thế cho TLS, kiểm soát truy cập backend, hay kỷ luật quản lý bí mật.
Cấu hình trông đại khái như sau:
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
}
}
}Nhà cung cấp for_each (v1.9). Bạn có thể lặp (iterate) cấu hình provider giống như cách lặp resource. Với các thiết lập đa vùng (multi-region) hoặc đa tài khoản, điều này loại bỏ một lớp giải pháp tình thế đã tồn tại lâu dài. Bạn không còn cần tự viết tay từng provider có alias cho mỗi vùng nữa; bạn có thể điều khiển một khối duy nhất từ một map.
Đánh giá biến sớm (v1.8). Các biến giờ có thể được tham chiếu ở những nơi trước đây bị hạn chế, bao gồm các đối số backend và nguồn module. Điều này hữu ích khi một module gốc điều khiển nhiều môi trường chỉ khác nhau ở một tập hợp nhỏ các biến.
Ephemeral resources và enabled meta-argument (v1.11.0, 9 tháng 12 năm 2025). OpenTofu 1.11 đã bổ sung ephemeral resources và enabled meta-argument. Ephemeral resources chỉ tồn tại trong một chu kỳ plan/apply duy nhất và không được lưu vào state, điều này hữu ích cho thông tin xác thực dùng trong thời gian ngắn. Chúng không phải tính năng riêng của OpenTofu: Terraform đã giới thiệu chúng ở bản 1.10 và bổ sung đối số write-only ở bản 1.11. Khả năng đặc thù của OpenTofu ở đây là enabled, cho phép bật/tắt một khối resource dựa trên một biểu thức mà không cần dùng count kiểu "thể dục nhào lộn" với count.
Động prevent_destroy (v1.12). Cài đặt prevent_destroy prevent_destroy trong Terraform chỉ chấp nhận giá trị cố định (literal). OpenTofu 1.12 cho phép bạn tính toán giá trị này, nhờ đó một module có thể vừa cho phép xóa môi trường staging vừa bảo vệ môi trường production.
Dòng về giấy phép là khác biệt mang tính cấu trúc, không thể hiện ra như một tính năng. MPL 2.0 được OSI phê duyệt và là copyleft ở cấp độ tệp. Giấy phép BSL 1.1 của Terraform là source-available, có thêm một hạn chế sử dụng, và chuyển thành MPL 2.0 sau bốn năm kể từ khi mỗi tác phẩm được cấp phép công bố. Với hầu hết các đội ngũ, tác động thực tế là nhỏ; nhưng với các nhà cung cấp xây dựng thứ gì đó gần giống sản phẩm thương mại của HashiCorp, đây chính là lý do bản phân nhánh này tồn tại.
Di chuyển: Điều gì thực sự bị hỏng
Hướng dẫn di chuyển chính thức được thiết kế cố tình ngắn gọn và có thể đảo ngược: sao lưu state và mã nguồn, cài đặt OpenTofu, chạy tofu init, so sánh với tofu plan, và thử nghiệm một thay đổi nhỏ. Phần khó không nằm ở các câu lệnh. Nó nằm ở các tham chiếu CI/CD xung quanh, quy trình đặc thù của HCP, các thay đổi trong khóa phụ thuộc, và quá trình rà soát nội bộ đi kèm với việc áp dụng một bản phân nhánh.
Con đường thuận lợi
Với một dự án không dùng HCP Terraform và không có hàng nghìn tham chiếu pipeline tới terraform, việc di chuyển khá đơn giản.
# 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 plantofu plan phải khớp với plan mà Terraform đã tạo ra. Nếu có sự khác biệt bất ngờ, hãy kiểm tra phiên bản provider, cấu hình backend, và bất kỳ tính năng nào của Terraform sau 1.5.x trước khi áp dụng.
Có hai điểm tinh tế cần lưu ý trước khi bạn chạy bất cứ điều gì. Thứ nhất, OpenTofu nhìn chung tương thích về cấu hình với HCL kiểu Terraform cho các trường hợp mà hướng dẫn này mô tả, nhưng các tính năng được thêm vào sau Terraform 1.5.x vẫn cần được kiểm tra tính tương thích. Thứ hai, tofu init -upgrade có thể cập nhật .terraform.lock.hcl, bao gồm địa chỉ nguồn của provider và các mục checksum. Hãy xem xét các metadata này tách biệt khỏi hiện tượng trôi dạt hạ tầng (infrastructure drift).
Những rào cản thực sự
Có ba yếu tố có thể biến một cuộc di chuyển CLI nhanh gọn thành một dự án nền tảng quy mô lớn hơn. Không yếu tố nào trong số đó là lỗi.
Workspace của HCP Terraform. OpenTofu bao gồm các tích hợp cloud và remote cho các dịch vụ remote tương thích, bao gồm HCP Terraform trong các kịch bản thực thi cục bộ và lưu trữ state. Phần khó hơn là việc thực thi từ xa và các tính năng nền tảng đặc thù của HCP: Sentinel, run trigger, thông tin xác thực động, Stacks, và bất kỳ hành vi dịch vụ nào mà OpenTofu chưa thể kiểm thử hoặc hỗ trợ đầy đủ. Nếu những thứ đó là trọng tâm, hãy thử nghiệm một workspace trước; nếu bạn đang rời khỏi HCP, hãy di chuyển state và tái tạo lại các cơ chế kiểm soát nền tảng đó.
Mẹo: Rời bỏ HCP Terraform có thể là chi phí ẩn lớn nhất nếu hệ thống phụ thuộc vào các quy trình đặc thù của HCP. Trước khi quyết định, hãy chạy terraform state pull > state.json và kiểm tra kích thước cùng số lượng resource. Một workspace với 200 resource là một dự án khác hẳn so với một hạm đội 50 workspace có run trigger và bộ chính sách. Trường hợp sau là một cuộc di chuyển ở tầm platform engineering, không phải chỉ đơn thuần đổi công cụ.
Pipeline CI/CD được viết cứng cho terraform. Mọi tham chiếu tới terraform plan, terraform apply, đường dẫn tệp nhị phân, image Docker, và bước trong GitHub Actions hay GitLab CI đều cần được rà soát. Với GitHub Actions, việc thay thế đại khái như sau:
# 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Đó là trường hợp đơn giản nhất: một workflow, một repo. Trong một monorepo với các composite action dùng chung, nhiều pipeline, và một thư viện workflow tái sử dụng, phạm vi cần rà soát rộng hơn nhiều. Công việc này mang tính máy móc, nhưng có thể mất nhiều thời gian hơn so với việc chỉ đổi CLI.
Rà soát tệp khóa phụ thuộc. tofu init có thể cập nhật .terraform.lock.hcl, bao gồm địa chỉ nguồn của provider và các mục checksum. OpenTofu 1.12 cũng có thể bổ sung đầy đủ h1: bộ checksum cho tất cả các nền tảng. Hãy coi diff này là metadata phụ thuộc cần rà soát và commit riêng, không phải là hiện tượng trôi dạt hạ tầng.
Mẹo: Diff của tệp khóa có thể trông lộn xộn ở lần commit đầu tiên. Hãy chạy tofu init -upgrade trên một nhánh sạch, chỉ commit tệp lock với thông điệp rõ ràng như "review OpenTofu lock-file changes", sau đó rebase công việc tính năng lên trên. Trộn lẫn metadata phụ thuộc vào một PR tính năng khiến cả hai thay đổi khó review hơn.
Sự phản đối từ các bên liên quan. "Chúng ta đang chạy một bản phân nhánh" nghe khác nhau tùy từng tổ chức. Câu trả lời trung thực là OpenTofu vẫn tương thích rộng rãi về cấu hình với HCL kiểu Terraform cho các trường hợp mà hướng dẫn này mô tả, nên việc chuyển đổi thường có thể đảo ngược được. Nếu OpenTofu biến mất vào ngày mai, nhiều đội ngũ vẫn có thể cài lại Terraform, kiểm tra tệp khóa, và tiếp tục dùng cùng những tệp .tf tệp .tf. Hãy kiểm chứng các tính năng xuất hiện sau khi phân nhánh trước; lời cảnh báo này đáng tin hơn là hứa hẹn khả năng thay thế hoàn hảo.
Khi nào việc di chuyển thực sự khó khăn
Con đường thuận lợi đó không áp dụng cho mọi hệ thống Terraform.
Việc di chuyển trở nên khó khăn hơn đáng kể khi:
- State có quy mô lớn (hàng nghìn resource, hàng chục workspace) và nằm trong HCP Terraform.
- Mã nguồn sử dụng sâu các tính năng chỉ có ở HCP: chính sách Sentinel gắn vào workspace, run trigger, thông tin xác thực provider động do HCP quản lý. Terraform Stacks là tính năng chỉ có ở HCP và không có tương đương trong OpenTofu, nằm ngoài phạm vi bài viết này.
- Một khung kiểm toán hoặc tuân thủ của doanh nghiệp nêu đích danh "Terraform" là công cụ IaC chính thức, đây là vấn đề về mua sắm và tài liệu bên cạnh vấn đề kỹ thuật.
- Một thư viện module lớn có các ràng buộc phiên bản nội bộ được phân giải dựa trên hành vi registry đặc thù của Terraform.
Không phải đội ngũ nào cũng nên di chuyển. Bài toán chi phí - lợi ích chỉ thực sự có ý nghĩa khi các hạn chế của BSL ảnh hưởng thực sự đến trường hợp sử dụng của bạn, khi một tính năng cụ thể của OpenTofu mở khóa điều gì đó thiết thực, hoặc khi lộ trình do IBM kiểm soát là mối lo thực sự với tổ chức của bạn. Nếu không rơi vào các trường hợp đó, việc tiếp tục dùng Terraform là một lựa chọn hoàn toàn hợp lý.
Bạn có nên chuyển đổi không?
Không có một câu trả lời đúng duy nhất ở đây. Khi tôi vẽ cây quyết định cho một đội ngũ, bốn tình huống phổ biến thường xuất hiện, và bước đi đúng đắn phụ thuộc vào việc bạn đang ở tình huống nào.
Áp dụng IaC mới (dự án greenfield). Hãy bắt đầu với OpenTofu. Giấy phép là MPL 2.0, việc quản trị nằm dưới Linux Foundation và CNCF, và dự án có nhịp độ phát hành tích cực. Các điểm khác biệt của nó bao gồm mã hóa state phía client, provider for_each, enabled, và prevent_destroy. Bạn không cần phải tính toán vòng quanh những vướng mắc từ BSL. Đây là khuyến nghị mạnh mẽ nhất trong bài viết này.
Người dùng Terraform hiện tại, dự án quy mô nhỏ đến trung bình. Hãy chuyển đổi nếu một trong ba yếu tố kích hoạt sau xảy ra. Một: bạn đang bán hoặc có thể bán một sản phẩm có nguy cơ chạm vào điều khoản loại trừ "cạnh tranh với HashiCorp" của BSL; bài toán pháp lý rõ ràng hơn với MPL 2.0. Hai: bạn cần mã hóa state phía client, provider for_each, enabled, hoặc prevent_destroy và giải pháp lách của Terraform không còn đáng để duy trì nữa. Ba: bạn ưu tiên mô hình quản trị đa bên hơn là lộ trình do một nhà cung cấp duy nhất kiểm soát. Nếu không rơi vào trường hợp nào và Terraform vẫn chạy ổn định, hãy cứ ở lại. Việc di chuyển có thể đảo ngược ở nhiều hệ thống, nhưng không miễn phí.
Người dùng HCP Terraform ở mức độ nặng. Hãy coi đây là một quyết định ở tầm nền tảng, không tự động coi là một cuộc di chuyển backend. OpenTofu có thể dùng các backend từ xa tương thích, nhưng việc thực thi từ xa đặc thù của HCP, Sentinel, run trigger, thông tin xác thực động, và Stacks vẫn cần được đánh giá theo từng tính năng. Nếu các cơ chế kiểm soát đó là trọng tâm, hãy thử nghiệm trước. Nếu bạn rời khỏi HCP vì lý do giấy phép, chi phí, hoặc quản trị, hãy lên kế hoạch công việc này như một cuộc di chuyển nền tảng.
Đang cân nhắc Pulumi hoặc một giải pháp thay thế không dùng HCL. OpenTofu là con đường gần nhất nếu bạn muốn giữ lại HCL và phần lớn quy trình hiện có. Pulumi là một nền tảng và lựa chọn ngôn ngữ rộng hơn: TypeScript, Python, Go, hoặc .NET để điều khiển các API đám mây. Việc chuyển sang đó có thể đòi hỏi chuyển đổi hoặc viết lại, vì vậy hãy đánh giá nó tách biệt khỏi việc chỉ đơn thuần đổi tệp nhị phân từ Terraform sang OpenTofu.
Còn một điều nữa đáng được nói thẳng: lời phê bình chính đáng rằng OpenTofu phần nào là một biện pháp phòng ngừa rủi ro của các nhà cung cấp SaaS. Một luồng thảo luận trên Hacker News về thay đổi BSL đã nêu lên lo ngại rằng các thành viên sáng lập của dự án là những nền tảng thương mại dựa trên Terraform, với động cơ riêng về sự linh hoạt trong giấy phép. Tôi coi trọng mối lo ngại đó. Yếu tố giảm nhẹ ở đây là cấu trúc quản trị, việc được Linux Foundation lưu trữ, tư cách CNCF Sandbox, và MPL 2.0 trên mọi tệp, khiến việc thay đổi giấy phép trong tương lai khó khăn hơn đáng kể so với việc một nhà cung cấp duy nhất từng làm. Điều đó không khiến việc này trở nên bất khả thi. Nhưng nó khiến chi phí đủ cao để trở thành một cơ chế kiểm soát thực sự.
Kết luận nhanh. Đối với công việc IaC mới vào năm 2026, hãy bắt đầu với OpenTofu. Giấy phép, cơ chế quản trị, quá trình phát triển tích cực, và tập tính năng của nó khiến nó trở thành lựa chọn mặc định vững chắc. Đối với các hệ thống Terraform đang triển khai, hãy chuyển đổi khi một trong ba yếu tố kích hoạt ở trên xảy ra; nếu không, lợi ích so với chi phí khá mỏng và việc tiếp tục ở lại cũng ổn.
Khi việc lựa chọn công cụ đã rõ ràng, câu hỏi thực tế tiếp theo là nên chạy OpenTofu ở đâu. Quyết định đó ảnh hưởng đến cách xử lý bí mật (secrets), chi phí, khả năng lặp lại, và mức độ kiểm soát mà đội ngũ của bạn có đối với môi trường thực thi.
Tự vận hành OpenTofu
OpenTofu là một tệp nhị phân CLI. Nơi bạn chạy nó quyết định rất nhiều đến chi phí, bảo mật, và những gì bạn có thể làm với nó. Có khoảng ba nơi hợp lý để đặt nó.
Laptop hoặc máy phát triển. Phù hợp cho các plan chạy một lần, làm prototype, và các dự án cá nhân nhỏ. Đây là lựa chọn mặc định kém cho các quy trình sản xuất dùng chung, trừ khi state từ xa, cơ chế khóa, và kỷ luật rà soát đã được áp dụng chặt chẽ. Các đội ngũ thường được lợi hơn khi có một môi trường thực thi chuẩn hóa, thay vì phụ thuộc vào chiếc laptop nào đó vừa chạy tofu apply.
CI runner được quản lý (GitHub Actions, GitLab CI, v.v.). Con đường phổ biến. opentofu/setup-opentofu action này có thể thay thế trực tiếp cho hashicorp/setup-terraform. Cách này hoạt động tốt cho hầu hết các đội ngũ và dự án. Đánh đổi: bí mật (secrets) phải đi qua một dịch vụ CI của bên thứ ba, số phút miễn phí có thể cạn khi thực hiện các thao tác state lớn, và môi trường runner mang tính tạm thời, điều này thường là một ưu điểm nhưng đôi khi lại là hạn chế. Xem GitHub vs GitLab nếu bạn vẫn đang phân vân giữa các lựa chọn CI được lưu trữ, và Best CI/CD Tools để có cái nhìn tổng quan hơn.
Runner tự lưu trữ trên VPS. Hữu ích khi những đánh đổi của CI được quản lý không còn phù hợp nữa: bí mật cần tránh xa dịch vụ bên thứ ba, số phút CI trở nên tốn kém, hoặc bạn muốn có bộ nhớ đệm provider lâu dài. Việc thiết lập khá đơn giản: một VPS Linux, tệp nhị phân OpenTofu, một agent GitHub Actions hoặc GitLab Runner, và Docker để cách ly job. Xem Install Docker on VPS nếu phần đó còn mới với bạn. Với một runner cho đội ngũ nhỏ, 4 GB RAM, 2 vCPU, và 60 GB NVMe là điểm khởi đầu hợp lý; hãy mở rộng CPU, bộ nhớ, và dung lượng lưu trữ khi cần plan lớn hơn và mức độ đồng thời cao hơn.
Với những đội ngũ cần kiểm soát chặt chẽ hơn đối với bí mật của runner, bộ nhớ đệm provider lâu dài, hoặc chi phí CI có thể dự đoán được, một runner tự lưu trữ trên VPS có thể là lựa chọn hợp lý. Trong thiết lập đó, hãy ưu tiên quyền truy cập root, bộ lưu trữ NVMe tốc độ cao, khả năng thay đổi quy mô dễ dàng, và đủ CPU/RAM cho các thao tác plan lớn hơn.
Cloudzy Linux VPS các instance phù hợp với mô hình runner tự lưu trữ đó nhờ quyền truy cập root, bộ lưu trữ NVMe, và khả năng thay đổi quy mô linh hoạt, nhờ đó bạn có thể bắt đầu từ quy mô nhỏ rồi mở rộng runner khi khối lượng công việc OpenTofu của bạn tăng lên.
Câu hỏi thường gặp
OpenTofu Có Giống Terraform Không?
Không hẳn vậy. OpenTofu bắt đầu như một bản phân nhánh của Terraform 1.5.x và vẫn tương thích rộng rãi về cấu hình với HCL kiểu Terraform: cùng những tệp .tf , provider, và cùng quy trình plan/apply plan/apply cho nhiều dự án. Chúng khác nhau ở giấy phép và các tính năng được thêm vào sau khi phân nhánh. OpenTofu có mã hóa state phía client, provider for_each, enabled, và prevent_destroy; còn Terraform có những tính năng riêng được thêm sau khi phân nhánh, bao gồm ephemeral resources.
OpenTofu Có Hỗ Trợ Tất Cả Provider Terraform Của Tôi Không?
Đối với các provider lớn như AWS, GCP, Azure, Kubernetes, và Helm, nhìn chung là có. OpenTofu Registry báo cáo có hơn 3.900 provider tính đến tháng 7 năm 2026. tofu init có thể cập nhật .terraform.lock.hcl metadata. Với các provider ngách, đặc thù theo nhà cung cấp, hoặc mới được phát hành, hãy xác minh trực tiếp tính khả dụng và mức hỗ trợ phiên bản trước khi chuyển đổi.
Liệu Bản Thân OpenTofu Có Thể Bị Thay Đổi Giấy Phép Trong Tương Lai Không?
Việc thay đổi giấy phép trong tương lai khó khăn hơn so với những gì đã xảy ra với Terraform, nhưng không phải là bất khả thi. OpenTofu dùng MPL 2.0, được Linux Foundation lưu trữ, và là dự án Sandbox của CNCF kể từ ngày 23 tháng 4 năm 2025. Cơ chế quản trị mang tính đa bên và giấy phép được OSI phê duyệt. Việc một người sáng lập đơn phương thay đổi giấy phép sẽ xung đột với cả điều lệ của tổ chức lẫn các đóng góp MPL 2.0 hiện có, vốn sẽ cần phải bị loại bỏ hoặc viết lại. Mối lo ngại này là chính đáng; các rào cản mang tính cấu trúc là có thật.
Việc IBM Mua Lại HashiCorp Có Ý Nghĩa Gì Với Tương Lai Của Terraform?
IBM đã hoàn tất việc mua lại HashiCorp vào ngày 27 tháng 2 năm 2025 với giá 6,4 tỷ đô la. Lộ trình phát triển của Terraform giờ đây nằm trong một nhà cung cấp doanh nghiệp lớn hơn. Bản thân thương vụ mua lại không chứng minh được hướng đi tương lai về giấy phép hay sản phẩm; hãy đánh giá dựa trên ghi chú phát hành hiện tại, hướng dẫn về giấy phép, và các thay đổi sản phẩm HCP, thay vì coi quyền sở hữu như một lời tiên đoán.
OpenTofu Đã Sẵn Sàng Cho Môi Trường Production Vào Năm 2026 Chưa?
Có. v1.12.5 là bản phát hành bảo trì hiện tại, dự án nằm trong CNCF Sandbox, và Fidelity đã mô tả việc áp dụng vào môi trường production trên một hệ thống IaC với hơn 50.000 tệp state và bốn triệu resource. Sẵn sàng cho production không có nghĩa là giống hệt về tính năng: những đội ngũ phụ thuộc vào các khả năng chỉ có ở HCP, như Terraform Stacks, vẫn cần một quyết định riêng về khả năng tương thích.
