OpenTofu en producción: el primer año tras la bifurcación

OpenTofu forkeó Terraform en agosto 2023 tras el cambio de HashiCorp a licencia BSL (non-OSI). Linux Foundation tomó governance, con AWS, GCP, Oracle, Datadog y la comunidad apoyando. Reached GA como 1.6 en enero 2024 y 1.7 en mayo 2024 trajo primera divergencia de features. Seis meses post-GA: ¿drop-in replacement estable o ecosistema divergente?

Estado de compatibilidad

OpenTofu 1.6 (enero 2024): fork de Terraform 1.6. Drop-in compatible:

• Configs Terraform funcionan sin cambios.
• Providers (AWS, Azure, GCP, etc) iguales.
• State format compatible.
• CLI syntax idéntico (tofu plan, tofu apply).

OpenTofu 1.7 (mayo 2024): primera divergencia:

• State encryption nativo.
• Provider iteration más flexible.
• Algunas mejoras de error messages.

Terraform 1.7 y 1.8 añadieron sus propias features. Paths empiezan a divergir.

Terraform vs OpenTofu en 2024

Drop-in migración

Para la mayoría de setups Terraform:

# Stop using Terraform
# Install OpenTofu
brew install opentofu

# Rename commands
alias terraform=tofu

# Apply as before
tofu init
tofu plan
tofu apply

Typically funciona first try. Configs no cambian. State compatible.

Features nuevas OpenTofu

State encryption

Native en 1.7:

terraform {
  encryption {
    method "unencrypted" "migrate" {}
    method "aes_gcm" "secure" {
      keys = key_provider.pbkdf2.mykey
    }
    key_provider "pbkdf2" "mykey" {
      passphrase = var.encryption_passphrase
    }

    state {
      method = method.aes_gcm.secure
    }
  }
}

State file encriptado at-rest. Antes requería plugins externos.

Removed block

removed {
  from = aws_instance.old_server
}

Sintaxis cleaner para remove resources del state sin destruir.

Adopción en 2024

Cloud providers:

• AWS: OpenTofu en documentation oficial.
• Google Cloud: similar.
• Oracle: strong backer.
• DigitalOcean, Linode, Vultr: soportan.

Managed services:

• Env0: OpenTofu support.
• Spacelift: similar.
• Scalr: también.
• HashiCorp Cloud: no — solo Terraform.

Enterprises:

• Adoption tangible pero no universal.
• Startups y mid-size migrating activamente.
• Grandes enterprises con HashiCorp contracts permaneciendo Terraform.

Provider registry

Terraform Registry sigue siendo canonical. OpenTofu Registry mirror compatible.

En 1.7, OpenTofu puede install providers desde Terraform Registry o propio. La mayoría usan Terraform Registry por ahora.

Para enterprise registries (privados), la mayoría funciona con ambos.

¿Por qué migrar?

Razones válidas:

• Legal: BSL no aceptable para algunas enterprises OSS-first.
• Governance: Linux Foundation vs single company control.
• Features específicas: state encryption si necesitas.
• Futuro-proof: hedge contra HashiCorp direction.

¿Por qué quedarse con Terraform?

Razones válidas:

• HashiCorp contract existing.
• HCP Terraform (el SaaS) tiene features únicas.
• Ecosystem mas grande (aunque cerrando).
• Stability: Terraform tiene más producción time en versión BSL.

Para la mayoría, OpenTofu es opción segura. Terraform sigue para quien tiene razón específica.

Migración path

Plan:

1. Test: run tofu commands en una Terraform config existente.
2. Resolve differences (raramente hay algunas).
3. Update CI/CD a usar tofu.
4. Update docs.
5. Train team (mínimo — syntax igual).

Proyecto de días, no semanas, en la mayoría de casos.

Features que seguirán divergir

OpenTofu 1.8+ planea:

• Provider signing más flexible.
• Async plan para plans grandes.
• Better error messages continuously.

Terraform mantiene su roadmap separate con HCP integration como foco.

Tools ecosystem

Muchas tools adaptan a ambos:

• Terragrunt: soporta Terraform y OpenTofu.
• Atlantis: ambos.
• tfsec / checkov: security scanning ambos.
• terraform-docs: funciona con ambos.

Ecosystem tools agnosticos — agnostic es estrategia smart.

Casos reales

• Cloudflare: migrated a OpenTofu.
• Bumble: public adopters.
• DigitalOcean: usa OpenTofu internally.
• Many startups: default OpenTofu.

Casos donde Terraform sigue ganando

• HCP Terraform adoption: el SaaS es Terraform-only.
• Enterprise con contracts: valor del support comercial.
• Compliance específico: si audits accept solo Terraform por name.

Conclusión

OpenTofu en 2024 es reality estable y creciente. Para nuevos proyectos, es default razonable — libre, community-governed, feature-parity suficiente. Migraciones desde Terraform son trivial en la mayoría de casos. Diverging features (state encryption) ya dan razones positivas para preferir OpenTofu beyond solo la licencia. Terraform sigue siendo válido pero con trajectory commercial-first. Para la comunidad OSS, la bifurcación fue saludable — demostró que licenses abiertas son defendibles, y eso incentiva otros vendors a pensarlo bien.

Síguenos en jacar.es para más sobre IaC, OpenTofu y open source governance.