Abra un módulo de Terraform hoy y se enfrentará a una pregunta que no existía hace tres años: ¿el binario que ejecuta este código es terraform, o es tofu? IBM completó su adquisición de HashiCorp el 27 de febrero de 2025, por 6.400 millones de dólares, OpenTofu se convirtió en un proyecto CNCF Sandbox el 23 de abril de 2025, y la ruta de migración entre ambas herramientas ya está documentada oficialmente. La decisión ya no es hipotética.
Este artículo está escrito desde una perspectiva de operaciones de infraestructura, no desde la de una plataforma Terraform gestionada. El objetivo es separar los costes reales de migración del ruido de licencias y gobernanza. Eso significa que puedo ser directo sobre qué se rompe durante la migración, las preguntas legítimas de gobernanza y los casos en los que quedarse con Terraform es la decisión correcta.
Este artículo cubre cuatro cosas: qué es OpenTofu en 2026, las funciones que Terraform no tiene, cómo es la migración en la práctica y una recomendación clara para los escenarios de decisión más comunes.
La versión corta
- OpenTofu es un fork de código abierto de Terraform, con licencia MPL 2.0, alojado por la Linux Foundation, y proyecto CNCF Sandbox desde el 23 de abril de 2025. Se bifurcó de Terraform 1.5.x después de que HashiCorp pasara Terraform a la Business Source License en agosto de 2023.
- A fecha de 26 de julio de 2026, la versión de mantenimiento actual es v1.12.5; el repositorio de GitHub tiene más de 29.000 estrellas, y el sitio oficial del proyecto OpenTofu enumera más de 3.900 providers y más de 23.600 módulos.
- Incluye capacidades exclusivas de OpenTofu o en las que OpenTofu va por delante, que Terraform no iguala actualmente de la misma forma: cifrado del state y los planes en el cliente, provider
for_each, la evaluación temprana de variables, el meta-argumentoenabledy dynamicprevent_destroy. Los recursos efímeros no son exclusivos de OpenTofu; Terraform los admite desde la 1.10. - Para un proyecto pequeño de Terraform 1.5.x con state local o en S3, el camino sencillo puede ser una migración corta y reversible. Las referencias de CI/CD, los flujos específicos de HCP y los cambios en el bloqueo de dependencias son donde el trabajo se expande.
- Para un nuevo proyecto de IaC en 2026, empieza con OpenTofu. Para un despliegue de Terraform ya existente, cambia cuando la BSL te limite, cuando necesites una función que OpenTofu tiene y Terraform no, o cuando la hoja de ruta controlada por IBM sea una preocupación real. Si no, la relación coste-beneficio es escasa.
Qué es OpenTofu en 2026
OpenTofu es un fork de código abierto de Terraform, alojado por la Linux Foundation, aceptado en la CNCF como proyecto Sandbox el 23 de abril de 2025, y licenciado bajo la Mozilla Public License 2.0. El binario es tofu. El lenguaje de configuración es HCL, el mismo HCL que usa Terraform. Para la mayoría de los proyectos de tamaño simple a medio, una base de código de Terraform existente se ejecuta sin cambios en OpenTofu.
El fork comenzó en agosto de 2023, después de que HashiCorp pasara Terraform de la MPL 2.0 a la Business Source License 1.1 el 10 de agosto de 2023. La BSL es "source-available" en lugar de aprobada por la OSI, y restringe el uso en producción que "compita con las ofertas comerciales de HashiCorp". A los cinco días se publicó el OpenTF Manifesto y se anunció un fork. El anuncio de la Linux Foundation presentó formalmente OpenTofu el 20 de septiembre de 2023.
El anuncio de la Linux Foundation mencionó a Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver y Terramate entre los apoyos fundadores, con al menos 18 ingenieros comprometidos a tiempo completo durante un mínimo de cinco años. OpenTofu se bifurcó de Terraform 1.5.x, la última versión con MPL 2.0.
En qué punto está el proyecto hoy: v1.12.5 es la versión de mantenimiento actual, y el sitio oficial enumera más de 3.900 providers y más de 23.600 módulos. Las señales de adopción ya no se limitan al impulso inicial del fork de protesta: un estudio de caso sobre la migración de Fidelity describe un programa que abarca más de 50.000 archivos de state y cuatro millones de recursos.
El contexto empresarial relevante: IBM completó su adquisición de HashiCorp el 27 de febrero de 2025, por 6.400 millones de dólares. La hoja de ruta de Terraform ahora se define dentro de un proveedor mucho más grande. Eso no es automáticamente bueno ni malo para los usuarios, pero forma parte del cálculo que hacen los equipos en 2026.
En qué se diferencia OpenTofu de Terraform
Desde el fork, ambos proyectos han seguido caminos de funciones distintos. La tabla siguiente es la versión corta; las notas que la acompañan explican qué cambia cada diferencia para quienes lo usan en la práctica.
| Característica | OpenTofu | Terraform | Desde |
|---|---|---|---|
| Cifrado del state en el cliente | Nativo (PBKDF2, AWS KMS, GCP KMS, OpenBao) | Gestionado por el backend en reposo | v1.7 (abr. 2024) |
| Evaluación temprana de variables | Sí | No compatible | v1.8 |
Proveedor for_each | Sí | Sin equivalente nativo | v1.9 |
| Recursos efímeros | Sí | Sí, desde Terraform 1.10 | OpenTofu v1.11 / Terraform v1.10 |
enabled meta-argumento | Sí | No compatible | v1.11 (dic. 2025) |
Dynamic prevent_destroy | Sí | Solo estático | v1.12 (mayo 2026) |
| Licencia | MPL 2.0 (aprobada por la OSI) | BSL 1.1 (no aprobada por la OSI) | N/A |
El cifrado del state en el cliente (v1.7.0, 30 de abril de 2024). OpenTofu puede cifrar los archivos de state y plan dentro de la propia herramienta con PBKDF2, AWS KMS, GCP KMS u OpenBao. Terraform, en general, delega el cifrado en reposo al backend elegido, mientras que el state local permanece en texto plano. El cifrado en el cliente de OpenTofu puede proteger un objeto de state robado o un plan en caché, siempre que la clave de descifrado no se exponga junto a él. No sustituye a TLS, a los controles de acceso del backend ni a la disciplina de gestión de secretos.
La configuración se ve más o menos así:
terraform {
encryption {
key_provider "pbkdf2" "passphrase" {
passphrase = var.tofu_state_passphrase
}
method "aes_gcm" "default" {
keys = key_provider.pbkdf2.passphrase
}
state {
method = method.aes_gcm.default
}
}
}Proveedor for_each (v1.9). Puedes iterar sobre configuraciones de provider igual que iteras sobre recursos. En configuraciones multirregión o multicuenta, esto elimina toda una categoría de soluciones alternativas que se arrastraba desde hace tiempo. Ya no necesitas crear a mano un provider con alias por región; puedes controlar todo desde un único bloque impulsado por un map.
Evaluación temprana de variables (v1.8). Ahora se pueden referenciar variables en lugares antes restringidos, incluidos los argumentos de backend y de source de módulo. Esto resulta útil cuando un único módulo raíz gobierna varios entornos que solo difieren en un pequeño conjunto de variables.
Los recursos efímeros y el enabled meta-argumento (v1.11.0, 9 de diciembre de 2025). OpenTofu 1.11 añadió los recursos efímeros y el meta-argumento enabled . Los recursos efímeros solo existen dentro de un único ciclo plan/apply y no persisten en el state, lo cual es útil para credenciales de corta duración. No son exclusivos de OpenTofu: Terraform los introdujo en la 1.10 y añadió argumentos write-only en la 1.11. La capacidad específica de OpenTofu aquí es enabled, que activa o desactiva un bloque de recurso a partir de una expresión, sin necesidad de recurrir a la gimnasia del count condicional.
Dynamic prevent_destroy (v1.12). de Terraform prevent_destroy solo acepta valores literales. OpenTofu 1.12 permite calcularlo, de modo que un mismo módulo puede dejar staging destruible mientras protege producción.
La fila de la licencia es la diferencia estructural que no aparece como una función. La MPL 2.0 está aprobada por la OSI y es copyleft a nivel de archivo. La licencia BSL 1.1 de Terraform es "source-available", incluye una restricción de uso adicional, y pasa a MPL 2.0 cuatro años después de la publicación de cada obra licenciada. Para la mayoría de los equipos el efecto práctico es pequeño; para proveedores que construyen algo cercano a las ofertas comerciales de HashiCorp, es la razón misma por la que existe el fork.
Migración: qué se rompe en realidad
La guía de migración oficial es deliberadamente corto y reversible: haz una copia de seguridad del state y el código, instala OpenTofu, ejecuta tofu init, compara el resultado de tofu plan, y prueba un cambio pequeño. Las partes difíciles no son los comandos. Son las referencias de CI/CD que lo rodean, los flujos específicos de HCP, los cambios en el bloqueo de dependencias y la revisión organizativa que conlleva adoptar un fork.
El camino sencillo
Para un proyecto que no usa HCP Terraform y que no tiene miles de referencias a terraform en sus pipelines, la migración es sencilla.
# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak
# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone
# Re-initialize against the OpenTofu registry.
tofu init -upgrade
# Verify parity with what Terraform was doing.
tofu plantofu plan debería coincidir con el plan que produjo Terraform. Si hay una diferencia inesperada, revisa las versiones de los providers, la configuración del backend y cualquier función de Terraform posterior a la 1.5.x antes de aplicar.
Hay dos matices que importan antes de ejecutar nada. Primero, OpenTofu es, en general, compatible en configuración con el HCL al estilo Terraform para los casos que describe esta guía, pero las funciones añadidas después de Terraform 1.5.x aún requieren una comprobación de compatibilidad. Segundo, tofu init -upgrade puede actualizar .terraform.lock.hcl, incluidas las direcciones de origen de los providers y las entradas de checksum. Revisa esos metadatos por separado de la deriva de infraestructura.
Los obstáculos reales
Tres cosas pueden convertir una migración rápida por CLI en un proyecto de plataforma mucho más amplio. Ninguna de ellas es un fallo.
Los workspaces de HCP Terraform. OpenTofu incluye integraciones cloud y remote para servicios remote compatibles, incluido HCP Terraform en escenarios de ejecución local y almacenamiento del state. La parte más difícil es la ejecución remote específica de HCP y las funciones de plataforma: Sentinel, los run triggers, las credenciales dinámicas, Stacks, y cualquier comportamiento de servicio que OpenTofu no pueda probar o admitir por completo. Si esos elementos son centrales, pilota primero un solo workspace; si estás abandonando HCP, migra el state y recrea esos controles de plataforma.
Consejo: dejar HCP Terraform puede ser el coste oculto más importante cuando el parque depende de flujos específicos de HCP. Antes de decidir, ejecuta terraform state pull > state.json e inspecciona el tamaño y el número de recursos. Un workspace con 200 recursos es un proyecto muy distinto de una flota de 50 workspaces con run triggers y policy sets. Este segundo caso es una migración de platform engineering, no un simple cambio de herramienta.
Los pipelines de CI/CD codificados de forma fija para terraform. Cada referencia a terraform plan, terraform apply, a la ruta del binario, a la imagen de Docker y al paso de GitHub Actions o GitLab CI necesita revisión. Para GitHub Actions, el cambio es más o menos así:
# Before
- name: Setup Terraform
uses: hashicorp/setup-terraform@v3
with:
terraform_version: 1.5.7
- run: terraform init
- run: terraform plan
# After
- name: Setup OpenTofu
uses: opentofu/setup-opentofu@v2
with:
tofu_version: 1.12.5
- run: tofu init
- run: tofu planEse es el caso trivial: un workflow, un repositorio. En un monorepo con composite actions compartidas, varios pipelines y una biblioteca de workflows reutilizables, la superficie de revisión es mucho mayor. El trabajo es mecánico, pero puede llevar más tiempo que el simple cambio de CLI.
Revisión del archivo de bloqueo de dependencias. tofu init puede actualizar .terraform.lock.hcl, incluidas las direcciones de origen de los providers y las entradas de checksum. OpenTofu 1.12 también puede añadir conjuntos completos de checksums h1: . Trata el diff como metadatos de dependencias que hay que revisar y confirmar por separado, no como una deriva de infraestructura.
Consejo: el diff del archivo de bloqueo puede parecer ruidoso en el primer commit. Ejecuta tofu init -upgrade en una rama limpia, confirme solo el archivo de bloqueo con un mensaje claro como "revisar cambios del archivo de bloqueo de OpenTofu", y luego reorganice el trabajo de la funcionalidad encima. Mezclar metadatos de dependencias en una PR de funcionalidad hace que ambos cambios sean más difíciles de revisar.
La resistencia de los interesados. "Ahora usamos un fork" no se recibe igual en todas las organizaciones. La respuesta honesta es que OpenTofu sigue siendo, en general, compatible en configuración con el HCL al estilo Terraform para los casos que describe esta guía, por lo que el cambio suele ser reversible. Si OpenTofu desapareciera mañana, muchos equipos podrían reinstalar Terraform, revisar el archivo de bloqueo y seguir usando los mismos .tf archivos .tf. Valida primero las funciones posteriores al fork; esa salvedad es más creíble que prometer una intercambiabilidad perfecta.
Cuándo la migración es realmente difícil
Ese camino sencillo no se aplica a todos los parques de Terraform.
La migración se vuelve claramente más difícil cuando:
- El state es grande (miles de recursos, docenas de workspaces) y vive en HCP Terraform.
- La base de código usa en profundidad funciones exclusivas de HCP: policies de Sentinel integradas en los workspaces, run triggers, credenciales dinámicas de provider gestionadas por HCP. Terraform Stacks es exclusivo de HCP y no tiene equivalente en OpenTofu, algo que queda fuera del alcance aquí.
- Una auditoría empresarial o un marco de cumplimiento designa expresamente a "Terraform" como la herramienta de IaC de referencia, lo que suma un problema de compras y documentación al técnico.
- Una biblioteca de módulos extensa tiene restricciones de versión internas que se resolvían apoyándose en un comportamiento de registry específico de Terraform.
No todos los equipos deberían migrar. La relación coste-beneficio solo tiene sentido cuando las restricciones de la BSL afectan realmente a tu caso de uso, cuando una función concreta de OpenTofu desbloquea algo tangible, o cuando la hoja de ruta controlada por IBM es una preocupación real para tu organización. Si nada de eso se aplica, quedarse con Terraform es una decisión perfectamente defendible.
¿Deberías cambiar?
No hay una única respuesta correcta aquí. Cuando dibujo el árbol de decisión para un equipo, aparecen cuatro escenarios habituales, y el movimiento correcto depende de en cuál te encuentres.
Nueva adopción de IaC (greenfield). Empieza con OpenTofu. La licencia es la MPL 2.0, la gobernanza recae en la Linux Foundation y la CNCF, y el proyecto tiene un ritmo de publicación activo. Sus diferenciadores incluyen el cifrado del state en el cliente, provider for_each, enabled, y prevent_destroy. No hay ninguna fricción de la BSL que planificar. Esta es la recomendación más contundente de este artículo.
Usuario existente de Terraform, proyecto pequeño a mediano. Cambia si se activa alguno de estos tres desencadenantes. Uno: vendes o podrías vender un producto que roce la cláusula de exclusión "compite con HashiCorp" de la BSL; el cálculo legal es más claro con la MPL 2.0. Dos: necesitas el cifrado del state en el cliente, provider for_each, enabled, o prevent_destroy , y el workaround en Terraform ya no vale la pena mantenerlo. Tres: prefieres una gobernanza multiparte a una hoja de ruta de un solo proveedor. Si nada de esto se aplica y Terraform funciona sin problemas, quédate. La migración es reversible en muchos parques, pero no gratuita.
Usuario intensivo de HCP Terraform. Trata esto como una decisión de plataforma, no automáticamente como una migración de backend. OpenTofu puede usar backends remote compatibles, pero la ejecución remote específica de HCP, Sentinel, los run triggers, las credenciales dinámicas y Stacks todavía requieren una evaluación función por función. Si esos controles son centrales, pilota primero. Si estás dejando HCP por razones de licencia, coste o gobernanza, planifica el trabajo como una migración de plataforma.
Estás considerando Pulumi u otra alternativa que no sea HCL. OpenTofu es el camino más cercano si quieres conservar HCL y la mayoría de tus flujos de trabajo actuales. Pulumi es una elección de plataforma y lenguaje más amplia: TypeScript, Python, Go o .NET manejando APIs de nube. Pasarte allí puede implicar una conversión o una reescritura, así que evalúalo por separado de un simple cambio de binario de Terraform a OpenTofu.
Vale la pena abordar directamente una cosa más: la crítica legítima de que OpenTofu es, en parte, una cobertura para proveedores de SaaS. Un hilo de Hacker News sobre el cambio de la BSL sacó a la luz la preocupación de que los miembros fundadores del proyecto son plataformas comerciales de Terraform con su propio motivo de flexibilidad de licencia. Me tomo esa preocupación en serio. La mitigación es la estructura de gobernanza, el alojamiento de la Linux Foundation, el estatus de CNCF Sandbox, la MPL 2.0 en cada archivo, lo que hace que un futuro cambio de licencia sea mucho más difícil de lo que fue para un solo proveedor. Eso no lo hace imposible. Sí lo hace lo bastante costoso como para ser un freno real.
Veredicto rápido. Para cualquier trabajo nuevo de IaC en 2026, empieza con OpenTofu. Su licencia, gobernanza, desarrollo activo y conjunto de funciones lo convierten en una opción por defecto sólida. Para despliegues de Terraform ya existentes, cambia cuando se aplique alguno de los tres desencadenantes anteriores; si no, la relación coste-beneficio es escasa y quedarte está bien.
Una vez que la elección de la herramienta está clara, la siguiente pregunta práctica es dónde debe ejecutarse OpenTofu. Esa decisión afecta a la gestión de secretos, el coste, la repetibilidad y cuánto control tiene tu equipo sobre el entorno de ejecución.
Ejecutar OpenTofu por tu cuenta
OpenTofu es un binario de CLI. Dónde lo ejecutes determina en gran medida el coste, la seguridad y qué puedes hacer con él. Hay, a grandes rasgos, tres lugares razonables donde ponerlo.
Portátil o máquina de desarrollo. Está bien para planes puntuales, prototipos y proyectos personales pequeños. Es una mala opción por defecto para flujos de trabajo de producción compartidos, salvo que ya se apliquen el state remoto, el bloqueo y la disciplina de revisión. Los equipos suelen beneficiarse de un entorno de ejecución canónico en lugar de depender de cualquier portátil que haya ejecutado por última vez tofu apply.
Runner de CI gestionado (GitHub Actions, GitLab CI, etc.). El camino habitual. La opentofu/setup-opentofu action es un reemplazo directo de hashicorp/setup-terraform. Esto funciona bien para la mayoría de equipos y proyectos. Contrapartidas: los secretos transitan por un servicio de CI de terceros, los minutos del plan gratuito pueden agotarse en operaciones de state grandes, y el entorno del runner es efímero, lo cual suele ser una ventaja pero a veces una limitación. Consulta GitHub vs GitLab si todavía estás eligiendo entre opciones de CI alojadas, y Best CI/CD Tools para una visión más amplia del panorama.
Runner autoalojado en un VPS. Útil cuando las contrapartidas de un CI gestionado dejan de funcionar: los secretos deben quedarse fuera de un servicio de terceros, los minutos de CI se encarecen, o quieres cachés de providers persistentes. La configuración es sencilla: un VPS Linux, el binario de OpenTofu, un agente de GitHub Actions o GitLab Runner, y Docker para aislar los jobs. Consulta Install Docker on VPS si esa parte es nueva para ti. Para un runner de un equipo pequeño, 4 GB de RAM, 2 vCPU y 60 GB de NVMe son un punto de partida razonable; escala CPU, memoria y almacenamiento para planes más grandes y mayor concurrencia.
Para equipos que necesitan un control más estricto sobre los secretos del runner, cachés de providers persistentes o costes de CI predecibles, un runner autoalojado en un VPS puede tener sentido. En esa configuración, prioriza el acceso root, un almacenamiento NVMe rápido, un redimensionamiento sencillo y suficiente CPU/RAM para las operaciones de plan más grandes.
VPS Linux de Cloudzy encajan bien con ese patrón de runner autoalojado, con acceso root, almacenamiento NVMe y dimensionamiento flexible, así que puedes empezar en pequeño y escalar el runner a medida que crecen tus cargas de trabajo de OpenTofu.
Preguntas frecuentes
¿Es OpenTofu lo mismo que Terraform?
No exactamente. OpenTofu comenzó como un fork de Terraform 1.5.x y sigue siendo, en general, compatible en configuración con el HCL al estilo Terraform: los mismos .tf archivos, los mismos providers, y el mismo workflow de plan/apply para muchos proyectos. Se diferencian en la licencia y en las funciones añadidas después del fork. OpenTofu tiene cifrado del state en el cliente, provider for_each, enabled, y prevent_destroy; Terraform tiene sus propias funciones posteriores al fork, incluidos los recursos efímeros.
¿OpenTofu admitirá todos mis providers de Terraform?
Para los principales providers como AWS, GCP, Azure, Kubernetes y Helm, generalmente sí. El OpenTofu Registry reporta más de 3.900 providers a fecha de julio de 2026. tofu init puede actualizar .terraform.lock.hcl puede actualizar los metadatos. Para providers de nicho, específicos de un proveedor, o recién publicados, verifica directamente la disponibilidad y el soporte de versiones antes de cambiar.
¿Podría OpenTofu misma cambiar de licencia algún día?
Un futuro cambio de licencia es más difícil de lo que fue para Terraform, pero no imposible. OpenTofu tiene licencia MPL 2.0, está alojado por la Linux Foundation, y es un proyecto CNCF Sandbox desde el 23 de abril de 2025. La gobernanza es multiparte y la licencia está aprobada por la OSI. Un cambio de licencia unilateral por parte de un solo fundador entraría en conflicto tanto con el estatuto de la fundación como con las contribuciones existentes bajo MPL 2.0, que tendrían que eliminarse o reescribirse. La preocupación es legítima; las barreras estructurales son reales.
¿Qué significa la adquisición de HashiCorp por parte de IBM para el futuro de Terraform?
IBM completó la adquisición de HashiCorp el 27 de febrero de 2025, por 6.400 millones de dólares. La hoja de ruta de Terraform ahora se encuentra dentro de un proveedor empresarial más grande. La adquisición por sí sola no determina la futura dirección de licencia o producto; evalúa las notas de versión actuales, las indicaciones de licencia y los cambios de producto de HCP en lugar de tratar la propiedad como una predicción.
¿Está OpenTofu listo para producción en 2026?
Sí. v1.12.5 es la versión de mantenimiento actual, el proyecto está en el CNCF Sandbox, y Fidelity ha descrito una adopción en producción en un parque de IaC con más de 50.000 archivos de state y cuatro millones de recursos. Listo para producción no significa idéntico en funciones: los equipos que dependen de capacidades exclusivas de HCP, como Terraform Stacks, aún necesitan una decisión de compatibilidad aparte.
