Terraform 1.6 en adelante: novedades tras el cambio de licencia

Actualizado: 2026-05-03

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, con Terraform 1.9 ya en producción y OpenTofu 1.8 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 corren 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, la mayoría de equipos siguen apañándose 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: 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 la mayoría de configuraciones; 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.