Terraform чи OpenTofu у 2026 році: ліцензія, можливості і як мігрувати

Роками Terraform був безальтернативним вибором для інфраструктури як коду. У серпні 2023 року HashiCorp перевела його з open-source ліцензії MPL на Business Source License, спільнота створила форк OpenTofu, а у 2025 році IBM завершила купівлю HashiCorp. Через три роки команди, що починають новий проєкт чи продовжують enterprise-контракт, ставлять те саме запитання: Terraform чи OpenTofu? У гайді простими словами пояснюємо ліцензування, порівнюємо інструменти станом на 2026 рік і описуємо, як ми мігруємо наявні кодові бази Terraform.

Що сталося, коротко

Серпень 2023: HashiCorp оголосила, що майбутні релізи Terraform (з 1.6) виходитимуть під Business Source License 1.1 замість MPL 2.0.
Вересень 2023 – січень 2024: ініціатива OpenTF зробила форк останньої версії під MPL, проєкт увійшов до Linux Foundation як OpenTofu, а OpenTofu 1.6.0 став загальнодоступним у січні 2024 року (маніфест OpenTofu; OpenTofu is going GA).
27 лютого 2025: IBM завершила купівлю HashiCorp (IBM, 2025).
Квітень 2025: OpenTofu прийняли до Cloud Native Computing Foundation як sandbox-проєкт (CNCF: OpenTofu).

Що означає BSL для вас

Business Source License — це source-available, а не open source. Якщо коротко, вона дозволяє широке використання, зокрема в продакшені всередині компанії, але обмежує пропонування продуктів чи хостингових сервісів, що конкурують із комерційними пропозиціями HashiCorp. Для більшості компаній, що керують через Terraform власною інфраструктурою, щоденне використання не змінилося.

Де це має значення:

Вендори й платформи, що вбудовують чи хостять Terraform у межах комерційної пропозиції.
Компанії із суворими політиками open source, що вимагають ліцензій, схвалених OSI, для ключових інструментів.
Довгострокова оцінка ризиків: власник ліцензії може змінити умови для майбутніх версій; у open-source проєкту під керуванням фонду цей ризик нижчий.

Якщо ви в «сірій зоні», прочитайте ліцензію і FAQ HashiCorp разом із юристами (HashiCorp licensing FAQ).

Сумісність у 2026 році

OpenTofu починався як пряма заміна Terraform 1.5/1.6, і в основі обидва інструменти досі мають спільну мову HCL, протокол провайдерів і формат стану. Більшість провайдерів працюють з обома, а реєстр OpenTofu віддзеркалює екосистему провайдерів і модулів. З часом можливості розійшлися, тож «пряма заміна» тепер залежить від того, які новіші функції ви використовуєте з кожного боку.

Порівняння можливостей

Область	Terraform	OpenTofu
Ліцензія	BSL 1.1 (source-available)	MPL 2.0 (open source), Linux Foundation / CNCF
Управління	HashiCorp, компанія IBM	Спільнота, кілька вендорів
Шифрування стану	Покладається на бекенд (наприклад, шифрований S3)	Вбудоване клієнтське шифрування стану і планів з 1.7
Реєстри	Terraform Registry, приватний реєстр HCP Terraform	OpenTofu Registry плюс OCI-реєстри для провайдерів і модулів з 1.10
Блокування в S3-бекенді	DynamoDB або нативне блокування S3 у новіших версіях	Нативне блокування S3 з 1.10
Керована платформа	HCP Terraform, Terraform Enterprise	Сторонні платформи (Spacelift, env0, Scalr та інші) або власний CI
Мовні можливості	Stacks, специфічні для Terraform функції	Рання обробка змінних, `for_each` для провайдерів, `-exclude`, позначки застарілості

OpenTofu 1.10, що вийшов у червні 2025 року, додав підтримку OCI-реєстрів для ізольованих середовищ, нативне блокування стану в S3, зовнішні постачальники ключів для шифрування стану, позначки застарілості для змінних і виходів модулів та трейсинг через OpenTelemetry (OpenTofu 1.10). Релізи тривали і у 2026 році: версія 1.12 вийшла в травні (релізи OpenTofu).

Шифрування стану заслуговує на окрему увагу

Стан Terraform часто містить секрети: паролі баз даних, приватні ключі, рядки підключення. OpenTofu може шифрувати файли стану й планів на клієнті до того, як вони потраплять у бекенд, ключами з парольних фраз чи сервісів керування ключами (OpenTofu: шифрування стану):

terraform {
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:eu-central-1:123456789012:key/abcd-..."
      region     = "eu-central-1"
      key_spec   = "AES_256"
    }
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.main
    }
    state {
      method = method.aes_gcm.default
    }
    plan {
      method = method.aes_gcm.default
    }
  }
}

Як обрати

Обирайте OpenTofu, коли:

Вам потрібен open-source інструмент під керуванням фонду для довготривалої платформи.
Важливі шифрування стану, OCI-реєстри чи робота в ізольованих середовищах.
Ви запускаєте IaC із власного CI чи сторонньої платформи, а не з HCP Terraform.
Ви будуєте продукт чи сервіс навколо автоматизації інфраструктури.

Залишайтеся на Terraform, коли:

Ви покладаєтеся на можливості й контракти підтримки HCP Terraform чи Terraform Enterprise.
Ваша організація стандартизована на інструментах HashiCorp, а BSL прийнятна для юристів.
Ви використовуєте функції, що є лише в Terraform і не мають аналогів в OpenTofu.

Для власних клієнтських платформ — як-от кластерів Hetzner зі статті Kubernetes на Hetzner — ми за замовчуванням обираємо OpenTofu.

Міграція з Terraform на OpenTofu

OpenTofu публікує гайди з міграції для кожної версії Terraform (OpenTofu: migration). Наш процес:

Інвентаризація версій Terraform, провайдерів, бекендів і специфічних для Terraform функцій, що використовуються.
Бекап стану для кожного workspace.
Встановлення OpenTofu в CI поруч із Terraform; фіксація версії.
tofu init і tofu plan для кожного workspace. Мета — план без змін.
Переведення одного малоризикового workspace на tofu apply, потім решти — пакетами.
Оновлення CI-пайплайнів, pre-commit хуків і документації; видалення бінарників Terraform.
Функції, що є лише в OpenTofu, як-от шифрування стану, — лише після завершення переходу: вони ускладнюють повернення назад.

# для кожного workspace
cp terraform.tfstate terraform.tfstate.backup     # або снапшот віддаленого бекенду
tofu init -upgrade
tofu plan -out=tofu.plan                           # очікуємо: No changes.

Ставтеся до IaC-пайплайна як до частини ланцюга постачання ПЗ: фіксуйте версії провайдерів, перевіряйте контрольні суми й переглядайте плани в pull request'ах, як описано у статтях CI/CD без болю і Безпека контейнерів і ланцюга постачання.

Запуск OpenTofu в CI

Мінімальна джоба GitHub Actions, що будує план у pull request'ах і застосовує зміни з main, а план переглядається в PR:

jobs:
  plan:
    runs-on: ubuntu-latest
    permissions: { contents: read, id-token: write, pull-requests: write }
    steps:
      - uses: actions/checkout@<pinned-sha>
      - uses: opentofu/setup-opentofu@<pinned-sha>
        with: { tofu_version: 1.12.x }
      - run: tofu init -input=false
      - run: tofu plan -input=false -out=plan.bin
      - run: tofu show -no-color plan.bin > plan.txt   # додаємо до PR для рев'ю

Використовуйте OIDC для отримання короткоживучих хмарних облікових даних замість збереження ключів доступу, а джобу apply тримайте за захищеним середовищем з обов'язковими рев'юерами.

Помилки, які ми бачимо під час міграцій

Переведення всіх workspace одночасно. Мігруйте пакетами, щоб проблема з провайдером чи бекендом зачепила одну команду, а не всі.
Незафіксовані версії. CI і розробники мають запускати ті самі зафіксовані версії OpenTofu і провайдерів; змішані версії дають «шумні» плани.
Забутий lock-файл. Комітьте .terraform.lock.hcl, щоб контрольні суми провайдерів перевірялися на кожному запуску.
Увімкнення шифрування стану посеред міграції. Робіть це після того, як усі перейшли, з ключами в KMS і задокументованою процедурою відновлення.
Бінарники Terraform у CI-образах. Рано чи пізно хтось виконає terraform apply над уже мігрованим станом.

FAQ

Чи можна й далі безкоштовно використовувати Terraform? Для керування власною інфраструктурою BSL дозволяє безкоштовне використання. Обмеження стосуються пропонування конкурентних продуктів чи сервісів.

Чи може OpenTofu використовувати провайдери й модулі Terraform? Загалом так: вони мають спільний протокол провайдерів, а реєстр OpenTofu обслуговує спільну екосистему.

Чи можна повернутися назад після міграції? Так, якщо ви ще не почали використовувати функції лише OpenTofu, як-от шифрований стан. Плануйте перехід до їх впровадження.

Чи розходитимуться інструменти й далі? Ймовірно. Оберіть один інструмент на організацію і стандартизуйтеся, а не змішуйте обидва в одній кодовій базі.

Джерела

OpenTofu. Маніфест, анонс GA, OpenTofu 1.10, релізи.
OpenTofu. State and plan encryption і гайди з міграції.
CNCF. Проєкт OpenTofu.
IBM (2025). IBM completes acquisition of HashiCorp.
HashiCorp. Licensing FAQ.

Terraform чи OpenTofu у 2026 році: ліцензія, можливості і як мігрувати

Що сталося, коротко

Що означає BSL для вас

Сумісність у 2026 році

Порівняння можливостей

Шифрування стану заслуговує на окрему увагу

Як обрати

Міграція з Terraform на OpenTofu

Запуск OpenTofu в CI

Помилки, які ми бачимо під час міграцій

FAQ

Джерела

Маєте подібний виклик у вашій компанії?

Може зацікавити

Kubernetes на Hetzner: дешевше за AWS у 5 разів — міф чи реальність

CI/CD без болю: GitHub Actions для команди до 20 розробників

Безпека контейнерів і ланцюга постачання ПЗ: SBOM, підписи і SLSA на практиці