OpenTofu 1.12 vs Terraform: diferencias y cuál elegir para IaC

Durante años, hablar de Infrastructure as Code (IaC) era, para muchos equipos, hablar de Terraform. La herramienta popularizó una forma declarativa de crear infraestructura, resolver dependencias y mantener entornos reproducibles en AWS, Azure, Google Cloud, Kubernetes y cientos de plataformas.

El panorama ya no es tan simple. OpenTofu nació después del cambio de licencia de Terraform y ha pasado de ser un fork orientado a preservar una alternativa abierta a desarrollar decisiones técnicas propias. La publicación de OpenTofu 1.12 el 14 de mayo de 2026 lo deja claro.

Ya no comparamos únicamente una edición comercial con otra abierta. Comparamos dos motores que parten de la misma filosofía de IaC, conservan una gran compatibilidad y empiezan a evolucionar en direcciones distintas.

La pregunta práctica es: si hoy diseñaras una plataforma desde cero, ¿elegirías Terraform u OpenTofu?

OpenTofu no es otro lenguaje de IaC

OpenTofu conserva el lenguaje HCL y el modelo de providers que conoce cualquier usuario de Terraform. Una configuración básica continúa siendo familiar:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "platform" {
  name     = "rg-platform-prod"
  location = "West Europe"
}

OpenTofu mantiene su propio registry y puede utilizar el amplio ecosistema de providers y módulos compatibles. Los providers de HashiCorp, sus APIs y SDKs no adoptaron la licencia BSL de Terraform Core: en su mayoría continúan bajo MPL 2.0.

Por eso, en muchos repositorios, pasar de terraform init, terraform plan y terraform apply a sus equivalentes tofu puede ser poco traumático. Pero reducir la elección a cambiar un comando sería quedarse en la superficie.

Qué cambia realmente en OpenTofu 1.12

Las novedades más valiosas de OpenTofu 1.12 no reinventan IaC. Atacan problemas que aparecen al reutilizar módulos, importar infraestructura o ejecutar cientos de planes desde CI/CD.

`prevent_destroy` ahora puede ser dinámico

prevent_destroy evita que un plan destruya un recurso crítico. Hasta OpenTofu 1.11, la decisión debía codificarse de forma estática, algo incómodo cuando el mismo módulo se utiliza en desarrollo, staging y producción.

OpenTofu 1.12 permite que el argumento haga referencia a variables y otros símbolos del mismo módulo:

variable "protect_database" {
  type    = bool
  default = true
}

resource "example_database" "main" {
  lifecycle {
    prevent_destroy = var.protect_database
  }
}

Así, el módulo puede proteger la base de datos en producción y permitir su sustitución en un entorno efímero. La política de protección se convierte en parte explícita de la interfaz del módulo.

Conviene recordar su límite: prevent_destroy bloquea planes destructivos mientras la regla está en la configuración. Si se elimina el bloque completo del recurso, también desaparece la regla.

`destroy = false` permite conservar el objeto remoto

OpenTofu 1.12 añade destroy al bloque lifecycle de un recurso:

resource "example_database" "main" {
  lifecycle {
    destroy = false
  }
}

Con el valor false, una acción que normalmente destruiría la infraestructura pasa a retirar el objeto del state sin pedir al provider que lo elimine. Esto puede ser útil para bases de datos, buckets con retención, recursos que sobreviven a un entorno o migraciones de responsabilidad entre plataformas.

La decisión queda persistida en el state. Según la documentación sobre el comportamiento de recursos, OpenTofu seguirá evitando la destrucción hasta que se cambie o retire la opción en la configuración correspondiente.

No debe activarse como seguro genérico: al olvidar un objeto, OpenTofu deja de administrarlo y puede crearse infraestructura huérfana. Hace falta un proceso claro para asumir su propiedad, importarlo en otro state o retirarlo manualmente.

Terraform estable permite conseguir un resultado parecido mediante un bloque removed:

removed {
  from = aws_instance.example

  lifecycle {
    destroy = false
  }
}

Este enfoque es revisable dentro del plan y es preferible a ejecutar terraform state rm sin una declaración versionada. La diferencia en las versiones estables comparadas es dónde se expresa la política: OpenTofu 1.12 puede asociarla directamente al recurso. Terraform 1.16, todavía en release candidate al publicar este análisis, ya anuncia una capacidad equivalente para el lifecycle del recurso; es una buena muestra de que la comparación cambia con cada release.

Imports con Resource Identity

Importar infraestructura existente es sencillo cuando un objeto tiene un único ID. Lo es menos cuando la API lo identifica mediante una combinación de cuenta, región, namespace y nombre.

OpenTofu 1.12 permite que un provider publique un esquema de identidad y que un bloque import lo utilice de forma estructurada:

import {
  to = example_resource.database

  identity = {
    account = "production"
    region  = "eu-west"
    name    = "database01"
  }
}

El provider debe implementar ese esquema; no todos los recursos lo ofrecerán de inmediato. Aun así, la mejora reduce la dependencia de cadenas de importación opacas y convenciones particulares, algo especialmente valioso al incorporar patrimonio cloud existente a IaC.

Lockfiles más portables entre plataformas

OpenTofu 1.12 mejora el tratamiento de checksums de providers. Con la instalación predeterminada desde el OpenTofu Registry, tofu init puede completar el lockfile con hashes zh: y h1: para las plataformas soportadas.

Esto reduce la necesidad de preparar manualmente el repositorio con tofu providers lock cuando participan, por ejemplo, un portátil macOS ARM64, un runner Linux AMD64 y un agente Linux ARM64.

El comando no desaparece: sigue siendo útil cuando tofu init está configurado para instalar desde una fuente alternativa. La mejora elimina fricción en el camino habitual, no todos los casos posibles.

Instalación concurrente de providers

El instalador ahora realiza solicitudes concurrentes. En una configuración pequeña la diferencia será marginal, pero puede reducir el tiempo de tofu init en repositorios que combinan providers como azurerm, azuread, kubernetes, helm, cloudflare, github o vault.

No convierte por sí solo un pipeline lento en uno rápido. Sí reduce trabajo repetido en runners efímeros que inicializan IaC cientos o miles de veces al mes.

Salida para humanos y máquinas en una ejecución

Un pipeline suele necesitar dos salidas: texto legible para quien revisa el job y JSON para una política, un análisis de seguridad o una interfaz interna.

OpenTofu 1.12 introduce -json-into=FILENAME:

tofu plan -json-into=plan.json

El terminal conserva la salida normal y, al mismo tiempo, la herramienta escribe la secuencia JSON en el archivo indicado. Esto simplifica integraciones con policy engines, FinOps, observabilidad, aprobaciones y portales internos sin obligarlos a sustituir toda la experiencia de la CLI.

Una diferencia previa a 1.12: cifrado nativo de state y plan

Una comparación seria debe incluir una capacidad que OpenTofu ya ofrecía antes de esta versión: el cifrado nativo de state y plan.

El state puede contener contraseñas, tokens, cadenas de conexión, atributos de bases de datos e información sensible sobre la topología. Marcar un valor como sensitive evita que aparezca en determinadas salidas, pero no lo elimina del state.

OpenTofu permite configurar cifrado con AES-GCM y utilizar proveedores de claves como AWS KMS, Google Cloud KMS, Azure Key Vault, OpenBao o PBKDF2. La documentación de cifrado de OpenTofu 1.12 incluye Azure Key Vault y Managed HSM.

Esto no sustituye los controles del backend. Siguen siendo necesarios el cifrado del almacenamiento, TLS, control de acceso, versionado, locking, auditoría y una estrategia probada de recuperación. El cifrado nativo añade una capa y permite proteger también planes locales o remotos, pero introduce la responsabilidad de custodiar y rotar claves sin perder la capacidad de descifrar estados anteriores.

Terraform también sigue evolucionando

OpenTofu 1.12 no convierte a Terraform en una herramienta inmóvil. A fecha de publicación, Terraform 1.15.8 es la versión estable más reciente, mientras Terraform 1.16 está en release candidate. El proyecto avanza en áreas que OpenTofu no replica de la misma forma, sobre todo Terraform Stacks y Actions.

Terraform Stacks coordina configuraciones completas

Cuando IaC crece, el problema deja de ser crear recursos aislados. Hay que coordinar networking, identidad, Kubernetes, bases de datos, observabilidad y múltiples entornos.

Terraform Stacks añade una capa de componentes y despliegues sobre los módulos. Permite reutilizar una composición en cuentas, regiones o entornos con states aislados y dependencias explícitas.

Su valor está especialmente ligado a HCP Terraform. No es simplemente una sintaxis local para agrupar carpetas, por lo que debe evaluarse junto con el modelo operativo y comercial de la plataforma.

Terraform Actions cubre operaciones day 2

No toda operación sobre infraestructura es crear, actualizar o eliminar un recurso. Reiniciar un servicio, invocar una función, rotar una credencial o ejecutar un procedimiento de recuperación son efectos operativos.

Terraform Actions permite que los providers expongan esas operaciones y que se invoquen desde la CLI o mediante eventos del lifecycle. Las Actions no modifican actualmente el resource state y requieren que el provider concreto las implemente.

Terraform está ampliando así su alcance hacia operaciones day 2. OpenTofu no ofrece hoy un equivalente directo con el mismo modelo.

OpenTofu vs Terraform: comparación práctica

Área	OpenTofu 1.12	Terraform estable 1.15
Lenguaje y modelo	HCL, providers y módulos compatibles	HCL y ecosistema original
Licencia del core	MPL 2.0, open source	BSL 1.1 con licencia adicional de uso
Gobierno	Proyecto de Linux Foundation	HashiCorp, una compañía de IBM
Cifrado nativo de state y plan	Sí	Depende del backend o la plataforma
`prevent_destroy` dinámico	Sí	No equivalente directo
`destroy = false` en `resource`	Sí	En estable, mediante bloque `removed`; previsto en 1.16
Import mediante Resource Identity	Sí, si el provider lo soporta	Identidad de recursos en evolución dentro del ecosistema de providers
Salida humana y JSON simultánea	`-json-into`	Flujos separados o tooling adicional
Stacks	Sin equivalente directo	Sí, integrado con HCP Terraform
Actions	Sin equivalente directo	Sí, si el provider las implementa
HCP Terraform / Enterprise	Sin integración nativa	Integración de primera parte
Migración desde Terraform clásico	Generalmente sencilla, con validación	No aplica

La tabla es una fotografía, no una promesa de paridad futura. De hecho, Terraform 1.16 ya reduce una de las diferencias de lifecycle. Conviene comparar las versiones que la organización puede desplegar y mantener, no solo los nombres de producto.

Cuándo elegir OpenTofu

OpenTofu merece estar entre las primeras opciones para un proyecto nuevo cuando el equipo busca mantener el motor IaC independiente de la plataforma que ejecuta la automatización.

Encaja especialmente bien si:

el core open source es un requisito;
se quiere reducir la dependencia de un único fabricante;
IaC se ejecuta desde GitHub Actions, GitLab CI, Azure DevOps, Jenkins o runners propios;
la plataforma es multi-cloud o se apoya mucho en Kubernetes;
interesa cifrar state y plan desde el propio motor;
las mejoras de lifecycle o automatización resuelven problemas concretos;
se quiere conservar HCL y el ecosistema de providers sin adoptar necesariamente HCP Terraform.

OpenTofu no elimina todo el lock-in: los módulos, providers, backends, servicios cloud y el diseño del state siguen condicionando la portabilidad. Lo que reduce es la dependencia del proveedor del core y de su plataforma comercial.

Cuándo elegir Terraform

Terraform continúa siendo una decisión razonable, especialmente cuando la organización ya ha construido procesos alrededor de:

HCP Terraform o Terraform Enterprise;
workspaces, private registry y VCS workflows;
Sentinel, run tasks y políticas;
Terraform Stacks;
providers con Actions relevantes para la operación;
soporte y acuerdos empresariales con HashiCorp.

Cambiar de motor sin un beneficio operativo medible puede consumir tiempo sin mejorar seguridad, fiabilidad ni velocidad de entrega.

La licencia BSL tampoco significa que una empresa no pueda utilizar Terraform comercialmente. El cambio afecta sobre todo a ciertos usos competitivos y redistribuciones; el uso interno habitual continúa permitido. Cualquier modelo de negocio que ofrezca Terraform como parte de un servicio competitivo debería revisar las condiciones exactas con asesoramiento legal, no basarse en una comparativa técnica.

¿Merece la pena migrar si ya usamos Terraform?

No migraría una plataforma estable solo porque OpenTofu existe. Una migración debe resolver un problema concreto: estrategia de licencias, portabilidad, seguridad del state, coste de plataforma, requisitos de compliance o desacuerdo con el roadmap.

Si ninguno existe, suele aportar más valor:

reducir drift;
ordenar y dividir states;
actualizar providers;
mejorar módulos y tests;
añadir revisión de planes y políticas;
eliminar cambios manuales;
documentar ownership y recuperación.

OpenTofu mantiene compatibilidad con muchas configuraciones de Terraform, pero “drop-in replacement” no significa “migración sin riesgo”. La guía oficial de migración recomienda respaldar código y state, inicializar, verificar el plan y probar primero un cambio pequeño.

En plataformas con varios states conectados mediante terraform_remote_state, el orden importa. OpenTofu puede leer states de Terraform, pero Terraform puede dejar de interpretar correctamente un state que ya utilice funciones específicas de OpenTofu. La guía para configuraciones interdependientes recomienda migrar primero los consumidores —los nodos hoja del grafo— y después sus dependencias.

Una migración prudente se parece más a esto:

Inventariar repositorios, versiones, backends y providers.
Dibujar dependencias entre states.
Congelar cambios durante cada ventana.
Probar que el backup puede restaurarse.
Ejecutar un plan sin cambios con la versión actual.
Inicializar OpenTofu y revisar el plan completo.
Migrar primero un entorno no crítico.
Validar drift, locking, credenciales y pipelines.
Migrar progresivamente según el grafo.
Evitar funciones exclusivas hasta cerrar la ventana de reversión.

La compatibilidad no será total para siempre

Terraform y OpenTofu partieron de Terraform 1.5, pero cada release aumenta la divergencia. OpenTofu introdujo archivos .tofu para que los autores de módulos puedan conservar compatibilidad y añadir comportamiento específico. En 1.12 incorpora también un bloque language para expresar restricciones de versión de forma más general.

Terraform, por su parte, desarrolla Stacks, Actions y una integración más profunda con HCP. Algunas ideas podrán converger —como muestra destroy = false— y otras serán deliberadamente distintas.

Por eso, una organización no debería asumir que podrá alternar binarios indefinidamente. Si quiere conservar una vía de retorno necesita una matriz de compatibilidad, tests de planes y una política explícita sobre características exclusivas.

Entonces, ¿cuál elegir para IaC?

El criterio puede resumirse así:

Para un proyecto nuevo con automatización propia, OpenTofu es una opción de primera línea: HCL, un ecosistema amplio, gobierno abierto y capacidades propias valiosas para seguridad y pipelines.

Para una organización integrada con HashiCorp, Terraform sigue teniendo mucho sentido. HCP Terraform, Enterprise, Stacks, Actions y el soporte de primera parte pueden pesar más que las diferencias del core.

Para una plataforma Terraform existente y estable, no migraría sin un objetivo verificable. El motor que funciona no suele ser el mayor riesgo operativo.

Para infraestructura sensible o regulada, evaluaría con especial atención el modelo de cifrado de OpenTofu, sin olvidar que la gestión de claves, el backend y la recuperación son parte del mismo control.

OpenTofu 1.12 no hace que Terraform sea una mala elección. Hace algo más útil: evita que Terraform sea una elección automática. La decisión vuelve a depender de arquitectura, operación, seguridad y estrategia de plataforma.

Antes de cambiar de herramienta, revisa qué problema quieres resolver, cómo se estructuran los states, dónde se ejecuta IaC, quién custodia las claves, qué providers son críticos y qué dependencia existe con HCP Terraform. La mejor elección no es la que gana una tabla; es la que reduce riesgo y complejidad en tu modelo operativo real.

En Nubyron trabajamos con Terraform en Azure, OpenTofu, automatización y plataformas cloud donde IaC ya es una pieza crítica de la operación. Si la decisión implica migrar states, rediseñar pipelines o reforzar controles, conviene tratarla como una decisión de arquitectura, no como un cambio de CLI.