La versión 1.6 de Terraform, publicada en octubre de 2023, fue la primera lanzada bajo la nueva licencia Business Source License. Aquel cambio provocó, apenas unos días después, el anuncio de OpenTofu como fork comunitario auspiciado por la Linux Foundation, partiendo de Terraform 1.5. Más de un año después, Terraform 1.9 ya está en producción y OpenTofu 1.8 es estable. Merece la pena revisar con calma qué ha ido entregando HashiCorp, qué ofrece el fork y qué novedades importan realmente en el día a día de un equipo que escribe infraestructura declarativa.

Puntos clave

  • Los import blocks declarativos de 1.6 son el cambio más transformador de la rama: importar infraestructura existente pasa de ser una tarde de CLI a un pull request revisable.

  • El framework de tests nativo permite validar lógica de módulos en HCL sin aprender Go ni salir del stack existente.

  • Los ephemeral values de 1.9 evitan que secretos dinámicos se persistan en el fichero de estado.

  • OpenTofu es drop-in compatible, con estado intercambiable, y aporta encriptación nativa del fichero de estado.

  • La decisión Terraform vs OpenTofu se reduce a tres preguntas: ¿contrato con HashiCorp?, ¿necesitas stacks o encriptación nativa?, ¿qué dice política interna sobre BSL?

Lo que 1.6 cambió de verdad

La estrella de Terraform 1.6 fueron los bloques import declarativos. Hasta entonces, importar un recurso existente al estado obligaba a ejecutar terraform import desde la línea de comandos, recordar el ID exacto del proveedor y luego escribir a mano el bloque de recurso correspondiente. Con los import declarativos, el plan muestra qué se va a importar antes de aplicarlo, el código queda versionado en Git, y se pueden importar decenas de recursos en un mismo ciclo de revisión. Para equipos que heredan infraestructura creada en la consola o en otra herramienta, es la diferencia entre una tarde entera de comandos CLI y un pull request revisable.

La otra novedad estructural de 1.6 fue el framework de tests nativo. Hasta ese momento, probar módulos de Terraform pasaba por Terratest (Go), kitchen-terraform u otras alternativas externas. El framework nativo introduce ficheros .tftest.hcl que describen bloques run con comandos (plan o apply), variables específicas del test y aserciones sobre los outputs. No sustituye a Terratest para pruebas de integración reales contra un proveedor cloud, pero cubre un hueco enorme: validar lógica de módulos sin abandonar HCL ni aprender Go.

run "valida_cidr_vpc" {
  command = plan
  variables {
    cidr_block = "10.0.0.0/16"
  }
  assert {
    condition     = module.vpc.cidr_block == "10.0.0.0/16"
    error_message = "CIDR de la VPC no coincide con el parámetro"
  }
}

Desde 1.7 estos tests se ejecutan en paralelo, lo que hace viable una suite amplia en CI.

Lo útil de 1.7 y 1.8

Terraform 1.7 añadió el bloque removed, el complemento conceptual de moved. Permite eliminar un recurso del estado de forma declarativa, sin destruirlo, escribiendo un bloque que indica la dirección retirada. Es imprescindible cuando se migran recursos entre módulos, se eliminan recursos gestionados fuera de Terraform, o se limpia estado tras refactorizaciones grandes.

Antes tocaba recurrir a terraform state rm, un comando imperativo que no deja rastro en el código. Ahora la operación queda revisada en el plan y auditada en el repositorio.

La versión 1.8 trajo las funciones definidas por provider. Los proveedores pueden exportar funciones personalizadas accesibles con la sintaxis provider::<nombre>::función(...). El AWS provider, por ejemplo, publica funciones para parsear ARNs sin expresiones regulares frágiles. Es un paso útil, pero menos transformador que los import blocks: en la práctica, un equipo se apaña con las funciones incorporadas y con local blocks.

Ephemeral values y validación de módulos en 1.9

La novedad más interesante de Terraform 1.9, publicada en julio de 2024, son los ephemeral values. Son valores que se materializan en tiempo de plan o apply, pero nunca se escriben al fichero de estado. El caso de uso evidente son secretos: contraseñas generadas dinámicamente, tokens obtenidos de Vault o AWS Secrets Manager, credenciales temporales. Hasta ahora, incluso con sensitive = true, estos valores acababan cifrados dentro del estado, con el riesgo que implica si el backend se compromete.

Con ephemeral, el valor se usa durante el ciclo y desaparece. No resuelve todos los problemas de secretos en IaC, pero reduce la superficie de exposición de una manera que mucha gente llevaba años pidiendo. Esta gestión de secretos efímeros conecta con los principios de cadena de suministro que analizamos en SLSA v1.0.

1.9 también endureció la validación de inputs de módulos. Las variables pueden referirse a otras variables del mismo módulo dentro de las reglas de validación, lo que permite escribir reglas cruzadas del tipo "si el parámetro A es prod, el parámetro B tiene que estar definido".

Stacks: el feature que puede cambiar los patrones

A finales de 2024, stacks sigue en preview privado en HCP Terraform. La promesa es ambiciosa: un único módulo desplegado en múltiples entornos con dependencias cruzadas explícitas, orquestación coordinada, y un modelo de estado que entiende la relación entre instancias. Si cumple lo prometido, reduce dramáticamente la necesidad de Terragrunt para el caso de uso clásico de "despliega este módulo en tres regiones y veinte cuentas".

Habrá que ver la GA y el pricing, porque el componente de orquestación vive en HCP y eso condiciona su adopción en entornos que prefieren todo autohospedado.

OpenTofu: el fork es real

A finales de 2024, OpenTofu ya tiene un rastro claro:

  • Es drop-in compatible para configuraciones estándar; el estado es intercambiable.

  • Los proveedores funcionan idénticamente.

  • Aporta encriptación nativa del fichero de estado (ausente en Terraform).

  • Mantiene MPL 2.0, que garantiza software libre de forma permanente.

  • Carece de stacks y ephemeral values en su implementación actual.

Para la inmensa mayoría de usuarios, la BSL no restringe nada: solo afecta a quien quiera construir un producto comercial competidor con HashiCorp. El impacto real ha sido psicológico y político, no técnico. La mayor preocupación a medio plazo es la divergencia de features: si stacks aterriza y solo existe en Terraform, los equipos OpenTofu necesitarán soluciones equivalentes, probablemente apoyándose en Terragrunt u orquestación externa.

Qué mirar y qué ignorar

De todas las novedades, las que de verdad cambian el día a día de un equipo son:

  • Import blocks: transforman la adopción de infraestructura existente.

  • Framework de tests: hacen viable el TDD en módulos HCL.

  • Bloque removed: cierra el ciclo declarativo de la gestión de estado.

  • Ephemeral values: reducen la superficie de exposición de secretos.

El resto, incluyendo HCP Terraform renombrado o la lista de novedades menores en providers, afecta poco a quien ya tiene un flujo estable. Stacks merece seguimiento porque puede consolidar herramientas existentes, pero aún es pronto para basar decisiones arquitectónicas en él.

Conclusión

La decisión Terraform vs OpenTofu se reduce a tres preguntas: ¿tienes contrato con HashiCorp o HCP? ¿necesitas stacks o encriptación nativa de estado? ¿qué dice la política interna sobre BSL? Con esas respuestas, la elección cae por su propio peso, y ambas herramientas van a seguir siendo usables durante bastante tiempo.

Fuentes:

  1. HashiCorp: Notas de la versión Terraform 1.6[1]
  2. OpenTofu: Sitio oficial del fork comunitario bajo MPL 2.0[2]
  3. HashiCorp Terraform: Documentación oficial del framework de tests nativos[3]

Preguntas frecuentes

¿Puedo pasar de Terraform a OpenTofu sin reescribir mi configuración ni migrar el estado?

Para una configuración estándar sí: OpenTofu es drop-in compatible, el fichero de estado es intercambiable y los proveedores funcionan idénticamente. Además aporta encriptación nativa del estado, que Terraform no tiene, y mantiene la licencia MPL 2.0. Lo que pierdes en su implementación actual son los ephemeral values y stacks. La decisión depende de si tienes contrato con HashiCorp o HCP, si necesitas esas dos funciones y qué dice la política interna sobre la BSL.

¿Cómo evito que los secretos acaben guardados en el fichero de estado de Terraform?

Con los ephemeral values de Terraform 1.9: valores que se materializan en tiempo de plan o apply pero nunca se escriben al estado. Sirven para contraseñas generadas dinámicamente, tokens obtenidos de Vault o AWS Secrets Manager y credenciales temporales. Antes, incluso con sensitive = true, esos valores acababan cifrados dentro del estado, con el riesgo que implica si el backend se compromete. No resuelve todos los problemas de secretos en IaC, pero reduce la superficie de exposición.

¿Necesito aprender Go para probar mis módulos de Terraform?

Ya no. Desde la versión 1.6 el framework de tests nativo usa ficheros .tftest.hcl con bloques run que ejecutan plan o apply, definen variables específicas del test y añaden aserciones sobre los outputs, todo en HCL. Desde 1.7 los tests corren en paralelo, lo que hace viable una suite amplia en CI. No sustituye a Terratest para pruebas de integración reales contra un proveedor cloud, pero cubre la validación de lógica de módulos.

Fuentes

  1. HashiCorp: Notas de la versión Terraform 1.6
  2. OpenTofu: Sitio oficial del fork comunitario bajo MPL 2.0
  3. HashiCorp Terraform: Documentación oficial del framework de tests nativos