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

Actualizado: 2026-05-03

OpenTofu^[1] forkeó Terraform en agosto de 2023, tras el cambio de licencia de HashiCorp a BSL (non-OSI). Linux Foundation tomó la governance, con AWS, GCP, Oracle, Datadog y la comunidad apoyando. Alcanzó GA como versión 1.6 en enero de 2024, y la 1.7 en mayo de 2024 trajo la primera divergencia real de features. Seis meses después del GA: ¿es un reemplazo drop-in estable o está divergiendo en un ecosistema propio?

Puntos clave

• OpenTofu 1.6 es drop-in compatible con Terraform: mismas configs, mismo state format, misma sintaxis CLI.
• OpenTofu 1.7 introdujo state encryption nativa, la primera feature exclusiva con ventaja técnica real frente a Terraform.
• La migración típica es un proyecto de días, no de semanas.
• Para nuevos proyectos, OpenTofu es el default razonable si no hay contrato HashiCorp previo.
• Startups y mid-size están migrando activamente; grandes enterprises con contratos HashiCorp permanecen en Terraform.

Estado de compatibilidad

OpenTofu 1.6 (enero 2024): fork de Terraform 1.6. Drop-in compatible en todos los aspectos:

• Las configuraciones Terraform funcionan sin cambios.
• Los providers (AWS, Azure, GCP, etc.) son idénticos.
• El formato de state es compatible.
• La sintaxis CLI es idéntica: tofu plan, tofu apply.

OpenTofu 1.7 (mayo 2024): primera divergencia real:

• State encryption nativa: feature exclusiva que Terraform no tiene sin plugins externos.
• Iteración de providers más flexible.
• Mejoras en mensajes de error.

Terraform 1.7 y 1.8 también añadieron features propias. Los caminos empiezan a separarse.

OpenTofu frente a Terraform en producción

Migración drop-in

Para la mayoría de setups Terraform:

# Instalar OpenTofu
brew install opentofu

# Alias para transición gradual
alias terraform=tofu

# Funciona igual que antes
tofu init
tofu plan
tofu apply

Típicamente funciona en el primer intento. Las configs no cambian. El state es compatible. Para setups más complejos con módulos privados o backends específicos, hacer primero una prueba en un entorno de staging aislado.

State encryption: la primera ventaja real

La feature más importante de OpenTofu 1.7 es el cifrado de state nativo:

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

El state file queda cifrado en reposo. Antes de OpenTofu 1.7, esto requería plugins externos o gestión manual. Para entornos con requisitos de compliance que exigen que los secretos en el state (credenciales de DB, tokens de API) estén cifrados, esta feature sola puede justificar la migración.

Adopción actual

Cloud providers:

• AWS: OpenTofu en documentación oficial.
• Google Cloud: soporte documentado.
• Oracle: strong backer desde el inicio.
• DigitalOcean, Linode, Vultr: soporte documentado.

Managed services de CI/CD IaC:

• Env0^[2]: soporte OpenTofu.
• Spacelift^[3]: soporte OpenTofu.
• Scalr^[4]: soporte OpenTofu.
• HashiCorp Cloud: no — solo Terraform. El SaaS está vinculado al vendor.

Casos reales públicos: Cloudflare, Bumble y DigitalOcean han migrado a OpenTofu internamente.

Cuándo migrar a OpenTofu

Razones válidas:

• La licencia BSL es inaceptable para tu empresa (OSS-first policy, redistribución).
• Quieres governance de Linux Foundation en lugar de control de un único vendor.
• Necesitas state encryption nativa.
• Quieres hacer un hedge ante la dirección futura de HashiCorp bajo IBM.

Cuándo permanecer en Terraform

Razones válidas:

• Tienes un contrato HashiCorp Enterprise activo con SLA.
• Usas HCP Terraform (el SaaS) con features que no tienen equivalente.
• Tu auditoría o compliance requiere “Terraform” por nombre específico.
• El equipo tiene demasiada carga operativa para una migración en este momento.

Ecosistema de herramientas

La mayoría del tooling es agnóstico:

• Terragrunt^[5]: soporta tanto Terraform como OpenTofu.
• Atlantis^[6]: ambos.
• tfsec^[7] y checkov^[8]: escaneo de seguridad en ambos.
• terraform-docs^[9]: funciona con los dos.

Para combinar OpenTofu con configuration management, ver el artículo sobre Ansible y Pulumi: el mismo patrón de inventario dinámico aplica con OpenTofu.

Plan de migración típico

Un proyecto de días en la mayoría de casos:

1. Prueba tofu commands en una config Terraform existente en entorno aislado.
2. Resuelve las diferencias (raramente hay alguna en 1.6, ocasionalmente en 1.7).
3. Actualiza el CI/CD para usar tofu en lugar de terraform.
4. Actualiza la documentación interna.
5. Forma al equipo (mínimo — la sintaxis es idéntica).

Conclusión

OpenTofu en producción es realidad estable y creciente. Para proyectos nuevos, es el default razonable: libre, con governance de Linux Foundation y suficiente feature parity con Terraform. Las migraciones desde Terraform son triviales en la mayoría de casos. El state encryption nativo ya ofrece razones positivas para preferir OpenTofu más allá de la licencia. Terraform sigue siendo válido para quien tiene razón específica (contrato activo, HCP SaaS). Para la comunidad open-source, la bifurcación fue saludable: demostró que las licencias abiertas son defendibles.

1. OpenTofu
2. Env0
3. Spacelift
4. Scalr
5. Terragrunt
6. Atlantis
7. tfsec
8. checkov
9. terraform-docs