Откройте сегодня модуль Terraform, и перед вами встанет вопрос, которого не существовало три года назад: это бинарник, запускающий данный код, terraform или tofu? IBM завершила приобретение HashiCorp 27 февраля 2025 года за 6,4 млрд долларов, OpenTofu стал проектом CNCF Sandbox 23 апреля 2025 года, а путь миграции между двумя инструментами теперь официально задокументирован. Решение больше не гипотетическое.
Эта статья написана с точки зрения инфраструктурных операций, а не managed-платформы Terraform. Цель — отделить реальные затраты на миграцию от шума вокруг лицензирования и управления проектом. Это значит, что я могу прямо говорить о том, что ломается при миграции, о законных вопросах управления и о случаях, когда правильным решением остаётся Terraform.
В этой статье рассматриваются четыре темы: что такое OpenTofu в 2026 году, какие функции отсутствуют в Terraform, как выглядит миграция на практике, и чёткая рекомендация для типичных сценариев принятия решения.
Кратко
- OpenTofu — это open-source форк Terraform под лицензией MPL 2.0, размещённый Linux Foundation, и проект CNCF Sandbox с 23 апреля 2025 года. Он был создан на основе Terraform 1.5.x после того, как HashiCorp перевела Terraform на Business Source License в августе 2023 года.
- По состоянию на 26 июля 2026 года текущий поддерживаемый релиз — v1.12.5; репозиторий на GitHub набрал более 29 000 звёзд, а официальный сайт проекта OpenTofu перечисляет более 3900 провайдеров и более 23 600 модулей.
- В нём есть возможности, уникальные для OpenTofu или в которых OpenTofu лидирует и которые Terraform пока не воспроизводит так же: клиентское шифрование state и планов, provider
for_each, раннее вычисление переменных, метааргументenabledи динамическийprevent_destroy. Эфемерные ресурсы не являются уникальными для OpenTofu; Terraform поддерживает их начиная с версии 1.10. - Для небольшого проекта на Terraform 1.5.x с локальным или S3-состоянием простой путь миграции может занять немного времени и быть обратимым. Работа разрастается там, где есть ссылки в CI/CD, специфичные для HCP воркфлоу и изменения в файле блокировки зависимостей.
- Для нового IaC-проекта в 2026 году начинайте с OpenTofu. Для уже существующего развёртывания на Terraform переходите, когда BSL начинает мешать, когда вам нужна функция, которая есть в OpenTofu, но которой нет в Terraform, или когда контролируемая IBM дорожная карта вызывает реальные опасения. В остальных случаях выгода от перехода невелика.
Что такое OpenTofu в 2026 году
OpenTofu — это open-source форк 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 — это лицензия с открытым исходным кодом, но не одобренная 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 | С версии |
|---|---|---|---|
| Клиентское шифрование state | Встроено (PBKDF2, AWS KMS, GCP KMS, OpenBao) | Управляется бэкендом на стороне хранения | v1.7 (апр. 2024) |
| Раннее вычисление переменных | Да | Не поддерживается | v1.8 |
Провайдер for_each | Да | Нет встроенного аналога | v1.9 |
| Эфемерные ресурсы | Да | Да, начиная с 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) | Н/Д |
Клиентское шифрование state (v1.7.0, 30 апреля 2024 г.). OpenTofu может шифровать файлы state и плана прямо внутри инструмента с помощью PBKDF2, AWS KMS, GCP KMS или OpenBao. Terraform обычно делегирует шифрование в состоянии покоя выбранному бэкенду, тогда как локальный state остаётся в открытом виде. Клиентское шифрование OpenTofu может защитить украденный объект state или кэшированный план, при условии что ключ дешифровки не был раскрыт вместе с ним. Оно не заменяет 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 так же, как перебираете ресурсы. Для мульти-региональных или мульти-аккаунтных настроек это устраняет целый класс давних обходных решений. Больше не нужно вручную создавать по одному aliased-провайдеру на регион — можно управлять всем из одного блока на основе map.
Раннее вычисление переменных (v1.8). Теперь на переменные можно ссылаться там, где раньше это было запрещено, включая аргументы backend и source модуля. Это полезно, когда один корневой модуль управляет несколькими окружениями, отличающимися лишь небольшим набором переменных.
Эфемерные ресурсы и enabled метааргумент (v1.11.0, 9 декабря 2025 г.). OpenTofu 1.11 добавил эфемерные ресурсы и метааргумент enabled добавлен. Эфемерные ресурсы существуют только в рамках одного цикла plan/apply и не сохраняются в state, что полезно для короткоживущих учётных данных. Они не уникальны для OpenTofu: Terraform ввёл их в версии 1.10 и добавил write-only аргументы в 1.11. Специфичная для OpenTofu возможность здесь — enabled, который переключает блок ресурса на основе выражения без гимнастики с count condition-based.
Динамический prevent_destroy (v1.12). У Terraform параметр prevent_destroy принимает только буквальные значения. OpenTofu 1.12 позволяет вычислять его, поэтому один модуль может оставить staging удаляемым, одновременно защищая продакшен.
Строка с лицензией — это структурное различие, которое не проявляется как функция. MPL 2.0 одобрена OSI и является copyleft-лицензией на уровне файла. Лицензия BSL 1.1 у Terraform — source-available, включает дополнительное ограничение использования и меняется на 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 plantofu plan должен совпадать с планом, созданным Terraform. Если есть неожиданное отличие, проверьте версии провайдеров, настройки backend и любые функции Terraform, появившиеся после версии 1.5.x, прежде чем применять.
Прежде чем что-либо запускать, важны два нюанса. Во-первых, OpenTofu в целом совместим по конфигурации со стилем HCL от Terraform для случаев, описанных в этом руководстве, но функции, добавленные после Terraform 1.5.x, всё же требуют проверки совместимости. Во-вторых, tofu init -upgrade может обновить .terraform.lock.hcl, включая адреса источников провайдеров и записи контрольных сумм. Просматривайте эти метаданные отдельно от дрейфа инфраструктуры.
Реальные препятствия
Три вещи могут превратить быструю CLI-миграцию в масштабный платформенный проект. Ни одна из них не является багом.
Рабочие пространства HCP Terraform. OpenTofu включает интеграции cloud и remote для совместимых remote-сервисов, включая HCP Terraform в сценариях локального выполнения и хранения state. Более сложная часть — это специфичное для HCP удалённое выполнение и функции платформы: Sentinel, run triggers, динамические учётные данные, Stacks, и любое поведение сервиса, которое OpenTofu не может полностью протестировать или поддержать. Если эти вещи критичны, сначала опробуйте один workspace; если вы уходите от HCP, перенесите state и воссоздайте эти платформенные механизмы контроля.
Совет: уход от HCP Terraform может стать самой крупной скрытой затратой, если инфраструктура зависит от специфичных для HCP воркфлоу. Прежде чем принять решение, выполните terraform state pull > state.json и изучите размер и количество ресурсов. Один workspace с 200 ресурсами — совсем другой проект по сравнению с флотом из 50 workspace с run triggers и policy sets. Второй случай — это миграция уровня platform engineering, а не просто замена инструмента.
Жёстко прописанные под 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Это тривиальный случай: один workflow, один репозиторий. В монорепозитории с общими composite actions, несколькими конвейерами и библиотекой переиспользуемых workflow область проверки гораздо шире. Работа механическая, но она может занять больше времени, чем простая замена CLI.
Проверка файла блокировки зависимостей. tofu init может обновить .terraform.lock.hcl, включая адреса источников провайдеров и записи контрольных сумм. OpenTofu 1.12 также может добавлять полные наборы контрольных сумм h1: с хэшами h1:. Относитесь к этому diff как к метаданным зависимостей, которые нужно проверить и закоммитить отдельно, а не как к дрейфу инфраструктуры.
Совет: diff файла блокировки может выглядеть шумным при первом коммите. Выполните tofu init -upgrade в чистой ветке, закоммитьте только lock-файл с понятным сообщением вроде «review OpenTofu lock-file changes», а затем перебазируйте работу над функциональностью поверх него. Смешивание метаданных зависимостей с фичей в одном PR усложняет проверку обоих изменений.
Сопротивление заинтересованных сторон. «Теперь мы используем форк» воспринимается по-разному в разных организациях. Честный контраргумент в том, что OpenTofu в целом остаётся совместимым по конфигурации со стилем HCL от Terraform для случаев, описанных в этом руководстве, поэтому переход обычно обратим. Если бы OpenTofu исчез завтра, многие команды могли бы переустановить Terraform, проверить файл блокировки и продолжить использовать те же .tf файлы .tf. Сначала проверьте функции, появившиеся после форка; эта оговорка звучит убедительнее, чем обещание идеальной взаимозаменяемости.
Когда миграция действительно сложна
Этот простой путь подходит не для каждой инфраструктуры на Terraform.
Миграция становится заметно сложнее, когда:
- State большой (тысячи ресурсов, десятки workspace) и хранится в HCP Terraform.
- Кодовая база глубоко использует функции, доступные только в HCP: политики Sentinel, встроенные в workspace, run triggers, динамические учётные данные провайдеров, управляемые HCP. Terraform Stacks доступен только в HCP и не имеет аналога в OpenTofu, что выходит за рамки этой статьи.
- Корпоративный аудит или требования комплаенса называют именно «Terraform» эталонным инструментом IaC, что добавляет проблему закупок и документации поверх технической.
- Крупная библиотека модулей содержит внутренние ограничения версий, которые разрешались, полагаясь на специфичное для Terraform поведение реестра.
Не каждой команде стоит переходить. Соотношение выгоды и затрат имеет смысл только тогда, когда ограничения 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. Относитесь к этому как к платформенному решению, а не автоматически как к миграции бэкенда. OpenTofu может использовать совместимые remote-бэкенды, но специфичное для HCP удалённое выполнение, Sentinel, run triggers, динамические учётные данные и Stacks всё ещё требуют оценки функция за функцией. Если эти механизмы контроля критичны, сначала опробуйте пилотный проект. Если вы уходите от HCP по причинам лицензирования, стоимости или управления, планируйте работу как платформенную миграцию.
Рассматриваете Pulumi или другую альтернативу без HCL. OpenTofu — ближайший путь, если вы хотите сохранить HCL и большинство существующих workflow. 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-бинарник. Место его запуска во многом определяет стоимость, безопасность и то, что вы можете с ним делать. Есть примерно три разумных места для его размещения.
Ноутбук или машина разработчика. Подходит для разовых планов, прототипирования и небольших личных проектов. Это плохой выбор по умолчанию для совместных production-воркфлоу, если только remote state, блокировка и дисциплина ревью уже не внедрены. Командам обычно выгоднее иметь единую эталонную среду выполнения, чем зависеть от того, на каком ноутбуке в последний раз запускали tofu apply.
Управляемый CI-раннер (GitHub Actions, GitLab CI и т. д.). Распространённый путь. opentofu/setup-opentofu action — это готовая замена для hashicorp/setup-terraform. Это хорошо работает для большинства команд и проектов. Компромиссы: секреты проходят через стороннюю CI-службу, бесплатных минут может не хватить на крупные операции с state, а среда раннера эфемерна, что обычно является плюсом, но иногда становится ограничением. См. 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 для крупных операций плана.
Linux VPS от Cloudzy хорошо подходят под этот шаблон самостоятельно размещённого раннера — с root-доступом, NVMe-хранилищем и гибким масштабированием, так что можно начать с малого и расширять раннер по мере роста нагрузок OpenTofu.
Часто задаваемые вопросы
Является ли OpenTofu тем же самым, что и Terraform?
Не совсем. OpenTofu начинался как форк Terraform 1.5.x и в целом остаётся совместимым по конфигурации со стилем HCL от Terraform: те же .tf файлы, провайдеры и plan/apply workflow для многих проектов. Они отличаются лицензией и функциями, добавленными после форка. В OpenTofu есть клиентское шифрование state, provider for_each, enabled, и prevent_destroy; у Terraform есть свои собственные функции, появившиеся после форка, включая эфемерные ресурсы.
Будет ли OpenTofu поддерживать все мои провайдеры Terraform?
Для основных провайдеров, таких как AWS, GCP, Azure, Kubernetes и Helm, в целом да. OpenTofu Registry указывает более 3900 провайдеров по состоянию на июль 2026 года. tofu init может обновить .terraform.lock.hcl может обновлять метаданные. Для нишевых, специфичных для вендора или недавно опубликованных провайдеров проверяйте доступность и поддержку версий напрямую перед переходом.
Может ли сама OpenTofu когда-нибудь сменить лицензию?
Смена лицензии в будущем сложнее, чем это было для Terraform, но не невозможна. OpenTofu распространяется под MPL 2.0, размещён Linux Foundation и является проектом CNCF Sandbox с 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 файлов state и четырьмя миллионами ресурсов. Готовность к продакшену не означает идентичность по функциям: командам, зависящим от возможностей, доступных только в HCP, таких как Terraform Stacks, всё ещё нужно отдельное решение о совместимости.
