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.
Lo que 1.6 cambió de verdad
La estrella de Terraform 1.6 fueron los bloques import. 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. Un test típico ejecuta un plan sobre el módulo VPC y verifica que el CIDR generado coincide con lo esperado, que el número de subredes es correcto, o que una flag opcional cambia el tipo de NAT. Desde 1.7 estos tests corren en paralelo, lo que hace viable una suite amplia en CI.
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"
}
}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>::funcion(...). 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.
También en 1.8 se mejoró el comportamiento de moved para refactorizar recursos sin destrucción y recreación, algo que ya existía pero ha ganado pulido y mejores mensajes de error cuando las direcciones no casan.
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.
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”. No es una función llamativa, pero elimina un patrón feo que obligaba a usar precondition en outputs o assertions externas.
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 diciembre de 2024, OpenTofu ya tiene un rastro claro. Es drop-in compatible para la mayoría de configuraciones, el estado es intercambiable, y los proveedores funcionan idénticamente. La divergencia visible está en features como la encriptación del fichero de estado (disponible nativamente en OpenTofu, ausente en Terraform), funciones provider-defined pero con una curva de incorporación distinta, y la ausencia en OpenTofu de stacks y ephemeral values. El fork se mantiene bajo MPL 2.0, lo que garantiza software libre de forma permanente.
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. Existing Terraform users no tienen razón urgente para migrar; nuevos proyectos con sensibilidad a licencia pueden elegir OpenTofu sin fricción. 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 los import blocks, el framework de tests, el bloque removed y los ephemeral values. Son mejoras concretas que resuelven dolores reales. 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. Y 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.
