OpenTofu Explicado: O Fork do Terraform, a Migração e Se Vale a Pena Mudar

Abra um módulo Terraform hoje e você se depara com uma pergunta que não existia há três anos: o binário que executa este código é terraform, ou é tofu? A IBM concluiu a sua aquisição da HashiCorp em 27 de fevereiro de 2025, por US$ 6,4 bilhões, e o OpenTofu se tornou um projeto CNCF Sandbox em 23 de abril de 2025, e o caminho de migração entre as duas ferramentas está oficialmente documentado. A decisão deixou de ser hipotética.

Este artigo é escrito sob a perspectiva de operações de infraestrutura, não sob a perspectiva de uma plataforma Terraform gerenciada. O objetivo é separar os custos reais de migração do ruído em torno de licenciamento e governança. Isso significa que posso ser direto sobre o que quebra durante a migração, as questões legítimas de governança e os casos em que permanecer no Terraform é a decisão certa.

Este artigo aborda quatro pontos: o que é o OpenTofu em 2026, os recursos que o Terraform não tem, como é a migração na prática e uma recomendação clara para os cenários de decisão mais comuns.

A versão curta

• O OpenTofu é um fork open source do Terraform, licenciado sob a MPL 2.0, hospedado pela Linux Foundation e um projeto CNCF Sandbox desde 23 de abril de 2025. Ele fez fork do Terraform 1.5.x depois que a HashiCorp migrou o Terraform para a Business Source License em agosto de 2023.
• Em 26 de julho de 2026, a versão de manutenção atual é v1.12.5; o repositório no GitHub tem mais de 29.000 estrelas, e o site oficial do projeto OpenTofu lista mais de 3.900 providers e mais de 23.600 módulos.
• Ele traz recursos exclusivos do OpenTofu ou em que o OpenTofu está à frente, que o Terraform atualmente não iguala da mesma forma: criptografia de state e plan no lado do cliente, provider for_each, avaliação antecipada de variáveis, o enabled meta-argumento e prevent_destroy. Recursos efêmeros não são exclusivos do OpenTofu; o Terraform os suporta desde a versão 1.10.
• Para um projeto Terraform 1.5.x pequeno com state local ou em S3, o caminho ideal pode ser uma migração curta e reversível. Referências de CI/CD, workflows específicos do HCP e alterações no dependency-lock são onde o trabalho se expande.
• Para um novo projeto de IaC em 2026, comece com o OpenTofu. Para uma implantação Terraform já existente, migre quando a BSL pesar, quando precisar de um recurso que o OpenTofu tem e o Terraform não, ou quando o roadmap controlado pela IBM for uma preocupação real. Caso contrário, a relação custo-benefício é fraca.

O Que é o OpenTofu em 2026

O OpenTofu é um fork open source do Terraform, hospedado pela Linux Foundation, aceito na CNCF como projeto Sandbox em 23 de abril de 2025, e licenciado sob a Mozilla Public License 2.0. O binário é tofu. A linguagem de configuração é a HCL, a mesma usada pelo Terraform. Na maioria dos projetos simples a médios, uma base de código Terraform existente roda sem alterações no OpenTofu.

O fork começou em agosto de 2023, depois que a HashiCorp migrou o Terraform da MPL 2.0 para a Business Source License 1.1 em 10 de agosto de 2023. A BSL é source-available em vez de aprovada pela OSI e restringe o uso em produção que "compete com as ofertas comerciais da HashiCorp". Em cinco dias, o OpenTF Manifesto foi publicado e um fork foi anunciado. O anúncio da Linux Foundation apresentou oficialmente o OpenTofu em 20 de setembro de 2023.

O anúncio da Linux Foundation citou Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver e Terramate entre os apoiadores fundadores, com pelo menos 18 engenheiros comprometidos em tempo integral por no mínimo cinco anos. O OpenTofu fez fork do Terraform 1.5.x, a última linha MPL 2.0.

Onde o projeto está hoje: v1.12.5 é a versão de manutenção atual, e o site oficial lista mais de 3.900 providers e mais de 23.600 módulos. Os sinais de adoção não se limitam mais ao impulso inicial de um fork de protesto: um estudo de caso de migração da Fidelity descreve um programa que abrange mais de 50.000 arquivos de state e quatro milhões de recursos.

O contexto de negócios relevante: a IBM concluiu a aquisição da HashiCorp em 27 de fevereiro de 2025, por US$ 6,4 bilhões. O roadmap do Terraform agora está definido dentro de um fornecedor corporativo muito maior. Isso não é automaticamente bom ou ruim para os usuários, mas faz parte do cálculo que as equipes estão fazendo em 2026.

Onde o OpenTofu Difere do Terraform

Desde o fork, os dois projetos seguiram caminhos de funcionalidades diferentes. A tabela abaixo é a versão resumida; as notas a seguir explicam o que cada diferença muda na prática.

Do lado do cliente criptografia de state (v1.7.0, 30 de abril de 2024). O OpenTofu pode criptografar arquivos de state e plan dentro da própria ferramenta com PBKDF2, AWS KMS, GCP KMS ou OpenBao. O Terraform geralmente delega a criptografia em repouso ao backend selecionado, enquanto o state local permanece em texto simples. A criptografia do lado do cliente do OpenTofu pode proteger um objeto de state roubado ou um plan em cache, desde que a chave de decriptação não seja exposta junto com ele. Isso não substitui TLS, controles de acesso do backend ou a disciplina de gerenciamento de segredos.

A configuração se parece aproximadamente com isto:

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
    }
  }
}

Provedor for_each (v1.9). Você pode iterar configurações de provider da mesma forma que itera recursos. Em configurações multi-região ou multi-conta, isso elimina uma classe antiga de workarounds. Você não precisa mais criar manualmente um provider com alias por região; pode conduzir tudo a partir de um único bloco baseado em um map.

Avaliação antecipada de variáveis (v1.8). As variáveis agora podem ser referenciadas em locais antes restritos, incluindo argumentos de backend e de module source. Isso é útil quando um único módulo raiz gerencia vários ambientes que diferem apenas por um pequeno conjunto de variáveis.

Recursos efêmeros e o enabled meta-argumento (v1.11.0, 9 de dezembro de 2025). O OpenTofu 1.11 adicionou recursos efêmeros e o enabled meta-argumento. Recursos efêmeros existem apenas dentro de um único ciclo de plan/apply e não persistem no state, o que é útil para credenciais de curta duração. Eles não são exclusivos do OpenTofu: o Terraform os introduziu na versão 1.10 e adicionou argumentos write-only na 1.11. O recurso específico do OpenTofu aqui é enabled, que ativa ou desativa um bloco de recurso a partir de uma expressão sem a necessidade de count acrobacias.

Dinâmico prevent_destroy (v1.12). do Terraform prevent_destroy aceita apenas valores literais. O OpenTofu 1.12 permite calculá-la, para que um único módulo mantenha o staging destrutível enquanto protege a produção.

A linha de licença é a diferença estrutural que não aparece como um recurso. A MPL 2.0 é aprovada pela OSI e copyleft em nível de arquivo. A licença BSL 1.1 do Terraform é source-available, inclui uma restrição de uso adicional e muda para a MPL 2.0 quatro anos após a publicação de cada obra licenciada. Para a maioria das equipes, o efeito prático é pequeno; para fornecedores que constroem algo próximo às ofertas comerciais da HashiCorp, essa é a razão de o fork existir.

Migração: O Que Realmente Quebra

O guia oficial de migração é deliberadamente curto e reversível: faça backup do state e do código, instale o OpenTofu, execute tofu init, compare tofu plane teste uma pequena alteração. As partes difíceis não são os comandos. São as referências de CI/CD ao redor, os workflows específicos do HCP, as mudanças no dependency-lock e a revisão organizacional que vem junto com a adoção de um fork.

O Caminho Tranquilo

Para um projeto que não usa o HCP Terraform e não tem milhares de referências de pipeline a terraform, a migração é direta.

# 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 deve corresponder ao plan produzido pelo Terraform. Se houver um diff inesperado, verifique as versões dos providers, as configurações de backend e quaisquer recursos do Terraform posteriores à 1.5.x antes de aplicar.

Dois detalhes importam antes de você executar qualquer coisa. Primeiro, o OpenTofu é amplamente compatível em termos de configuração com o HCL no estilo Terraform para os casos que este guia descreve, mas recursos adicionados após o Terraform 1.5.x ainda precisam de uma verificação de compatibilidade. Segundo, tofu init -upgrade pode atualizar .terraform.lock.hcl, incluindo endereços de source dos providers e entradas de checksum. Revise esses metadados separadamente do drift de infraestrutura.

Os Verdadeiros Obstáculos

Três coisas podem transformar uma migração rápida via CLI em um projeto de plataforma mais amplo. Nenhuma delas é um bug.

Workspaces do HCP Terraform. O OpenTofu inclui integrações cloud e remote para serviços remote compatíveis, incluindo o HCP Terraform em cenários de execução local e armazenamento de state. A parte mais difícil é a execução remota e os recursos de plataforma específicos do HCP: Sentinel, run triggers, credenciais dinâmicas, Stacks, e qualquer comportamento de serviço que o OpenTofu não consiga testar ou suportar totalmente. Se esses forem centrais, faça um piloto em um workspace primeiro; se estiver deixando o HCP, migre o state e recrie esses controles de plataforma.

Dica: Deixar o HCP Terraform pode ser o maior custo oculto quando o parque de recursos depende de workflows específicos do HCP. Antes de decidir, execute terraform state pull > state.json e verifique o tamanho e a contagem de recursos. Um workspace com 200 recursos é um projeto diferente de uma frota de 50 workspaces com run triggers e policy sets. O segundo caso é uma migração de engenharia de plataforma, não uma simples troca de ferramenta.

Pipelines de CI/CD com codificação fixa para terraform. Toda referência a terraform plan, terraform apply, o caminho do binário, a imagem Docker e a etapa do GitHub Actions ou GitLab CI precisa de revisão. Para o GitHub Actions, a troca é mais ou menos assim:

# 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

Esse é o caso trivial: um workflow, um repositório. Em um monorepo com composite actions compartilhadas, múltiplos pipelines e uma biblioteca reutilizável de workflows, a superfície de revisão é maior. O trabalho é mecânico, mas pode levar mais tempo do que a troca da CLI.

Revisão do arquivo de dependency lock. tofu init pode atualizar .terraform.lock.hcl, incluindo endereços de source dos providers e entradas de checksum. O OpenTofu 1.12 também pode adicionar conjuntos completos de checksum h1: de checksum. Trate o diff como metadados de dependência para revisar e fazer commit separadamente, não como drift de infraestrutura.

Dica: o diff do lock-file pode parecer ruidoso no primeiro commit. Execute tofu init -upgrade em uma branch limpa, faça commit apenas do arquivo de lock com uma mensagem clara como "review OpenTofu lock-file changes", e depois faça rebase do trabalho da funcionalidade em cima dele. Misturar metadados de dependências em um PR de funcionalidade torna as duas alterações mais difíceis de revisar.

Resistência das partes interessadas. "Agora estamos rodando um fork" é recebido de forma diferente em cada organização. O contra-argumento honesto é que o OpenTofu permanece amplamente compatível em termos de configuração com o HCL no estilo Terraform para os casos descritos neste guia, então a troca costuma ser reversível. Se o OpenTofu desaparecesse amanhã, muitas equipes poderiam reinstalar o Terraform, revisar o lock file e continuar usando os mesmos .tf arquivos. Valide primeiro os recursos pós-fork; essa ressalva é mais crível do que prometer intercambiabilidade perfeita.

Quando a Migração É Realmente Difícil

Esse caminho tranquilo não se aplica a todo parque Terraform.

A migração fica significativamente mais difícil quando:

• O state é grande (milhares de recursos, dezenas de workspaces) e vive no HCP Terraform.
• A base de código usa profundamente recursos exclusivos do HCP: políticas Sentinel conectadas aos workspaces, run triggers, credenciais dinâmicas de provider gerenciadas pelo HCP. O Terraform Stacks é exclusivo do HCP e não tem equivalente no OpenTofu, o que está fora do escopo aqui.
• Uma auditoria corporativa ou framework de compliance nomeia o "Terraform" como a ferramenta de IaC oficial, o que é um problema de aquisição e documentação além do técnico.
• Uma grande biblioteca de módulos tem restrições internas de versão que foram resolvidas com base no comportamento específico do registry do Terraform.

Nem toda equipe deveria migrar. A relação custo-benefício só faz sentido quando as restrições da BSL realmente afetam seu caso de uso, quando um recurso específico do OpenTofu desbloqueia algo concreto, ou quando um roadmap controlado pela IBM é uma preocupação real para sua organização. Se nada disso se aplica, permanecer no Terraform é uma escolha perfeitamente defensável.

Você Deveria Migrar?

Não existe uma única resposta certa aqui. Quando desenho a árvore de decisão para uma equipe, quatro cenários comuns aparecem, e a decisão certa depende de qual cenário você está.

Nova adoção de IaC (greenfield). Comece com o OpenTofu. A licença é a MPL 2.0, a governança fica sob a Linux Foundation e a CNCF, e o projeto tem um ritmo de lançamentos ativo. Seus diferenciais incluem criptografia de state no lado do cliente, provider for_each, enablede prevent_destroy. Não há atrito com a BSL para se preocupar. Esta é a recomendação mais forte deste artigo.

Usuário existente do Terraform, projeto pequeno a médio. Migre se qualquer um dos três gatilhos ocorrer. Um: você vende ou pode vir a vender um produto que possa esbarrar na exceção "compete com a HashiCorp" da BSL; o cálculo jurídico é mais limpo na MPL 2.0. Dois: você precisa de criptografia de state no lado do cliente, provider for_each, enabledou prevent_destroy e o workaround do Terraform não vale mais a pena manter. Três: você prefere uma governança multipartidária a um roadmap de fornecedor único. Se nada disso se aplica e o Terraform roda sem problemas, fique. A migração é reversível em muitos parques, mas não é gratuita.

Usuário intenso do HCP Terraform. Trate isso como uma decisão de plataforma, não automaticamente como uma migração de backend. O OpenTofu pode usar backends remotos compatíveis, mas a execução remota específica do HCP, o Sentinel, os run triggers, as credenciais dinâmicas e o Stacks ainda exigem uma avaliação recurso por recurso. Se esses controles forem centrais, faça um piloto primeiro. Se você está deixando o HCP por motivos de licenciamento, custo ou governança, planeje o trabalho como uma migração de plataforma.

Considerando o Pulumi ou outra alternativa não-HCL. O OpenTofu é o caminho mais próximo se você quiser manter o HCL e a maior parte dos workflows existentes. O Pulumi é uma escolha de plataforma e linguagem mais ampla: TypeScript, Python, Go ou .NET controlando APIs de nuvem. Migrar para lá pode envolver conversão ou reescrita, então avalie isso separadamente de uma simples troca de binário de Terraform para OpenTofu.

Mais uma coisa vale a pena abordar diretamente: a crítica legítima de que o OpenTofu é, em parte, uma proteção de fornecedores de SaaS. Uma thread no Hacker News sobre a mudança da BSL levantou a preocupação de que os membros fundadores do projeto são plataformas comerciais de Terraform com um interesse próprio em flexibilidade de licenciamento. Levo essa preocupação a sério. A mitigação é a estrutura de governança, a hospedagem pela Linux Foundation, o CNCF Sandbox, a MPL 2.0 em cada arquivo, o que torna um futuro relicenciamento significativamente mais difícil do que era um relicenciamento de fornecedor único. Isso não torna impossível. Mas torna caro o suficiente para ser um controle real.

Veredicto rápido. Para novos trabalhos de IaC em 2026, comece com o OpenTofu. Sua licença, governança, desenvolvimento ativo e conjunto de recursos fazem dele uma escolha padrão forte. Para implantações Terraform já existentes, migre quando um dos três gatilhos acima se aplicar; caso contrário, a relação custo-benefício é fraca e permanecer é aceitável.

Uma vez que a escolha da ferramenta esteja clara, a próxima questão prática é onde o OpenTofu deve rodar. Essa decisão afeta o tratamento de secrets, o custo, a repetibilidade e o quanto de controle sua equipe tem sobre o ambiente de execução.

Executando o OpenTofu Você Mesmo

O OpenTofu é um binário de CLI. Onde você o executa determina muito sobre custo, segurança e o que você pode fazer com ele. Existem, grosso modo, três lugares sensatos para colocá-lo.

Notebook ou máquina de desenvolvimento. Serve bem para plans pontuais, prototipagem e pequenos projetos pessoais. É uma escolha padrão ruim para workflows de produção compartilhados, a menos que remote state, locking e disciplina de revisão já estejam em vigor. Equipes geralmente se beneficiam de um ambiente de execução canônico em vez de qualquer notebook que tenha rodado por último tofu apply.

Runner de CI gerenciado (GitHub Actions, GitLab CI etc.). O caminho comum. opentofu/setup-opentofu é um substituto direto para hashicorp/setup-terraform. Isso funciona bem para a maioria das equipes e projetos. Trade-offs: os secrets transitam por um serviço de CI de terceiros, os minutos do plano gratuito podem se esgotar em operações grandes de state, e o ambiente do runner é efêmero, o que geralmente é uma vantagem, mas às vezes uma limitação. Veja GitHub vs GitLab se você ainda está escolhendo entre opções de CI hospedadas, e Best CI/CD Tools para o panorama mais amplo.

Runner auto-hospedado em uma VPS. Útil quando os trade-offs do CI gerenciado deixam de funcionar: os secrets precisam ficar fora de um serviço de terceiros, os minutos de CI ficam caros, ou você quer caches persistentes de provider. A configuração é simples: uma VPS Linux, o binário do OpenTofu, um agente do GitHub Actions ou GitLab Runner, e o Docker para isolamento de jobs. Veja Install Docker on VPS se essa parte for nova para você. Para um runner de equipe pequena, 4 GB de RAM, 2 vCPUs e 60 GB de NVMe são um ponto de partida razoável; ajuste CPU, memória e armazenamento para plans maiores e maior concorrência.

Para equipes que precisam de controle mais rígido sobre os secrets do runner, caches persistentes de provider ou custos de CI previsíveis, um runner auto-hospedado em uma VPS pode fazer sentido. Nessa configuração, priorize acesso root, armazenamento NVMe rápido, redimensionamento fácil e CPU/RAM suficientes para operações de plan maiores.

Cloudzy Linux VPS instâncias se encaixam nesse padrão de runner auto-hospedado, com acesso root, armazenamento NVMe e dimensionamento flexível, para você começar pequeno e escalar o runner conforme suas cargas de trabalho do OpenTofu crescem.

Perguntas frequentes

O OpenTofu é o Mesmo que o Terraform?

Não exatamente. O OpenTofu começou como um fork do Terraform 1.5.x e permanece amplamente compatível em termos de configuração com o HCL no estilo Terraform: os mesmos .tf arquivos, providers e plan/apply workflow para muitos projetos. Eles diferem na licença e nos recursos adicionados após o fork. O OpenTofu tem criptografia de state no lado do cliente, provider for_each, enablede prevent_destroy; o Terraform tem seus próprios recursos pós-fork, incluindo recursos efêmeros.

O OpenTofu Vai Suportar Todos os Meus Providers do Terraform?

Para providers importantes como AWS, GCP, Azure, Kubernetes e Helm, geralmente sim. O OpenTofu Registry reporta mais de 3.900 providers a partir de julho de 2026. tofu init pode atualizar .terraform.lock.hcl metadados. Para providers de nicho, específicos de fornecedor ou recém-publicados, verifique diretamente a disponibilidade e o suporte de versão antes de migrar.

O Próprio OpenTofu Poderia Ser Relicenciado Algum Dia?

Um relicenciamento futuro é mais difícil do que foi para o Terraform, mas não é impossível. O OpenTofu é MPL 2.0, hospedado pela Linux Foundation, e um projeto CNCF Sandbox desde 23 de abril de 2025. A governança é multipartidária e a licença é aprovada pela OSI. Um relicenciamento unilateral por qualquer fundador isolado entraria em conflito tanto com o estatuto da fundação quanto com as contribuições MPL 2.0 existentes, que teriam de ser removidas ou reescritas. A preocupação é legítima; as barreiras estruturais são reais.

O Que a Aquisição da HashiCorp pela IBM Significa para o Futuro do Terraform?

A IBM concluiu a aquisição da HashiCorp em 27 de fevereiro de 2025, por US$ 6,4 bilhões. O roadmap do Terraform agora está dentro de um fornecedor corporativo maior. A aquisição, por si só, não comprova a direção futura de licenciamento ou de produto; avalie as release notes atuais, as orientações de licenciamento e as mudanças de produto do HCP em vez de tratar a propriedade como uma previsão.

O OpenTofu Está Pronto para Produção em 2026?

Sim. A v1.12.5 é a versão de manutenção atual, o projeto está no CNCF Sandbox, e a Fidelity descreveu uma adoção em produção em um parque de IaC com mais de 50.000 arquivos de state e quatro milhões de recursos. Pronto para produção não significa idêntico em recursos: equipes que dependem de capacidades exclusivas do HCP, como o Terraform Stacks, ainda precisam tomar uma decisão de compatibilidade à parte.