Se você trabalha com infraestrutura como código, provavelmente sentiu o impacto da mudança de licença do Terraform em 2023. O que era MPL virou BSL, a HashiCorp foi comprada pela IBM por 6.4 bilhões de dólares, e de repente a ferramenta que você usava tranquilamente ganhou restrições comerciais. Nesse cenário, o OpenTofu surgiu como um fork open-source mantido pela Linux Foundation e rapidamente conquistou mais de 140 empresas apoiadoras e mais de 27 mil estrelas no GitHub.

Mas migrar não precisa ser um salto no escuro. O OpenTofu mantém compatibilidade com configurações Terraform 1.5.x e, ao mesmo tempo, traz features exclusivas que o Terraform não oferece. Neste guia, vamos cobrir tudo: o que mudou no cenário de IaC, as diferenças práticas entre as duas ferramentas e um roteiro completo para migrar projetos reais.

Por que o cenário de IaC mudou em 2026

A mudança começou em agosto de 2023, quando a HashiCorp anunciou que o Terraform deixaria de ser open-source sob a MPL 2.0 e passaria a adotar a Business Source License (BSL). Na prática, isso significa que qualquer empresa que ofereça Terraform como parte de um serviço voltado a clientes precisa de um acordo comercial com a HashiCorp.

Para quem usa Terraform internamente, nada mudou no dia a dia. Mas o efeito cascata foi enorme: a incerteza sobre o futuro da licença levou a comunidade a criar o OpenTofu em setembro de 2023, e a Linux Foundation assumiu a governança do projeto.

Em fevereiro de 2025, a IBM completou a aquisição da HashiCorp por 6.4 bilhões de dólares. Isso adicionou mais uma camada de incerteza. A IBM tem histórico de manter produtos enterprise com licenciamento restritivo, e muitas empresas decidiram que não queriam depender dessa direção.

O resultado? Em 2026, o cenário de IaC tem dois caminhos claros: Terraform (BSL, controlado pela IBM/HashiCorp) e OpenTofu (MPL 2.0, governado pela comunidade via Linux Foundation).

O que é o OpenTofu

O OpenTofu é um fork do Terraform 1.6.x que funciona como drop-in replacement. Seus arquivos .tf existentes, state files e configurações de provider funcionam sem modificação. O comando tofu substitui o terraform com a mesma interface CLI.

# Verificar a versão instalada
tofu version

# Inicializar um projeto existente
tofu init

# Planejar mudanças
tofu plan

# Aplicar infraestrutura
tofu apply

A compatibilidade é tão alta que a migração técnica leva em média duas semanas para a maioria das organizações. Os providers do Terraform Registry funcionam no OpenTofu sem alteração, e os módulos públicos continuam sendo resolvidos normalmente.

# providers.tf - Funciona idêntico no OpenTofu
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "sa-east-1"
}

Repare que o bloco ainda se chama terraform {} por compatibilidade. Não precisa renomear nada.

As features exclusivas que fazem a diferença

Alguns podem pensar que migrar para o OpenTofu é trocar seis por meia dúzia. Não é. Desde o fork, o OpenTofu introduziu features que o Terraform não tem e provavelmente não terá.

State encryption nativo

Talvez a feature mais impactante. O OpenTofu permite criptografar o state file no lado do cliente, garantindo que segredos nunca saiam da sua máquina sem criptografia. No Terraform, você depende de criptografia do backend (como S3 com SSE), mas os dados ficam em texto plano durante o trânsito e no plano.

terraform {
  encryption {
    key_provider "pbkdf2" "minha_chave" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "encriptacao" {
      keys = key_provider.pbkdf2.minha_chave
    }

    state {
      method = method.aes_gcm.encriptacao
    }

    plan {
      method = method.aes_gcm.encriptacao
    }
  }
}

Isso é especialmente relevante para ambientes regulados que exigem criptografia end-to-end dos dados de infraestrutura.

Ephemeral resources

Introduzidos no OpenTofu 1.11, os ephemeral resources existem apenas durante a execução de um comando. Eles nunca são persistidos no state file, o que é perfeito para credenciais temporárias e dados sensíveis.

ephemeral "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "prod/database/password"
}

resource "aws_db_instance" "postgres" {
  engine         = "postgres"
  engine_version = "17"
  instance_class = "db.t3.medium"

  password = ephemeral.aws_secretsmanager_secret_version.db_password.secret_string
}

A senha do banco é lida do Secrets Manager durante o apply, usada para configurar a instância RDS e descartada. Em nenhum momento ela aparece no state.

Provider for_each

Desde o OpenTofu 1.9, você pode iterar sobre providers com for_each. Isso facilita deployments multi-região sem duplicar blocos de configuração.

variable "regioes" {
  default = ["us-east-1", "sa-east-1", "eu-west-1"]
}

provider "aws" {
  alias    = "por_regiao"
  for_each = toset(var.regioes)
  region   = each.value
}

resource "aws_s3_bucket" "dados" {
  for_each = toset(var.regioes)
  provider = aws.por_regiao[each.value]
  bucket   = "minha-app-${each.value}"
}

No Terraform, você precisaria de um bloco provider separado para cada região e módulos com providers explícitos. Com for_each, o código fica mais limpo e escalável.

Meta-argumento enabled

O OpenTofu 1.11 trouxe o enabled como alternativa ao padrão count = var.habilitar ? 1 : 0. Mais legível e sem os problemas de indexação que count causa.

resource "aws_cloudwatch_log_group" "app" {
  name              = "/app/producao"
  retention_in_days = 30

  lifecycle {
    enabled = var.habilitar_logs
  }
}

Terraform vs OpenTofu: o que muda na prática

Vamos ao comparativo direto para quem precisa tomar a decisão.

Licença e governança: O Terraform usa BSL 1.1 sob controle da HashiCorp/IBM. O OpenTofu usa MPL 2.0 sob governança da Linux Foundation. Se você oferece um serviço que compete com os produtos HashiCorp, a BSL pode ser um problema. Para uso interno, ambos são livres.

Compatibilidade: O OpenTofu 1.11 mantém compatibilidade drop-in com configurações Terraform 1.5.x. A paridade de features está em torno de 95%, mas essa porcentagem vai diminuir conforme os projetos divergem.

Features exclusivas do OpenTofu: State encryption nativo, ephemeral resources, provider for_each, meta-argumento enabled, distribuição de providers via registros OCI e variáveis em configuração de backend.

Features exclusivas do Terraform: Terraform Cloud e Terraform Enterprise como plataformas gerenciadas, integrações profundas com o ecossistema HashiCorp (Vault, Consul, Nomad) e suporte comercial oficial.

Providers: Ambos usam os mesmos providers. O OpenTofu busca no seu próprio registry e faz fallback automático para o registry da HashiCorp. Nenhuma alteração nos blocos required_providers é necessária.

Comunidade: O Terraform tem base instalada maior e mais conteúdo educacional disponível. O OpenTofu tem crescimento acelerado e governança mais transparente, com decisões tomadas em público via RFCs.

Migrando um projeto real passo a passo

A migração é mais simples do que parece. Siga este roteiro para um projeto com backend S3.

Passo 1: instalar o OpenTofu

# Linux (Debian/Ubuntu)
curl -fsSL https://get.opentofu.org/install-opentofu.sh \
  | sudo bash -s -- --install-method deb

# macOS
brew install opentofu

# Verificar instalação
tofu version

Passo 2: validar a versão do state

Antes de tudo, confirme que seu state file é compatível.

# Checar versão do Terraform que gerou o state
cat terraform.tfstate | jq '.terraform_version'

Se o resultado for 1.5.x ou anterior, a migração é direta. Para versões 1.6+, teste em ambiente de staging primeiro.

Passo 3: backup do state

Nunca migre sem backup. Se o state está no S3, faça uma cópia.

BACKUP_KEY="backups/pre-opentofu-$(date +%Y%m%d-%H%M%S).tfstate"
aws s3 cp \
  s3://meu-bucket-state/producao/terraform.tfstate \
  s3://meu-bucket-state/$BACKUP_KEY

Passo 4: inicializar com OpenTofu

O comando tofu init lê a configuração existente e baixa os providers do registry do OpenTofu.

cd /caminho/do/projeto
tofu init

Se houver um state existente no backend, o OpenTofu o lê automaticamente. O formato JSON do state é idêntico.

Passo 5: validar com plan

Este é o teste crítico. Um plan limpo, sem nenhuma mudança, confirma que o OpenTofu interpreta sua infraestrutura corretamente.

tofu plan -detailed-exitcode
# Exit code 0 = sem mudanças (sucesso!)
# Exit code 2 = mudanças detectadas (investigar)

Se o resultado mostrar zero mudanças, sua migração está completa do ponto de vista do state.

Passo 6: atualizar o CI/CD

Substitua o binário terraform por tofu nos seus pipelines. No GitHub Actions, a action oficial facilita.

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup OpenTofu
        uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: 1.11.0

      - name: Init
        run: tofu init

      - name: Plan
        run: tofu plan -out=tfplan

      - name: Apply
        if: github.ref == 'refs/heads/main'
        run: tofu apply -auto-approve tfplan

Passo 7: validação paralela (recomendado)

Antes do cutover definitivo, rode ambas as ferramentas por pelo menos duas semanas comparando os outputs.

terraform plan -no-color > tf-plan.txt
tofu plan -no-color > tofu-plan.txt
diff tf-plan.txt tofu-plan.txt

Diferenças cosméticas (timestamps, versão do binário) são esperadas. O importante é que os recursos e mudanças propostas sejam idênticos.

Armadilhas e cuidados na migração

A migração é simples, mas existem pontos que merecem atenção.

Não use features exclusivas do OpenTofu antes de completar a migração. Se você habilitar state encryption ou usar ephemeral resources e precisar voltar ao Terraform, o rollback se torna complexo. Migre primeiro, adote features novas depois.

Scripts e aliases com referência ao binário terraform: Faça um grep no repositório e nos scripts de CI para encontrar todas as referências. Um alias temporário pode ajudar na transição.

# Alias temporário durante a migração
alias terraform='tofu'

Lock files do state: Se você usa DynamoDB para locking (padrão em backends S3), confirme que não há locks ativos antes de iniciar a migração. Um lock preso pode bloquear o tofu init.

aws dynamodb scan --table-name terraform-state-locks \
  --filter-expression "attribute_exists(LockID)" \
  --projection-expression "LockID"

Módulos privados: Se você hospeda módulos em um registry privado do Terraform Cloud, eles não estarão disponíveis diretamente. Considere mover para um registry Git ou OCI, que o OpenTofu suporta nativamente desde a versão 1.10.

Terraform Cloud e Enterprise: Se você depende do Terraform Cloud para execução remota, state management ou policy-as-code com Sentinel, não existe equivalente direto no OpenTofu. Alternativas como Spacelift, env0 e Scalr oferecem suporte ao OpenTofu e podem preencher essa lacuna.

Conclusão

A migração do Terraform para o OpenTofu não é uma questão de qual ferramenta é melhor em termos absolutos. É uma questão de controle: você quer que o futuro da sua infraestrutura como código dependa das decisões de licenciamento de uma única empresa, ou prefere uma governança aberta e previsível?

Para quem usa Terraform internamente e não compete com a HashiCorp, continuar no Terraform é perfeitamente viável. Mas para empresas que oferecem serviços de infraestrutura, trabalham em ambientes regulados que exigem criptografia de state, ou simplesmente valorizam a previsibilidade de uma licença open-source, o OpenTofu é a escolha mais segura em 2026.

A migração técnica leva dias, não meses. Os providers são os mesmos, os módulos são os mesmos, e o formato do state é idêntico. O investimento real está na validação cuidadosa e no treinamento do time nas features novas.

Se você decidir migrar, comece pelo staging, rode a validação paralela por duas semanas, e só então faça o cutover em produção. Infraestrutura não é lugar para pressa.

Referências pesquisadas nesta publicação