OpenTofu nació hace menos de tres años como respuesta al cambio de licencia de Terraform, pero empieza a ser difícil describirlo simplemente como un fork abierto. La llegada de OpenTofu 1.12 confirma que el proyecto mantiene una elevada compatibilidad con Terraform mientras desarrolla funciones propias como destroy = false, prevent_destroy dinámico o el cifrado de los archivos de estado y planes. El resultado es que los equipos que trabajan con Infrastructure as Code (IaC) tienen ya dos caminos con diferencias técnicas, comerciales y de gobernanza.
Las claves de OpenTofu 1.12 frente a Terraform en 20 segundos
- OpenTofu nació en 2023 después de que HashiCorp cambiara Terraform de MPL 2.0 a Business Source License (BSL).
- Está gestionado bajo la Linux Foundation y mantiene licencia MPL 2.0.
- OpenTofu 1.12 incorpora
prevent_destroydinámico ydestroy = false. - También dispone de cifrado nativo de estados y planes.
- Su compatibilidad con Terraform reduce considerablemente el trabajo necesario para probar una migración.
Para un administrador acostumbrado a Terraform, probablemente lo primero que sorprenda al instalar OpenTofu sea precisamente lo poco que sorprende.
Los archivos .tf, HashiCorp Configuration Language (HCL), módulos, proveedores y buena parte del flujo de trabajo continúan resultando familiares. Donde antes se ejecutaba terraform init, terraform plan o terraform apply, OpenTofu utiliza tofu init, tofu plan y tofu apply.
Eso no es accidental. El proyecto se presenta como un reemplazo directo de Terraform y actualmente afirma disponer de un ecosistema de más de 3.900 proveedores y 23.600 módulos. La compatibilidad, sin embargo, no significa que ambos proyectos vayan a evolucionar indefinidamente de la misma manera.
Por qué nació OpenTofu
Para entender la comparación hay que regresar a agosto de 2023.
Hasta entonces Terraform se distribuía bajo la licencia abierta Mozilla Public License 2.0 (MPL 2.0). HashiCorp decidió cambiar las futuras versiones de varios de sus productos, incluido Terraform, a la Business Source License 1.1.
Terraform siguió siendo utilizable gratuitamente en muchos escenarios. HashiCorp especifica que el uso interno dentro de una organización está permitido, incluida la utilización de Terraform dentro de procesos de integración y despliegue continuo para gestionar infraestructura propia.
La diferencia afecta especialmente a determinados usos comerciales.
La licencia limita el empleo del software para ofrecer a terceros productos alojados o integrados que compitan con las versiones comerciales de HashiCorp. Por tanto, describir el cambio simplemente como que «Terraform pasó a ser de pago» sería incorrecto. La cuestión estaba relacionada con las condiciones bajo las que terceros podían construir determinados negocios utilizando su código.
También conviene separar cronológicamente este movimiento de la posterior compra de HashiCorp por IBM. El cambio de licencia fue anunciado en agosto de 2023, mientras que IBM anunció su acuerdo para adquirir HashiCorp en abril de 2024.
Una parte de la comunidad respondió creando OpenTF, un fork basado en la última base de Terraform disponible bajo MPL.
En septiembre de 2023 el proyecto pasó a la Linux Foundation y adoptó su actual nombre: OpenTofu. Su primera versión estable para producción, OpenTofu 1.6, llegó en enero de 2024.
Desde entonces los dos proyectos siguen caminos diferentes.
Terraform permanece dentro del ecosistema comercial de HashiCorp, actualmente propiedad de IBM, mientras OpenTofu mantiene una gobernanza comunitaria bajo la Linux Foundation y continúa distribuyéndose bajo MPL 2.0.
OpenTofu 1.12 ya incorpora funciones propias
La compatibilidad sigue siendo una de sus mayores ventajas, pero OpenTofu ya no se limita a reproducir las capacidades heredadas de Terraform.
La versión 1.12.0, publicada el 14 de mayo de 2026, introduce varias mejoras interesantes para administradores de sistemas, equipos DevOps y responsables de plataformas.
Una de ellas es prevent_destroy dinámico.
Hasta ahora esta protección obligaba a tomar una decisión estática dentro de la configuración. OpenTofu 1.12 permite utilizar variables y otros valores disponibles dentro del módulo.
Esto permite, por ejemplo, crear un mismo módulo para bases de datos que impida por defecto eliminar recursos en producción, pero permita hacerlo en entornos de desarrollo.
variable "prevent_destroy_database" {
type = bool
default = true
}
resource "example_database" "database" {
lifecycle {
prevent_destroy = var.prevent_destroy_database
}
}El mismo módulo puede así comportarse de manera diferente dependiendo del entorno sin tener que mantener variantes independientes.
Otra novedad especialmente práctica es:
destroy = falseEsta opción modifica lo que ocurre cuando OpenTofu deja de gestionar un recurso.
Normalmente eliminar un recurso de la configuración puede provocar que la herramienta planifique también la eliminación de la infraestructura asociada. Con destroy = false, OpenTofu puede retirar el objeto de su state sin destruir el recurso real.
Es una diferencia importante.
La máquina virtual, base de datos, volumen o recurso cloud continúa existiendo, pero OpenTofu deja de administrarlo.
Puede resultar útil durante migraciones, reorganizaciones de infraestructura o situaciones donde determinados recursos deban abandonar el control de IaC sin ser eliminados.
También exige precaución: una vez olvidado el recurso, OpenTofu deja de conocerlo. Si posteriormente se vuelve a declarar con la misma dirección podría intentar crear otro, por lo que podría ser necesario importarlo nuevamente.
OpenTofu 1.12 también mejora la gestión de checksums de proveedores, permite generar simultáneamente salida legible para personas y JSON mediante -json-into y paraleliza determinadas solicitudes durante la instalación de proveedores para acelerar tofu init.
El cifrado del state es una diferencia especialmente interesante
Una de las capacidades propias más relevantes había llegado anteriormente, con OpenTofu 1.7: State and Plan Encryption.
El state es una de las piezas más delicadas de cualquier infraestructura gestionada mediante Terraform u OpenTofu.
Puede contener direcciones IP, identificadores de recursos, configuraciones y, dependiendo de los proveedores utilizados y de cómo esté diseñada la infraestructura, información sensible.
OpenTofu permite cifrar los archivos de state y plan en reposo, tanto cuando se almacenan localmente como cuando se utiliza un backend compatible.
También puede utilizar el cifrado con terraform_remote_state.
La funcionalidad no sustituye una política adecuada de permisos, gestión de secretos y protección del backend. Además introduce otra responsabilidad: perder las claves utilizadas para cifrar el estado puede hacer imposible recuperarlo.
Pero disponer del cifrado integrado directamente en la herramienta añade una capa que puede resultar interesante para organizaciones con requisitos estrictos de seguridad.
OpenTofu vs Terraform: principales diferencias en 2026
Aunque comparten origen, la comparación ya empieza a mostrar dos filosofías distintas.
| Característica | OpenTofu | Terraform |
|---|---|---|
| Infrastructure as Code | Sí | Sí |
| Lenguaje HCL | Sí | Sí |
| Proveedores Terraform | Alta compatibilidad | Nativos |
| Módulos existentes | Alta compatibilidad | Sí |
| Licencia del núcleo actual | MPL 2.0 | BSL 1.1 |
| Gobernanza | Linux Foundation | HashiCorp / IBM |
| Uso interno gratuito | Sí | Sí |
| State Encryption integrado | Sí | Depende del backend/plataforma |
prevent_destroy dinámico | Sí en 1.12 | Diferencias según versión |
destroy = false | Sí en 1.12 | Diferencias de implementación |
| Producto comercial integrado | Ecosistema de terceros | HCP Terraform |
| Objetivo | IaC abierto y neutral | IaC + plataforma HashiCorp |
La tabla tampoco debería interpretarse como que OpenTofu es automáticamente superior.
Terraform conserva una enorme base instalada, documentación, experiencia acumulada, integraciones empresariales y la plataforma comercial desarrollada durante años por HashiCorp.
Además, IBM completó la adquisición de HashiCorp en 2025, por lo que Terraform forma ahora parte de un grupo tecnológico con una presencia empresarial enorme.
OpenTofu compite desde otra posición: compatibilidad, licencia abierta y gobernanza independiente de un único fabricante.
La migración de Fidelity demuestra que ya no es solo para laboratorios
Quizá uno de los datos que mejor muestra la madurez alcanzada por OpenTofu procede de Fidelity Investments.
La propia organización explicó su experiencia en una entrevista publicada por OpenTofu.
Las dimensiones de su infraestructura permiten hacerse una idea:
| Infraestructura gestionada | Escala comunicada |
| Aplicaciones | Más de 2.000 |
| State files | Más de 50.000 |
| Recursos cloud | Más de 4 millones |
| Actualizaciones de state diarias | Hasta 4.000 |
Fidelity explicó que el cambio de licencia de Terraform abrió internamente la conversación sobre alternativas y que la gobernanza abierta de OpenTofu encajaba con su estrategia.
Pero había otra condición indispensable: la compatibilidad técnica.
Migrar una organización con millones de recursos sería mucho más complicado si fuera necesario reescribir toda su infraestructura. Fidelity señaló precisamente que considerar OpenTofu como un reemplazo técnico directo hizo viable estudiar el cambio.
Esto no demuestra que todas las organizaciones deban migrar, pero sí desmonta una percepción que acompañó al proyecto durante sus primeros meses: OpenTofu ya no puede considerarse únicamente una alternativa experimental para entusiastas del open source.
¿Es OpenTofu realmente compatible con Terraform?
En términos prácticos, la compatibilidad continúa siendo elevada, especialmente para configuraciones convencionales.
Un proyecto existente puede ser un buen candidato para probar:
tofu init
tofu planantes de realizar cualquier cambio.
Pero «drop-in replacement» tampoco debe entenderse como una garantía de compatibilidad perpetua.
Desde el fork ambos proyectos incorporan características independientemente. Cuanto más tiempo transcurra y más funciones exclusivas utilice una infraestructura, mayor puede ser la divergencia.
Por eso una migración empresarial debe revisar al menos:
- versión de Terraform utilizada;
- proveedores y versiones;
- módulos internos y externos;
- backend del state;
- automatizaciones CI/CD;
- Terraform Cloud/HCP Terraform;
- funciones específicas utilizadas;
- herramientas externas que dependan directamente del CLI o sus salidas.
Para proyectos que utilizan principalmente Terraform CLI, HCL, proveedores convencionales y backends estándar, evaluar OpenTofu puede resultar relativamente sencillo.
Una organización profundamente integrada con HCP Terraform y otros productos de HashiCorp tendrá más elementos que analizar.
Entonces, ¿Terraform u OpenTofu?
No existe una respuesta universal.
Terraform continúa teniendo sentido para organizaciones ya estandarizadas sobre HashiCorp, especialmente cuando utilizan HCP Terraform y valoran disponer de una plataforma empresarial integrada, soporte comercial y un ecosistema construido durante años.
OpenTofu resulta especialmente atractivo cuando la prioridad está en mantener la capa de Infrastructure as Code bajo una licencia open source, reducir la dependencia de un único proveedor o disponer de características propias como State Encryption.
También existe una tercera situación bastante habitual: empresas que no necesitan decidir inmediatamente.
Una organización puede mantener Terraform para infraestructura existente y empezar a evaluar OpenTofu en nuevos proyectos o laboratorios. Su elevada compatibilidad permite realizar pruebas sin adoptar desde el primer momento una migración general.
Ese probablemente sea uno de los mayores logros de OpenTofu.
En 2023 la pregunta era si una comunidad sería capaz de mantener un fork viable de Terraform. En 2026 la cuestión empieza a ser diferente: qué herramienta encaja mejor con cada estrategia de Infrastructure as Code.
Terraform sigue siendo uno de los grandes estándares de IaC y cuenta ahora con el respaldo empresarial de IBM. OpenTofu ha conseguido construir alrededor de la misma experiencia conocida una alternativa gobernada por la Linux Foundation que además empieza a incorporar capacidades propias.
La competencia ya no consiste necesariamente en que uno sustituya al otro. La existencia de dos proyectos con modelos de gobernanza y evolución diferentes ofrece a administradores, equipos DevOps y responsables de plataforma algo que durante años apenas tuvieron en este ámbito: una elección real.
Preguntas frecuentes
¿Qué es OpenTofu?
OpenTofu es una herramienta open source de Infrastructure as Code basada originalmente en un fork de Terraform. Está gestionada bajo la Linux Foundation, utiliza licencia MPL 2.0 y mantiene una elevada compatibilidad con configuraciones y proveedores del ecosistema Terraform.
¿OpenTofu puede utilizar archivos de Terraform?
En muchos proyectos sí. OpenTofu mantiene compatibilidad con HCL, módulos y buena parte del ecosistema de proveedores, aunque una migración debe probarse antes de aplicarla en producción, especialmente cuando existen integraciones específicas con productos de HashiCorp.
¿Terraform sigue siendo gratuito?
Sí para numerosos casos de uso. HashiCorp permite expresamente el uso interno bajo su Business Source License. Las restricciones afectan principalmente a determinados productos comerciales que ofrecen Terraform alojado o integrado y compiten con productos de pago de HashiCorp.
¿Qué novedades incorpora OpenTofu 1.12?
Entre las principales novedades están prevent_destroy dinámico, destroy = false, mejoras en los checksums e instalación de proveedores y la posibilidad de generar simultáneamente salida humana y JSON. OpenTofu también dispone desde versiones anteriores de cifrado nativo para archivos de state y plan.
