En agosto de 2023 HashiCorp relicenció Terraform bajo la Business Source License (BSL) y, días después, nació OpenTofu como fork bajo la Linux Foundation. Más de dos años después, ambos proyectos publicaron su versión 1.11 y el resultado es paradójico: en esta release convergieron casi en lo mismo —los ephemeral values— mientras la grieta profunda quedó en otro lado. Esta comparativa mira dónde divergieron de verdad.
OpenTofu y Terraform son dos herramientas de Infrastructure as Code (IaC) que gestionan infraestructura declarativa con lenguaje HCL. Terraform pertenece a HashiCorp (hoy parte de IBM) y se distribuye bajo la BSL, una licencia source-available no aprobada por la OSI. OpenTofu es su fork open source bajo MPL 2.0, gobernado por la Linux Foundation. Comparten sintaxis, providers y estado, pero divergen en licencia, gobernanza y features acumuladas.
¿Por qué la versión 1.11 hace parecer que no divergieron?

Porque en la 1.11 ambos aterrizaron la misma característica estrella: los ephemeral values / write-only arguments, valores efímeros que viven solo en memoria durante una fase de ejecución y nunca se persisten en el archivo de estado ni en el plan. Es la respuesta de las dos herramientas al mismo problema histórico: secretos filtrándose al state en texto plano.
- Terraform 1.11 (3 de marzo de 2025, según HashiCorp) introdujo los write-only arguments: argumentos de recursos administrados que aceptan valores efímeros para pasar contraseñas o tokens sin exponerlos. Se versionan con atributos tipo
value_wo_versionpara disparar actualizaciones. - OpenTofu 1.11 (9 de diciembre de 2025, según el blog oficial de OpenTofu) sumó ephemeral resources y write-only attributes equivalentes, más el meta-argumento
enabledenlifecyclecomo alternativa legible acount = 0/1.
Como resume la documentación de HashiCorp: "Ephemeral values in Terraform are not persisted in artifacts like the plan or state file". La misma idea, en las dos herramientas, con nueve meses de diferencia en el calendario. Si mirás solo la 1.11, parecen gemelos.
¿Dónde divergieron de verdad OpenTofu y Terraform?
La divergencia real no está en la 1.11 sino en tres ejes: la licencia, las features exclusivas acumuladas y la gobernanza. Ahí es donde el fork dejó de ser un espejo y se volvió una bifurcación con decisiones propias.
La licencia: MPL 2.0 vs BSL
OpenTofu es open source bajo MPL 2.0; Terraform es source-available bajo la BSL. En la práctica, la BSL permite el uso interno y productivo normal, pero restringe ofrecer Terraform como servicio gestionado que compita con HashiCorp. La diferencia aparece más en la revisión legal y de compras que en el trabajo diario de ingeniería, pero para equipos que construyen plataformas encima de la herramienta, no es un detalle menor.
Las features que uno tiene y el otro no
Acá está el corazón de la divergencia. OpenTofu shippeó, versión tras versión, capacidades que el binario open source de Terraform todavía no tiene:
- State encryption nativa (OpenTofu 1.7, abril de 2024): cifrado configurable del estado y del plan en reposo, con AES-GCM y providers de clave PBKDF2 (passphrase), OpenBao y KMS externos. Era una de las funciones más pedidas durante años y Terraform nunca la shippeó en su binario abierto.
- Provider
for_each(OpenTofu 1.9): instanciar dinámicamente configuraciones de un mismo provider, algo que simplifica escenarios multi-región o multi-cuenta. - Evaluación temprana de variables (OpenTofu 1.8): permite usar variables incluso en la configuración del backend.
- Flag
-exclude(OpenTofu 1.9): el inverso de-target, para excluir recursos de una operación.
Terraform, por su lado, mueve fichas en su propio terreno. En la 1.11 llevó a disponibilidad general el bloqueo de estado nativo del backend S3 con el argumento use_lockfile, deprecando la dependencia de DynamoDB, y consolidó el framework de testing (-junit-xml GA, state_key en bloques run, y override_during = plan para mockear valores en tests unitarios). También agregó el comando terraform modules -json.
La gobernanza: fundación vs empresa
OpenTofu se decide en una fundación con roadmap público y RFCs abiertas; Terraform lo define HashiCorp según su estrategia comercial. Para algunas organizaciones eso es una garantía de neutralidad; para otras, la respaldo corporativo de un vendor con soporte pago es justamente lo que buscan.
Tabla comparativa: OpenTofu 1.11 vs Terraform 1.11
| Criterio | OpenTofu 1.11 | Terraform 1.11 |
|---|---|---|
| Licencia | MPL 2.0 (open source, OSI) | BSL (source-available, no OSI) |
| Gobernanza | Linux Foundation | HashiCorp (IBM) |
| Fecha 1.11.0 | 9 de diciembre de 2025 | 3 de marzo de 2025 |
| Ephemeral / write-only values | Sí | Sí |
| State encryption nativa | Sí (desde 1.7) | No (en el binario abierto) |
Provider for_each | Sí (desde 1.9) | No |
Flag -exclude | Sí (desde 1.9) | No |
| Bloqueo nativo backend S3 | Vía compatibilidad | GA con use_lockfile |
| Costo | Gratuito | Gratuito (CLI); pago en su nube gestionada |
¿Puedo migrar de Terraform a OpenTofu sin romper nada?
En la mayoría de los casos sí, y suele ser un simple reemplazo del binario: OpenTofu lee el estado existente de Terraform directamente y el CLI tofu es drop-in. El detalle crítico es la vuelta: una vez que adoptás features exclusivas de OpenTofu —state encryption a la cabeza—, el camino inverso deja de estar garantizado, porque ese estado cifrado no es compatible con Terraform ni con herramientas de terceros que lean el state directamente.
- Probá en un workspace no productivo primero. Corré
tofu plancontra tu estado actual y verificá que el plan salga vacío (sin drift). - Fijá versiones de providers. El ecosistema de providers es compartido, pero conviene pinnear para evitar sorpresas.
- Decidí conscientemente antes de activar encryption. Es una puerta de ida: mejora la seguridad, pero te ata a OpenTofu.
¿Cuál conviene elegir en 2026?
No hay un ganador absoluto: depende de qué priorices. La honestidad técnica manda por encima del fanatismo por cualquiera de los dos.
- OpenTofu es mejor si valorás una licencia open source real, querés state encryption nativa sin montar un flujo externo, o construís una plataforma interna encima de la herramienta y la BSL te genera fricción legal.
- Terraform es mejor si ya dependés de su ecosistema comercial gestionado, necesitás soporte de vendor con SLA, o tu organización exige el respaldo de un proveedor corporativo con contrato.
- Da bastante igual si usás solo funciones básicas de HCL: la sintaxis y los providers son compatibles, y en la 1.11 hasta los ephemeral values se comportan casi idéntico.
Si estás armando IaC sobre virtualización, esta comparativa se complementa con nuestra nota "Proxmox con Terraform: crear VMs con un API token", donde el flujo aplica casi sin cambios a OpenTofu.
Preguntas frecuentes
¿OpenTofu es un reemplazo directo de Terraform?
Sí, para la mayoría de los proyectos. OpenTofu lee el estado de Terraform y su CLI tofu es drop-in. La compatibilidad se rompe solo cuando adoptás features exclusivas de OpenTofu, como el cifrado de estado.
¿Terraform 1.11 tiene state encryption?
No en su binario open source. El cifrado nativo de estado y plan es exclusivo de OpenTofu, disponible desde la versión 1.7 (abril de 2024). En Terraform hay que resolverlo con herramientas o backends externos.
¿Qué son los write-only arguments de Terraform 1.11?
Son argumentos de recursos administrados que aceptan valores efímeros —contraseñas, tokens— y nunca se persisten en el plan ni en el estado. Se versionan con atributos tipo value_wo_version para disparar actualizaciones.
¿Cuál es gratis?
Ambos CLI son gratuitos. OpenTofu es completamente open source y sin costo. El CLI de Terraform también se usa sin pagar; el cobro de HashiCorp aparece en sus servicios gestionados en la nube, no en la herramienta local.
¿La licencia BSL me impide usar Terraform en producción?
No. La BSL permite el uso interno y productivo normal. Su restricción apunta a ofrecer Terraform como un servicio gestionado que compita con HashiCorp, algo que afecta a proveedores de plataformas, no al uso habitual de un equipo.