OpenTofu ha dejado de ser simplemente el fork de Terraform surgido tras el cambio de licencia de HashiCorp. Con OpenTofu 1.12, el proyecto bajo la Linux Foundation mantiene una experiencia muy familiar para quienes administran infraestructura con Terraform, pero incorpora funciones propias que empiezan a diferenciarlo: prevent_destroy dinámico, destroy = false, cifrado del state y los planes o mejoras en la gestión de proveedores. Para desarrolladores, administradores de sistemas, equipos DevOps y Platform Engineering, ya existe una alternativa que merece ser evaluada en entornos reales.
Las claves de OpenTofu 1.12 en 30 segundos
- OpenTofu nació en 2023 como fork de la última base de Terraform disponible bajo MPL 2.0 y actualmente está bajo la Linux Foundation.
- Mantiene HCL, providers, módulos y comandos muy similares a Terraform, reduciendo la curva de aprendizaje.
- OpenTofu 1.12 añade
prevent_destroydinámico ydestroy = false. - El proyecto también ofrece cifrado nativo para archivos de state y plan.
- Fidelity Investments ha documentado su adopción en una plataforma con más de 4 millones de recursos cloud.
Para alguien que lleve años utilizando Terraform, la primera experiencia con OpenTofu puede resultar incluso anticlimática. Se instala la herramienta, se entra en un proyecto conocido y los comandos cambian poco:
tofu init
tofu plan
tofu applyLos archivos continúan siendo .tf, la configuración utiliza HashiCorp Configuration Language (HCL) y conceptos como resources, data sources, variables, outputs, providers, modules o state siguen formando parte del flujo de trabajo.
Esa familiaridad es probablemente una de las principales razones por las que OpenTofu se ha convertido en un competidor serio. No intenta convencer a los administradores para que aprendan desde cero otra forma de trabajar con Infrastructure as Code (IaC). Parte de un modelo que ya conocen miles de equipos.
De Terraform a OpenTofu: por qué existe el proyecto
El origen está en agosto de 2023, cuando HashiCorp anunció que las nuevas versiones de Terraform y otros productos dejarían de publicarse bajo Mozilla Public License 2.0 (MPL 2.0) para utilizar Business Source License (BSL) 1.1.
El cambio no convirtió Terraform en una herramienta de pago para cualquier usuario. Terraform continúa pudiendo utilizarse gratuitamente en numerosos escenarios, incluido el uso interno dentro de una empresa.
La diferencia estaba principalmente en determinadas actividades comerciales. BSL introdujo restricciones para organizaciones que utilizaran los productos de HashiCorp para desarrollar ofertas comerciales que compitieran con sus propios servicios.
Una parte de la comunidad respondió creando OpenTF a partir de la última base disponible bajo MPL 2.0. Poco después el proyecto entró en la Linux Foundation y pasó a llamarse OpenTofu.
También conviene aclarar una confusión habitual: el cambio de licencia no fue consecuencia de la compra de HashiCorp por IBM. HashiCorp modificó la licencia en agosto de 2023; IBM anunció el acuerdo de adquisición en abril de 2024 y completó posteriormente la operación.
Tres años después, la discusión ya no gira únicamente alrededor de las licencias. OpenTofu ha empezado a introducir características técnicas propias.
Qué aporta OpenTofu 1.12 a un administrador de sistemas
Una de las novedades más prácticas de OpenTofu 1.12 es la posibilidad de utilizar valores dinámicos con prevent_destroy.
La protección sirve para evitar que una operación de infraestructura elimine accidentalmente un recurso especialmente delicado.
El caso típico podría ser una base de datos:
variable "protect_database" {
type = bool
default = true
}
resource "example_database" "production" {
lifecycle {
prevent_destroy = var.protect_database
}
}Lenguaje del código: JavaScript (javascript)Esto permite que un mismo módulo cambie su política dependiendo del entorno.
Una organización podría establecer:
protect_database = trueLenguaje del código: JavaScript (javascript)en producción y:
protect_database = falseLenguaje del código: JavaScript (javascript)en un laboratorio temporal.
La diferencia puede parecer pequeña, pero facilita crear módulos reutilizables sin duplicar configuraciones únicamente para cambiar las políticas del ciclo de vida.
Otra novedad interesante es destroy = false.
El problema que intenta solucionar aparece con frecuencia durante migraciones y reorganizaciones de infraestructura: se quiere dejar de gestionar un recurso mediante IaC, pero no eliminarlo realmente.
OpenTofu 1.12 permite expresarlo directamente:
removed {
from = example_server.legacy
lifecycle {
destroy = false
}
}Lenguaje del código: JavaScript (javascript)El recurso desaparece del state administrado por OpenTofu, pero la infraestructura real continúa funcionando.
Puede resultar útil para retirar una máquina virtual, volumen, base de datos u otro objeto de un proyecto sin destruirlo.
Naturalmente, esto requiere disciplina. Desde ese momento OpenTofu deja de conocer el recurso. Si posteriormente vuelve a gestionarse mediante IaC habrá que revisar su importación y evitar crear accidentalmente un duplicado.
State Encryption: proteger uno de los archivos más delicados de IaC
Una diferencia técnica especialmente interesante para administradores es el cifrado nativo de state y plan, disponible desde versiones anteriores de OpenTofu.
Cualquier equipo que haya trabajado con Terraform sabe que el state merece un tratamiento especial.
Un archivo de estado puede contener:
- identificadores de infraestructura;
- nombres y direcciones de recursos;
- configuraciones internas;
- metadatos de proveedores;
- valores que pueden resultar sensibles.
Por eso guardar alegremente terraform.tfstate en un repositorio Git nunca ha sido una buena práctica.
Los backends remotos pueden proporcionar controles de acceso y cifrado, pero OpenTofu decidió incorporar además un mecanismo propio de State and Plan Encryption.
La configuración permite utilizar distintos métodos de gestión de claves y cifrar los datos antes de almacenarlos.
Esto tampoco elimina la necesidad de proteger correctamente las credenciales o controlar quién puede acceder al backend. Añade otra capa de seguridad, con una contrapartida evidente: si se pierden las claves necesarias para descifrar el state, recuperar la infraestructura administrada puede convertirse en un problema serio.
Terraform y OpenTofu se parecen mucho, pero ya no son lo mismo
La elevada compatibilidad puede llevar a pensar que elegir entre ambos consiste simplemente en sustituir un ejecutable.
Todavía puede ser así en muchos proyectos sencillos, pero cada nueva versión aumenta la posibilidad de divergencias.
| Aspecto | OpenTofu | Terraform |
|---|---|---|
| Infrastructure as Code | Sí | Sí |
| HCL | Sí | Sí |
Archivos .tf | Sí | Sí |
| Providers | Amplia compatibilidad | Ecosistema original |
| Módulos Terraform | Amplia compatibilidad | Sí |
| CLI | tofu | terraform |
| Licencia | MPL 2.0 | BSL 1.1 |
| Gobernanza | Linux Foundation | HashiCorp / IBM |
| State Encryption integrado | Sí | Protección ligada también al backend/plataforma |
prevent_destroy dinámico | Sí, en 1.12 | Evolución independiente |
destroy = false | Sí, en 1.12 | Evolución independiente |
| Plataforma SaaS propia | No equivalente directo | HCP Terraform |
Terraform conserva ventajas importantes. Su ecosistema lleva años utilizándose en producción y HashiCorp dispone de HCP Terraform, además de soporte empresarial e integración con otros productos de su plataforma.
OpenTofu apuesta por otra propuesta: mantener el núcleo abierto bajo MPL 2.0 y una gobernanza independiente dentro de la Linux Foundation.
No son exactamente dos productos dirigidos a públicos completamente distintos. Son dos ramas que parten de una historia común y que cada vez evolucionan con mayor independencia.
Probar una migración desde Terraform
Para muchos administradores, la pregunta práctica será mucho más sencilla: ¿qué ocurre al ejecutar OpenTofu sobre una infraestructura que ya utiliza Terraform?
En proyectos compatibles, una primera evaluación puede comenzar en un entorno de pruebas con:
tofu init
tofu planPero ejecutar directamente tofu apply sobre producción sin revisar el plan sería una mala idea.
Antes de plantear una migración conviene comprobar al menos:
- versión actual de Terraform;
- versiones de providers;
- módulos utilizados;
- backend donde reside el state;
- bloqueo del state;
- scripts que invoquen
terraform; - pipelines de CI/CD;
- integraciones con HCP Terraform;
- herramientas que procesen la salida JSON;
- funciones específicas de Terraform utilizadas por los módulos.
También es recomendable realizar copias del state antes de cualquier migración.
Un entorno de CI/CD, por ejemplo, puede contener decenas de referencias directas:
terraform init
terraform validate
terraform plan
terraform applyque tendrán que revisarse aunque el código HCL sea perfectamente compatible.
OpenTofu también puede gestionar Proxmox, OpenStack, AWS o Kubernetes
La utilidad de estas herramientas no está limitada a los grandes hiperescalares.
Mediante providers pueden utilizarse para administrar numerosos tipos de infraestructura.
Un administrador podría definir mediante IaC una combinación de:
OpenTofu
│
├── Proxmox VE
├── OpenStack
├── Kubernetes
├── AWS
├── Azure
├── Google Cloud
├── Cloudflare
└── otros providersEsto resulta especialmente interesante para organizaciones con infraestructura híbrida.
Por ejemplo, una empresa podría utilizar OpenTofu para aprovisionar máquinas virtuales en OpenStack, configurar recursos DNS, desplegar posteriormente Kubernetes y entregar las aplicaciones mediante otra capa de automatización.
La idea continúa siendo la misma que hizo popular a Terraform: la infraestructura deja de configurarse exclusivamente mediante paneles y comandos manuales para convertirse en código versionable y reproducible.
OpenTofu ya se utiliza en infraestructuras de millones de recursos
El proyecto también empieza a aportar referencias que van más allá de pequeños laboratorios.
OpenTofu publicó el caso de Fidelity Investments, cuya plataforma de infraestructura gestiona una escala considerable:
| Elemento | Escala comunicada |
|---|---|
| Aplicaciones | Más de 2.000 |
| State files | Más de 50.000 |
| Recursos cloud | Más de 4 millones |
| Actualizaciones diarias del state | Hasta 4.000 |
La experiencia de Fidelity resulta relevante porque uno de los mayores interrogantes alrededor de cualquier fork es su capacidad para pasar de proyectos personales a grandes organizaciones.
Un despliegue de millones de recursos obliga a considerar compatibilidad, automatización, providers, rendimiento, actualizaciones y mantenimiento a largo plazo.
No demuestra que OpenTofu sea automáticamente mejor que Terraform, pero sí que ya existen implementaciones empresariales suficientemente grandes como para considerarlo una opción de producción.
¿Qué deberían elegir desarrolladores y administradores?
Para un proyecto nuevo, la decisión depende menos de la sintaxis que hace tres años.
Quien necesite integración estrecha con el entorno comercial de HashiCorp, utilice HCP Terraform o tenga una infraestructura ya estandarizada sobre sus herramientas encontrará pocos motivos para realizar una migración únicamente por seguir una tendencia.
Terraform continúa siendo una plataforma madura y ampliamente utilizada.
OpenTofu gana atractivo cuando se busca IaC con licencia open source, gobernanza bajo la Linux Foundation y menor dependencia de las decisiones comerciales de un único fabricante.
Para un administrador que empieza desde cero, probar ambos resulta relativamente sencillo precisamente porque comparten buena parte de los conceptos.
Y para quien ya utiliza Terraform, probablemente el experimento más interesante no sea iniciar inmediatamente una migración, sino ejecutar OpenTofu sobre una copia de un proyecto real y observar el resultado de tofu plan.
Tres años atrás OpenTofu tenía que demostrar que podía sobrevivir como fork. Ahora la situación es diferente. Sigue teniendo mucho del ADN de Terraform, pero características como State Encryption, destroy = false y el prevent_destroy dinámico muestran que ya ha empezado a construir su propia interpretación de cómo debería evolucionar Infrastructure as Code.
Terraform tiene así algo que durante mucho tiempo apenas tuvo: un competidor técnicamente familiar, compatible con buena parte de su ecosistema y suficientemente diferente como para obligar a los equipos de infraestructura a valorar cuál de los dos modelos encaja mejor en sus sistemas.
Preguntas frecuentes
¿OpenTofu es compatible con Terraform?
Mantiene una compatibilidad elevada con HCL, módulos, providers y muchos proyectos existentes de Terraform. Sin embargo, ambos proyectos evolucionan de forma independiente, por lo que cualquier migración debe probarse antes de aplicarse en producción.
¿Se puede utilizar OpenTofu con Proxmox VE u OpenStack?
Sí, siempre que exista un provider compatible con los recursos que se quieran gestionar. OpenTofu no está limitado a AWS, Azure o Google Cloud y puede utilizarse en infraestructuras privadas e híbridas.
¿Qué diferencia hay entre terraform apply y tofu apply?
Conceptualmente realizan la misma operación: aplicar el plan necesario para llevar la infraestructura al estado definido en el código. La diferencia es que cada comando pertenece a una herramienta distinta y sus capacidades pueden divergir según las versiones.
¿Merece la pena migrar de Terraform a OpenTofu?
Depende del entorno. Para organizaciones que valoran la licencia MPL 2.0, la gobernanza de la Linux Foundation o determinadas funciones propias, OpenTofu merece una evaluación. Una empresa muy integrada con HCP Terraform debe analizar más componentes antes de cambiar.
