IaC além do Terraform - OpenTofu, o fork que virou alternativa séria

1. Uma nova série: o mundo além do Terraform

Na série anterior deste blog, exploramos em profundidade como combinar Terraform e YAML para gerenciar infraestrutura em múltiplos ambientes. O Terraform é, de longe, a ferramenta de Infraestrutura como Código (IaC) mais popular do mercado — mas está longe de ser a única peça relevante do ecossistema. Nesta nova série, vamos sair da bolha do Terraform puro e olhar para ferramentas que complementam (ou, em alguns casos, competem com) ele: OpenTofu, Ansible, e as ferramentas de teste que garantem que o código de infraestrutura realmente faz o que promete.

Começamos pelo caso mais próximo de casa: o OpenTofu, um fork direto do Terraform que nasceu de uma crise de licenciamento e hoje é um projeto da Linux Foundation com vida própria.

2. Por que um fork aconteceu

Em agosto de 2023, a HashiCorp anunciou que todos os seus produtos, incluindo o Terraform, deixariam de usar a licença Mozilla Public License 2.0 (MPL 2.0) — uma licença open source reconhecida pela OSI (Open Source Initiative) — e passariam a usar a Business Source License (BSL) 1.1.

Na prática, a BSL proíbe que terceiros usem o código da HashiCorp para criar produtos ou serviços que compitam diretamente com os produtos da própria HashiCorp. Isso pegou em cheio empresas que ofereciam plataformas de gerenciamento de estado, automação de pipelines e "Terraform as a Service" construídas sobre o código aberto do Terraform — de repente, seus modelos de negócio ficaram juridicamente incertos.

A reação da comunidade foi rápida. Em setembro de 2023, um grupo de empresas (incluindo Spacelift, Env0, Gruntwork, Harness e outras) anunciou a criação do OpenTF, um fork do último release do Terraform sob a MPL 2.0 original — congelando o código no ponto exato antes da mudança de licença. Pouco depois, o projeto foi doado para a Linux Foundation e renomeado para OpenTofu, ganhando governança neutra e um roadmap independente da HashiCorp. [1]

3. O que é o OpenTofu, na prática

OpenTofu não é um produto concorrente que reimplementa as ideias do Terraform do zero — é literalmente o mesmo código-fonte, mantido por uma comunidade aberta a partir do ponto em que divergiu. Isso significa que, para quem já usa Terraform, a curva de aprendizado para migrar é próxima de zero:

• A sintaxe é HCL (HashiCorp Configuration Language), idêntica.
• Os providers (AWS, GCP, Azure, Kubernetes, etc.) continuam funcionando — o OpenTofu consome o mesmo Terraform Registry por padrão, além de manter seu próprio registry espelhado.
• O formato do arquivo de state é compatível.
• Os comandos são praticamente os mesmos, trocando o binário terraform por tofu:

tofu init
tofu plan
tofu apply
tofu destroy

4. Diferenças práticas que já existem hoje

Apesar de compatível, o OpenTofu não ficou parado — o projeto já implementou funcionalidades que o Terraform ainda não tem (ou demorou mais para lançar):

• Criptografia de state nativa (state encryption): o OpenTofu permite criptografar o arquivo de state em repouso e em trânsito usando chaves gerenciadas pelo usuário, sem depender de um backend que já faça isso (como um bucket S3 com criptografia server-side). Isso é configurado diretamente no bloco terraform:

terraform {
  encryption {
    key_provider "pbkdf2" "mykey" {
      passphrase = var.state_encryption_passphrase
    }

    method "aes_gcm" "example" {
      keys = key_provider.pbkdf2.mykey
    }

    state {
      method = method.aes_gcm.example
    }
  }
}

• for_each em blocos provider: permite instanciar múltiplas configurações de um mesmo provider dinamicamente (por exemplo, uma credencial AWS por conta em uma lista), algo que no Terraform exige declarar cada alias manualmente.

• Registry alternativo e distribuído: o OpenTofu Registry funciona de forma independente do Terraform Registry, reduzindo o risco de um único ponto de falha para quem depende de providers e módulos públicos.

No dia a dia de um módulo Terraform comum — recursos, variáveis, outputs, for_each, count, módulos aninhados — não há diferença perceptível.

5. Quando faz sentido migrar

• Preocupação com o modelo de licenciamento: se sua empresa constrói produtos ou serviços sobre IaC (plataformas internas de self-service, ferramentas de automação) e quer evitar qualquer ambiguidade jurídica com a BSL, o OpenTofu remove essa preocupação por estar sob MPL 2.0.
• Você já usa Terraform CLI puro, sem depender de recursos exclusivos do Terraform Cloud/Enterprise (como Sentinel para policy-as-code, ou Run Tasks). Nesse caso, a migração tende a ser praticamente transparente.
• Você quer as features que só existem no OpenTofu, como a criptografia de state nativa mencionada acima.
• Governança aberta é um critério de decisão para sua organização — times que valorizam projetos sob fundações neutras (como já acontece com Kubernetes na CNCF) tendem a preferir o modelo do OpenTofu.

6. Quando NÃO faz sentido migrar (ainda)

• Dependência forte do Terraform Cloud/Enterprise: se sua equipe usa Sentinel, Run Tasks, ou outras integrações profundas com a plataforma paga da HashiCorp, migrar exige primeiro substituir essas peças por equivalentes (o OpenTofu tem parceiros como Spacelift, Env0 e Scalr oferecendo isso, mas é uma migração adicional).
• Módulos ou providers de terceiros com licenciamento restritivo: raro, mas alguns módulos privados podem ter cláusulas específicas sobre qual runtime é permitido.
• Zero atrito no momento: se o time está satisfeito com o Terraform atual e não há motivação de licenciamento, features ou governança, trocar de ferramenta só para trocar introduz risco operacional sem benefício claro. IaC não é o lugar para migrações por modismo.

7. Migrando sem drama

A migração de um projeto Terraform existente para OpenTofu costuma ser um processo de poucos passos, já que o formato de state é compatível:

# Instala o tofu (exemplo via script oficial)
curl -fsSL https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Dentro do diretório do projeto Terraform existente
tofu init

# Confirma que o plano bate com o que o terraform geraria
tofu plan

Na maioria dos casos, tofu init reconhece o state existente sem exigir nenhuma migração explícita — o formato é o mesmo. É recomendado rodar tofu plan logo após a troca e comparar com o último terraform plan para garantir que nenhuma mudança inesperada apareça antes de rodar apply.

8. Conclusão

O OpenTofu não é uma ferramenta radicalmente diferente do Terraform — e essa é exatamente a sua proposta de valor. Para quem já domina Terraform, migrar é uma decisão de baixo risco técnico e alto peso estratégico (licenciamento, governança, e algumas features exclusivas). Não é uma migração obrigatória para todo mundo, mas é uma alternativa madura o suficiente para estar na mesa de qualquer discussão sobre o futuro do seu stack de IaC. No próximo artigo desta série, saímos do território "provisionar infraestrutura" para entrar no de "configurar o que já foi provisionado": o Ansible.

---

Imagem de capa: Logo oficial do Terraform — Wikimedia Commons

Referências:

1. OpenTofu — About
2. OpenTofu Registry