Відкрийте сьогодні модуль Terraform, і ви зіткнетеся з питанням, якого не існувало три роки тому: це бінарник, що запускає цей код, terraform, чи, можливо, tofu? Компанія IBM завершила придбання HashiCorp 27 лютого 2025 року за 6,4 мільярда доларів, а OpenTofu став sandbox-проєктом CNCF 23 квітня 2025 року, і шлях міграції між цими двома інструментами офіційно задокументовано. Це рішення більше не є гіпотетичним.
Ця стаття написана з погляду інфраструктурних операцій, а не з погляду керованої платформи Terraform. Мета полягає в тому, щоб відокремити реальні витрати на міграцію від шуму навколо ліцензування та управління проєктом. Це означає, що я можу відверто говорити про те, що ламається під час міграції, про обґрунтовані питання управління та про випадки, коли залишитися на Terraform - правильне рішення.
Ця стаття охоплює чотири теми: що таке OpenTofu у 2026 році, які функції відсутні в Terraform, як виглядає міграція на практиці, і чітку рекомендацію для типових сценаріїв прийняття рішень.
Коротко
- OpenTofu - це відкритий форк Terraform під ліцензією MPL 2.0, який розміщує Linux Foundation, і sandbox-проєкт CNCF з 23 квітня 2025 року. Він відгалузився від Terraform 1.5.x після того, як HashiCorp у серпні 2023 року перевів Terraform на Business Source License.
- Станом на 26 липня 2026 року поточним підтримуваним випуском є v1.12.5; репозиторій на GitHub має понад 29 000 зірок, а сайт проєкту OpenTofu перелічує понад 3900 провайдерів і понад 23 600 модулів.
- Він пропонує можливості, доступні лише в OpenTofu, або ті, у яких OpenTofu лідирує, а Terraform наразі не має аналога в такому ж вигляді: шифрування стану та плану на стороні клієнта, provider
for_each, раннім обчисленням змінних,enabledмета-аргументом та динамічнимprevent_destroy. Ephemeral resources не є унікальними лише для OpenTofu; Terraform підтримує їх з версії 1.10. - Для невеликого проєкту на Terraform 1.5.x з локальним станом або станом у S3 простий шлях може бути короткою, оборотною міграцією. Обсяг роботи зростає через посилання в CI/CD, специфічні для HCP робочі процеси та зміни у файлах блокування залежностей.
- Для нового IaC-проєкту в 2026 році починайте з OpenTofu. Для наявного розгортання Terraform переходьте, коли BSL починає заважати, коли вам потрібна функція, яка є в OpenTofu, але відсутня в Terraform, або коли реальним занепокоєнням є дорожня карта під контролем IBM. В інших випадках співвідношення вигоди й витрат незначне.
Що таке OpenTofu у 2026 році
OpenTofu - це відкритий форк Terraform, який розміщує Linux Foundation, прийнятий до CNCF як sandbox-проєкт 23 квітня 2025 року та ліцензований за Mozilla Public License 2.0. Бінарний файл називається tofu. Мова конфігурації - HCL, той самий HCL, який використовує Terraform. Для більшості простих і середньої складності проєктів наявна кодова база Terraform працює в OpenTofu без змін.
Форк виник у серпні 2023 року після того, як HashiCorp перевів Terraform з MPL 2.0 на Business Source License 1.1 10 серпня 2023 року. BSL - це ліцензія source-available, а не схвалена OSI, і вона обмежує промислове використання, яке "конкурує з комерційними пропозиціями HashiCorp". Протягом п'яти днів був опублікований OpenTF Manifesto і оголошено про форк. Оголошення Linux Foundation офіційно представило OpenTofu 20 вересня 2023 року.
Оголошення Linux Foundation назвало Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver і Terramate серед засновників-прихильників, з щонайменше 18 інженерами, зобов'язаними працювати повний робочий день щонайменше п'ять років. OpenTofu відгалузився від Terraform 1.5.x, останньої гілки під MPL 2.0.
Де проєкт перебуває сьогодні: v1.12.5 - це поточний підтримуваний випуск, а офіційний сайт перелічує понад 3900 провайдерів і понад 23 600 модулів. Сигнали про впровадження вже не обмежуються лише імпульсом протестного форку: кейс-стаді про міграцію Fidelity описує програму, що охоплює понад 50 000 файлів стану та чотири мільйони ресурсів.
Важливий бізнес-контекст: IBM завершила придбання HashiCorp 27 лютого 2025 року за 6,4 мільярда доларів. Дорожню карту Terraform тепер визначає значно більший корпоративний постачальник. Це не є автоматично добре чи погано для користувачів, але це частина розрахунку, який команди роблять у 2026 році.
Чим OpenTofu відрізняється від Terraform
Після форку обидва проєкти пішли різними шляхами розвитку функцій. Таблиця нижче - це коротка версія; примітки, що йдуть далі, пояснюють, що кожна відмінність означає для практиків.
| Функція | OpenTofu | Terraform | З версії |
|---|---|---|---|
| Шифрування стану на стороні клієнта | Нативно (PBKDF2, AWS KMS, GCP KMS, OpenBao) | Керується бекендом у стані спокою | v1.7 (квітень 2024) |
| Раннє обчислення змінних | Так | Не підтримується | v1.8 |
Поставщик for_each | Так | Немає нативного еквівалента | v1.9 |
| Ephemeral resources | Так | Так, з Terraform 1.10 | OpenTofu v1.11 / Terraform v1.10 |
enabled мета-аргументом | Так | Не підтримується | v1.11 (грудень 2025) |
Динамічний prevent_destroy | Так | Лише статичне | v1.12 (травень 2026) |
| Ліцензія | MPL 2.0 (схвалена OSI) | BSL 1.1 (не схвалена OSI) | Н/Д |
На стороні клієнта шифрування стану (v1.7.0, 30 квітня 2024). OpenTofu може шифрувати файли стану та плану прямо в інструменті за допомогою PBKDF2, AWS KMS, GCP KMS або OpenBao. Terraform зазвичай делегує шифрування в стані спокою вибраному бекенду, тоді як локальний стан залишається у відкритому вигляді. Шифрування на стороні клієнта в OpenTofu може захистити викрадений об'єкт стану або кешований план, за умови що ключ дешифрування не розкрито разом з ним. Воно не замінює TLS, контроль доступу до бекенду чи дисципліну управління секретами.
Конфігурація виглядає приблизно так:
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). Ви можете ітерувати конфігурації provider так само, як ітеруєте ресурси. Для налаштувань з кількома регіонами чи обліковими записами це усуває давній клас обхідних рішень. Вам більше не потрібно вручну прописувати по одному провайдеру з псевдонімом на регіон; один блок можна керувати з карти (map).
Раннє обчислення змінних (v1.8). Змінні тепер можна використовувати в місцях, які раніше були обмежені, зокрема в аргументах бекенду та джерела модуля. Це корисно, коли один кореневий модуль керує кількома середовищами, що відрізняються невеликим набором змінних.
Ephemeral resources і enabled мета-аргумент (v1.11.0, 9 грудня 2025). OpenTofu 1.11 додав ephemeral resources та enabled мета-аргумент. Ephemeral resources існують лише в межах одного циклу plan/apply і не зберігаються у стані, що корисно для короткострокових облікових даних. Вони не є унікальними лише для OpenTofu: Terraform запровадив їх у версії 1.10 і додав write-only аргументи у версії 1.11. Специфічна для OpenTofu можливість тут - enabled, який перемикає блок ресурсу за виразом без умовної count гімнастики.
Динамічний prevent_destroy (v1.12). Налаштування prevent_destroy prevent_destroy у Terraform приймає лише буквальні значення. OpenTofu 1.12 дозволяє його обчислювати, тож один модуль може залишати staging таким, що можна видалити, водночас захищаючи продакшн.
Рядок про ліцензію - це структурна відмінність, яка не проявляється як функція. MPL 2.0 схвалена OSI і є copyleft на рівні файлу. Ліцензія Terraform BSL 1.1 - source-available, містить додаткове обмеження використання і змінюється на MPL 2.0 через чотири роки після публікації кожної ліцензованої роботи. Для більшості команд практичний ефект незначний; для постачальників, які створюють щось близьке до комерційних пропозицій HashiCorp, це і є причина існування форку.
Міграція: що насправді ламається
Офіційний посібник з міграції навмисно короткий і оборотний: створіть резервну копію стану та коду, встановіть 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 plantofu plan має відповідати плану, який створив Terraform. Якщо є несподівана різниця, перевірте версії провайдерів, налаштування бекенду та будь-які функції Terraform новіші за 1.5.x, перш ніж застосовувати.
Перш ніж щось запускати, важливі два нюанси. По-перше, OpenTofu загалом сумісний за конфігурацією з HCL у стилі Terraform для випадків, описаних у цьому посібнику, але функції, додані після Terraform 1.5.x, все ще потребують перевірки на сумісність. По-друге, tofu init -upgrade може оновити .terraform.lock.hcl, включно з адресами джерел провайдерів і записами контрольних сум. Ці метадані оцінюйте окремо від дрейфу інфраструктури.
Реальні перешкоди
Три речі можуть перетворити швидку CLI-міграцію на масштабніший платформний проєкт. Жодна з них не є багом.
Робочі простори HCP Terraform. OpenTofu включає хмарні та remote-інтеграції для сумісних remote-сервісів, включно з HCP Terraform у сценаріях локального виконання та зберігання стану. Складнішою частиною є специфічне для HCP remote-виконання та функції платформи: Sentinel, run triggers, динамічні облікові дані, Stacks та будь-яка поведінка сервісу, яку OpenTofu не може повністю протестувати чи підтримати. Якщо це критично важливо, спочатку випробуйте один робочий простір; якщо ви залишаєте HCP, перенесіть стан і відтворіть ці елементи керування платформою.
Порада: Відмова від HCP Terraform може стати найбільшою прихованою вартістю, якщо інфраструктура покладається на специфічні для HCP робочі процеси. Перш ніж вирішувати, запустіть terraform state pull > state.json і перевірте розмір та кількість ресурсів. Один робочий простір із 200 ресурсами - це інший проєкт, ніж флот із 50 робочих просторів із run triggers та наборами політик. Друге - це платформна інженерна міграція, а не заміна інструменту.
CI/CD-пайплайни, жорстко прив'язані до terraform. Кожне посилання на 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Це тривіальний випадок: один workflow, один репозиторій. У монорепозиторії зі спільними composite-екшенами, кількома пайплайнами та бібліотекою багаторазових workflow область перевірки ширша. Робота механічна, але може зайняти більше часу, ніж заміна CLI.
Перевірка файлу блокування залежностей. tofu init може оновити .terraform.lock.hcl, включно з адресами джерел провайдерів і записами контрольних сум. OpenTofu 1.12 також може додавати повні h1: набори контрольних сум для всіх платформ. Розглядайте цей diff як метадані залежностей, які потрібно перевірити та закомітити окремо, а не як дрейф інфраструктури.
Порада: Diff файлу блокування може виглядати заплутано під час першого коміту. Запустіть tofu init -upgrade на чистій гілці, закомітьте лише lock-файл із зрозумілим повідомленням на кшталт «review OpenTofu lock-file changes», а потім перебазуйте роботу над функціоналом поверх нього. Змішування метаданих залежностей із PR функціоналу ускладнює перевірку обох змін.
Опір зацікавлених сторін. "Тепер ми працюємо на форку" звучить по-різному в різних організаціях. Чесна відповідь полягає в тому, що OpenTofu для випадків, описаних у цьому посібнику, залишається загалом сумісним за конфігурацією з HCL у стилі Terraform, тож заміна зазвичай оборотна. Якби OpenTofu зникло завтра, багато команд могли б перевстановити Terraform, перевірити lock-файл і продовжити використовувати ті самі .tf файли. Спочатку перевірте функції, додані після форку; це застереження звучить правдоподібніше, ніж обіцянка ідеальної взаємозамінності.
Коли міграція справді складна
Цей простий шлях підходить не для кожної інфраструктури Terraform.
Міграція суттєво ускладнюється, коли:
- Стан великий (тисячі ресурсів, десятки робочих просторів) і зберігається в HCP Terraform.
- Кодова база глибоко використовує функції, доступні лише в HCP: політики Sentinel, вбудовані в робочі простори, run triggers, динамічні облікові дані провайдерів, керовані HCP. Terraform Stacks доступний лише в HCP і не має еквівалента в OpenTofu, що виходить за межі цієї статті.
- Корпоративний аудит або комплаєнс-фреймворк називає "Terraform" офіційним IaC-інструментом, що є проблемою закупівель і документації на додачу до технічної.
- Велика бібліотека модулів має внутрішні обмеження версій, які вирішувалися відповідно до специфічної для Terraform поведінки реєстру.
Не кожній команді варто мігрувати. Співвідношення вигоди й витрат має сенс лише тоді, коли обмеження BSL справді впливають на ваш сценарій використання, коли конкретна функція OpenTofu розблоковує щось реальне, або коли дорожня карта під контролем IBM є справжнім занепокоєнням для вашої організації. Якщо жодне з цього не стосується вас, залишитися на Terraform - цілком виправдане рішення.
Чи варто переходити?
Тут немає єдиної правильної відповіді. Коли я малюю дерево рішень для команди, з'являються чотири типові сценарії, і правильний крок залежить від того, в якому з них ви перебуваєте.
Нове впровадження IaC (з нуля). Починайте з OpenTofu. Ліцензія - MPL 2.0, управління підпорядковане Linux Foundation і CNCF, а проєкт має активний темп випусків. Серед його відмінних рис - шифрування стану на стороні клієнта, provider for_each, enabledта динамічним prevent_destroy. Не потрібно планувати навколо тертя з BSL. Це найсильніша рекомендація в цій статті.
Наявний користувач Terraform, невеликий або середній проєкт. Переходьте, якщо спрацьовує будь-який із трьох тригерів. Перше: ви продаєте або можете продавати продукт, який може зачепити виняток BSL "конкурує з HashiCorp"; юридичний розрахунок чистіший на MPL 2.0. Друге: вам потрібне шифрування стану на стороні клієнта, provider for_each, enabled, або динамічний prevent_destroy а обхідне рішення в Terraform уже не варте підтримки. Третє: ви віддаєте перевагу багатосторонньому управлінню перед дорожньою картою одного постачальника. Якщо жодне з цього не стосується вас і Terraform працює без проблем, залишайтеся. Міграція оборотна в багатьох випадках, але не безкоштовна.
Активний користувач HCP Terraform. Розглядайте це як платформне рішення, а не автоматично як міграцію бекенду. OpenTofu може використовувати сумісні remote-бекенди, але специфічне для HCP remote-виконання, Sentinel, run triggers, динамічні облікові дані та Stacks все ще потребують оцінки функція за функцією. Якщо ці елементи керування критично важливі, спочатку випробуйте. Якщо ви залишаєте HCP з причин ліцензування, вартості чи управління, плануйте роботу як платформну міграцію.
Розглядаєте Pulumi чи іншу альтернативу без HCL. OpenTofu - найближчий шлях, якщо ви хочете зберегти HCL і більшість наявних робочих процесів. Pulumi - це ширша платформа і вибір мови: TypeScript, Python, Go або .NET, що керують хмарними API. Перехід туди може передбачати конвертацію чи переписування, тож оцінюйте це окремо від простої заміни бінарного файлу Terraform на OpenTofu.
Ще одна річ, яку варто розглянути прямо: обґрунтована критика того, що OpenTofu частково є страховкою для SaaS-постачальників. Тема на Hacker News про зміну BSL підняла занепокоєння, що фундатори проєкту - це комерційні платформи на базі Terraform із власною мотивацією щодо гнучкості ліцензування. Я сприймаю це занепокоєння серйозно. Пом'якшувальним фактором є структура управління, розміщення в Linux Foundation, CNCF Sandbox, MPL 2.0 в кожному файлі, що робить майбутню зміну ліцензії значно складнішою, ніж була зміна ліцензії одним постачальником. Це не робить її неможливою. Але робить достатньо витратною, щоб бути реальним стримувальним фактором.
Швидкий вердикт. Для нової роботи з IaC у 2026 році починайте з OpenTofu. Його ліцензія, управління, активна розробка та набір функцій роблять його сильним варіантом за замовчуванням. Для наявних розгортань Terraform переходьте, коли застосовується один із трьох тригерів вище; в іншому випадку співвідношення вигоди й витрат незначне, і залишитися - цілком нормально.
Коли вибір інструменту зрозумілий, наступне практичне питання - де запускати OpenTofu. Це рішення впливає на роботу з секретами, вартість, повторюваність та рівень контролю вашої команди над середовищем виконання.
Самостійний запуск OpenTofu
OpenTofu - це CLI-бінарний файл. Те, де ви його запускаєте, значною мірою визначає вартість, безпеку та те, що ви можете з ним робити. Є приблизно три розумні місця для його розміщення.
Ноутбук або машина розробника. Годиться для одноразових планів, прототипування та невеликих особистих проєктів. Це поганий варіант за замовчуванням для спільних продакшн-процесів, якщо тільки remote-стан, блокування та дисципліна перегляду вже не забезпечені. Командам зазвичай корисне канонічне середовище виконання, а не покладання на те, який ноутбук останнім запускав tofu apply.
Керований CI-раннер (GitHub Actions, GitLab CI тощо). Типовий шлях. opentofu/setup-opentofu дія є прямою заміною для hashicorp/setup-terraform. Це добре працює для більшості команд і проєктів. Компроміси: секрети проходять через сторонній CI-сервіс, безкоштовних хвилин може не вистачити для великих операцій зі станом, а середовище раннера ефемерне, що зазвичай є перевагою, але іноді обмеженням. Дивіться GitHub vs GitLab якщо ви все ще обираєте між хостованими CI-варіантами, а Best CI/CD Tools для ширшого огляду.
Самостійно розміщений раннер на VPS. Корисно, коли компроміси керованого CI перестають працювати: секрети мають залишатися поза стороннім сервісом, хвилини CI стають дорогими, або вам потрібні постійні кеші провайдерів. Налаштування просте: Linux VPS, бінарний файл OpenTofu, агент GitHub Actions чи GitLab Runner та Docker для ізоляції завдань. Дивіться Install Docker on VPS якщо ця частина для вас нова. Для раннера невеликої команди розумною відправною точкою є 4 ГБ RAM, 2 vCPU та 60 ГБ NVMe; масштабуйте CPU, пам'ять і сховище для більших планів і вищої паралельності.
Для команд, яким потрібен жорсткіший контроль над секретами раннера, постійні кеші провайдерів або передбачувані витрати на CI, самостійно розміщений раннер на VPS може мати сенс. У такому налаштуванні надавайте пріоритет root-доступу, швидкому NVMe-сховищу, легкому масштабуванню та достатньому обсягу CPU/RAM для більших операцій планування.
Cloudzy Linux VPS інстанси підходять для цієї моделі самостійно розміщеного раннера завдяки root-доступу, NVMe-сховищу та гнучкому масштабуванню, тож ви можете почати з малого і масштабувати раннер у міру зростання ваших навантажень OpenTofu.
Часті запитання
Чи є OpenTofu тим самим, що й Terraform?
Не зовсім. OpenTofu почався як форк Terraform 1.5.x і залишається загалом сумісним за конфігурацією з HCL у стилі Terraform: ті самі .tf файли, провайдери та plan/apply workflow для багатьох проєктів. Вони відрізняються ліцензією та функціями, доданими після форку. OpenTofu має шифрування стану на стороні клієнта, provider for_each, enabledта динамічним prevent_destroy; Terraform має власні функції, додані після форку, включно з ephemeral resources.
Чи підтримає OpenTofu всі мої провайдери Terraform?
Для основних провайдерів, як-от AWS, GCP, Azure, Kubernetes і Helm, загалом так. OpenTofu Registry повідомляє про понад 3900 провайдерів станом на липень 2026 року. tofu init може оновити .terraform.lock.hcl метадані. Для нішевих, специфічних для постачальника чи щойно опублікованих провайдерів безпосередньо перевіряйте доступність і підтримку версій перед переходом.
Чи може саме OpenTofu колись змінити ліцензію?
Майбутня зміна ліцензії складніша, ніж це було для Terraform, але не неможлива. OpenTofu має ліцензію MPL 2.0, розміщений Linux Foundation і є sandbox-проєктом CNCF з 23 квітня 2025 року. Управління багатостороннє, а ліцензія схвалена OSI. Одностороння зміна ліцензії будь-яким одним засновником суперечила б як статуту фонду, так і наявним внескам під MPL 2.0, які довелося б видалити чи переписати. Занепокоєння обґрунтоване; структурні бар'єри реальні.
Що означає придбання HashiCorp компанією IBM для майбутнього Terraform?
IBM завершила придбання HashiCorp 27 лютого 2025 року за 6,4 мільярда доларів. Дорожня карта Terraform тепер перебуває всередині більшого корпоративного постачальника. Саме лише придбання не доводить майбутнє ліцензування чи напрямок продукту; оцінюйте поточні нотатки про випуски, рекомендації щодо ліцензування та зміни продуктів HCP, а не сприймайте власника як пророцтво.
Чи готовий OpenTofu до продакшену у 2026 році?
Так. v1.12.5 - поточний підтримуваний випуск, проєкт перебуває в CNCF Sandbox, а Fidelity описала промислове впровадження в IaC-інфраструктурі з понад 50 000 файлів стану та чотирма мільйонами ресурсів. Готовність до продакшену не означає ідентичність функцій: командам, які покладаються на можливості, доступні лише в HCP, такі як Terraform Stacks, все ще потрібне окреме рішення щодо сумісності.
