OpenTofu 2.0 se convierte en el estándar de IaC para empresas europeas

Hay momentos en los que lo que parecía una fragmentación del ecosistema resulta ser un cambio de estándar. El lanzamiento de OpenTofu 2.0 esta semana, acompañado del anuncio de que Capgemini, Atos y Deutsche Telekom migran su práctica de IaC desde Terraform, es uno de esos momentos.

Para entender el contexto: cuando HashiCorp cambió la licencia de Terraform de MPL a BSL en agosto de 2023, generó un terremoto en la comunidad de infraestructura. La Linux Foundation respondió creando OpenTofu, un fork con la licencia original. Lo que no estaba claro entonces era si OpenTofu sería un proyecto de nicho para puristas del open source o si tendría tracción real en la industria. Dos años después, la respuesta es evidente.

Qué trae OpenTofu 2.0

La versión 2.0 no es solo un fork al día de Terraform; incluye features propias que el proyecto original no ha implementado. Las más relevantes para equipos grandes:

State encryption nativa: OpenTofu 2.0 permite cifrar el estado de forma nativa, sin depender de que el backend remoto lo haga. Una feature muy pedida que HashiCorp nunca priorizó.

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

For-each en módulos: una de las limitaciones más molestas de HCL era la imposibilidad de iterar módulos completos. OpenTofu 2.0 lo resuelve de forma limpia y expresiva.

Provider functions: los providers ahora pueden exponer funciones que se usan directamente en expresiones HCL, no solo recursos y data sources. Esto abre la puerta a lógica más expresiva sin necesidad de scripts externos.

La migración desde Terraform: ¿qué tan difícil es?

La buena noticia es que para la mayoría de configuraciones existentes, la migración es trivial. OpenTofu es compatible con la sintaxis HCL de Terraform 1.x, lo que significa que en muchos casos basta con instalar el binario y sustituirlo:

brew install opentofu

# En tu directorio de proyecto — los ficheros .tf no cambian
tofu init
tofu plan
tofu apply

El estado existente es compatible. El cambio principal es el binario: terraform pasa a ser tofu. Las complicaciones aparecen si usas providers privados distribuidos solo a través del registry de HashiCorp, o si dependes de features de Terraform Cloud/Enterprise que no tienen equivalente en OpenTofu todavía.

¿Por qué las empresas europeas lideran la transición?

El factor licencia importa más en Europa que en otras regiones, especialmente para empresas grandes. La BSL de HashiCorp incluye restricciones sobre el uso competitivo que generan ambigüedad legal en entornos empresariales conservadores. Los departamentos jurídicos prefieren la claridad de la MPL que mantiene OpenTofu.

También hay un factor de soberanía tecnológica: OpenTofu, al ser gobernado por la Linux Foundation, se percibe como menos dependiente de las decisiones de una empresa privada. En el contexto regulatorio europeo actual, eso tiene valor real.

Qué significa para tu equipo

Si usas Terraform y estás contento con ello, no hay urgencia en migrar. La BSL no afecta a la mayoría de usos internos. Pero si tu empresa tiene una política de solo usar software con licencias permisivas, o si quieres features como state encryption que no están en Terraform, OpenTofu 2.0 es el momento de evaluar el salto.

El ecosistema de providers es esencialmente el mismo, los conocimientos de HCL son 100% transferibles, y la comunidad crece a buen ritmo. El riesgo de migrar es bajo; el riesgo de quedarse atrás si OpenTofu se consolida como estándar de facto es más difícil de cuantificar.