Las mejoras de interoperabilidad que Pulumi presentó en 2026 permiten a las organizaciones conservar sus flujos de trabajo de Terraform, compartir módulos de infraestructura entre lenguajes y ejecutar HCL con el motor de Pulumi. Estas opciones reducen algunas barreras de migración, pero cada una tiene implicaciones distintas para el estado, la ejecución y la propiedad de los recursos.
Un equipo de infraestructura puede tener años de trabajo invertidos en módulos de Terraform, pipelines de despliegue y estado de producción. Pasar a otra plataforma de infraestructura como código puede implicar reescribir la configuración, cambiar los procesos de entrega y validar recursos que ya funcionan.
El lanzamiento de Pulumi de agosto de 2026 amplía las formas en que los equipos pueden usar Terraform, OpenTofu (una implementación de código abierto compatible con Terraform) y Pulumi a la vez sin reemplazarlo todo de golpe. El lanzamiento reúne tres capacidades: el estado y la ejecución de Terraform a través de Pulumi Cloud, la interoperabilidad de módulos de Terraform entre lenguajes y HCL (HashiCorp Configuration Language, el lenguaje de los archivos de configuración de Terraform) como lenguaje de programación de Pulumi. Son enfoques diferentes. Entender esa distinción es más útil que tratar el lanzamiento como una única función de migración.
Tres capacidades, tres cambios diferentes
| Capacidad | Qué cambia | Qué sigue siendo importante |
|---|---|---|
| Backend de Terraform y ejecución remota | El estado de Terraform y, de forma opcional, la ejecución pasan a Pulumi Cloud | Los flujos de trabajo de Terraform u OpenTofu se mantienen, y la ejecución remota está sujeta al modelo de ejecución de Pulumi Cloud |
| Interoperabilidad de módulos de Terraform | Los módulos existentes pueden publicarse, consumirse y reutilizarse en los lenguajes compatibles | La ejecución, las dependencias y la compatibilidad de los módulos aún requieren validación |
| Entorno de ejecución HCL de Pulumi | La configuración HCL se ejecuta en el motor de Pulumi | El estado de Pulumi y la propiedad de los recursos sustituyen al modelo de ejecución de Terraform |
La diferencia empieza con dos conceptos. La configuración describe la infraestructura que un equipo quiere. El estado (state) registra los recursos reales asociados a un flujo de trabajo (workflow) de gestión de infraestructura.
Trasladar el almacenamiento del estado no cambia necesariamente el motor que aplica la configuración. En cambio, ejecutar el mismo HCL con otro motor cambia algo más que la ubicación de un archivo de estado.
Fuente: Pulumi, Full Support for Terraform State, Modules and HCL, agosto de 2026.
1. Mantener Terraform y usar Pulumi Cloud para el estado
Un equipo puede seguir escribiendo HCL y ejecutando los comandos habituales de Terraform u OpenTofu mientras almacena el estado en Pulumi Cloud. El backend ofrece gestión centralizada del estado, bloqueo, controles de acceso, historial de actualizaciones y visibilidad de los recursos gestionados. Este esquema no convierte los recursos gestionados por Terraform en recursos gestionados por el motor de Pulumi. El flujo de trabajo existente puede mantenerse prácticamente intacto.
Pulumi Cloud también ofrece ejecución remota (remote execution), pero hay que distinguirla de usar Pulumi Cloud solo como backend de estado. Con la ejecución local, la CLI de Terraform u OpenTofu ejecuta las operaciones en el propio entorno del equipo mientras Pulumi Cloud almacena el estado. Con la ejecución remota, la CLI envía la configuración a Pulumi Cloud, donde una infraestructura gestionada realiza el plan o el apply.
Un detalle de implementación importante es que el ejecutor remoto de Pulumi Cloud usa OpenTofu como motor de ejecución, incluso cuando la operación se inició desde la CLI de Terraform. Actualmente, la versión gestionada de OpenTofu la controla Pulumi Cloud y no la elige el cliente.
La ejecución remota también tiene limitaciones concretas, entre ellas que no admite las opciones -var y que no permite configurar imágenes de ejecutor personalizadas. Esas diferencias importan a los equipos cuyos pipelines actuales dependen de versiones concretas de Terraform, de argumentos de línea de comandos o de la personalización del ejecutor.
Ejecución local
Un equipo puede seguir escribiendo HCL y ejecutando los comandos habituales de Terraform u OpenTofu mientras almacena el estado en Pulumi Cloud. Con la ejecución local, la CLI de Terraform u OpenTofu ejecuta las operaciones en el propio entorno del equipo mientras Pulumi Cloud almacena el estado.
Ejecución remota
Con la ejecución remota, la CLI envía la configuración a Pulumi Cloud, donde una infraestructura gestionada realiza el plan o el apply. Un detalle de implementación importante es que el ejecutor remoto de Pulumi Cloud usa OpenTofu como motor de ejecución, incluso cuando la operación se inició desde la CLI de Terraform.
Revisa límites
Actualmente, la versión gestionada de OpenTofu la controla Pulumi Cloud y no la elige el cliente. La ejecución remota también tiene limitaciones concretas, entre ellas que no admite las opciones -var y que no permite configurar imágenes de ejecutor personalizadas.
Fuentes: Pulumi, Store Terraform State in Pulumi Cloud y Remote Execution for Terraform and OpenTofu.
2. Compartir módulos de Terraform entre lenguajes
Los módulos de Terraform suelen representar estándares de infraestructura ya establecidos. Un equipo de plataforma podría mantener módulos para redes, bases de datos, almacenamiento o controles de acceso. Reescribir estos componentes solo porque otro equipo quiere usar Python o TypeScript genera trabajo e introduce posibles diferencias. Las funciones de interoperabilidad de Pulumi ofrecen dos enfoques relacionados.
Registro de módulos y componentes generados. Los equipos pueden publicar módulos de Terraform en el registro privado de Pulumi Cloud. La plataforma puede ponerlos a disposición de quienes usan Terraform y OpenTofu y generar componentes tipados para los lenguajes compatibles con Pulumi.
Integración Any HCL Module. Los programas de Pulumi pueden usar módulos de Terraform existentes mediante una integración que usa OpenTofu para ejecutar el módulo, asigna las entradas proporcionadas a variables de Terraform y expone los resultados como salidas (outputs) de Pulumi.
El mecanismo Any HCL Module gestiona los recursos de sus módulos a través del backend de estado de Pulumi. No es lo mismo que ejecutar de forma independiente una configuración raíz de Terraform existente con su estado original. Los SDK generados pueden ofrecer entradas y salidas tipadas, mientras que la carga dinámica de módulos ofrece más flexibilidad a costa de cierta seguridad de tipos.
El beneficio práctico es reutilizar definiciones de infraestructura ya probadas entre equipos con preferencias de programación distintas. La responsabilidad que queda es la prueba de compatibilidad. Los módulos con dependencias complejas de proveedores (providers) o supuestos de ejecución complejos aún necesitan validarse en el entorno al que están destinados.
Registro
Los equipos pueden publicar módulos de Terraform en el registro privado de Pulumi Cloud. La plataforma puede ponerlos a disposición de quienes usan Terraform y OpenTofu y generar componentes tipados para los lenguajes compatibles con Pulumi.
Any HCL Module
Los programas de Pulumi pueden usar módulos de Terraform existentes mediante una integración que usa OpenTofu para ejecutar el módulo, asigna las entradas proporcionadas a variables de Terraform y expone los resultados como salidas (outputs) de Pulumi. El mecanismo Any HCL Module gestiona los recursos de sus módulos a través del backend de estado de Pulumi.
Lo que aún pruebas
La responsabilidad que queda es la prueba de compatibilidad. Los módulos con dependencias complejas de proveedores (providers) o supuestos de ejecución complejos aún necesitan validarse en el entorno al que están destinados.
Fuente: Pulumi, Use Terraform Modules in Pulumi.
3. Ejecutar HCL con el motor de Pulumi
La tercera capacidad cambia el modelo de ejecución de la infraestructura. Pulumi admite HCL como lenguaje para su motor. Los equipos pueden conservar la sintaxis de configuración .tf que ya conocen mientras usan el ciclo de vida de los recursos y la gestión del estado de Pulumi. Esto puede reducir el esfuerzo necesario para evaluar Pulumi sin reescribir toda una configuración en otro lenguaje de programación.
Sin embargo, el estado de Terraform no se convierte automáticamente en estado de Pulumi. Los recursos existentes deben ponerse bajo la gestión de Pulumi mediante un proceso de importación explícito.
Pulumi documenta el siguiente mecanismo para las migraciones de HCL:
pulumi import --from hcl <statefile>
La importación lee un archivo de estado de Terraform existente y asigna los recursos al stack de Pulumi. Es una operación de migración, no una instrucción para ejecutar dos motores independientes sobre los mismos recursos de infraestructura.
Antes de usar este enfoque, los equipos deben validar las correspondencias de proveedores, las identidades de los recursos, las dependencias y la vista previa (preview) resultante. Deben evitar que sistemas de estado independientes gestionen simultáneamente los mismos recursos.
También hay diferencias de compatibilidad. Por ejemplo, la configuración backend de Terraform y algunas otras opciones de configuración se aceptan, pero se ignoran con advertencias, porque Pulumi gestiona el estado de forma independiente. No se acepta un bloque cloud de Terraform. La compatibilidad con las conexiones de los provisioners es limitada, y no incluye compatibilidad con WinRM.
HCL con el motor Pulumi
Pulumi admite HCL como lenguaje para su motor. Los equipos pueden conservar la sintaxis de configuración .tf que ya conocen mientras usan el ciclo de vida de los recursos y la gestión del estado de Pulumi.
Importación
Sin embargo, el estado de Terraform no se convierte automáticamente en estado de Pulumi. Los recursos existentes deben ponerse bajo la gestión de Pulumi mediante un proceso de importación explícito. La importación lee un archivo de estado de Terraform existente y asigna los recursos al stack de Pulumi.
Revisa antes de migrar
Antes de usar este enfoque, los equipos deben validar las correspondencias de proveedores, las identidades de los recursos, las dependencias y la vista previa (preview) resultante. Deben evitar que sistemas de estado independientes gestionen simultáneamente los mismos recursos.
El equipo de ingeniería de Pulumi informó en Emulating Terraform on Pulumi’s Engine de que su intérprete de HCL ejecutó 56 de los 58 módulos de Terraform para AWS más usados, es decir, el 96 %, y de que los fallos se debieron a recursos efímeros (ephemeral resources). Se trata de un resultado comunicado por el proveedor para un conjunto concreto de módulos de AWS, no de una prueba de que el 96 % de las configuraciones de Terraform de cualquier organización vayan a migrar con éxito.
Fuentes: Pulumi, HCL Documentation, HCL Language Reference y Emulating Terraform on Pulumi’s Engine.
¿Qué deberían elegir los equipos?
Vuelve al equipo de infraestructura del principio y supón que gestiona un entorno de Terraform consolidado, pero quiere introducir Pulumi para la infraestructura de nuevas aplicaciones. Es un equipo hipotético, que se usa aquí para comparar las opciones. No es obligatorio migrarlo todo de una vez.
| Necesidad actual | Enfoque que conviene evaluar |
|---|---|
| Mejor gestión centralizada del estado | Backend de Terraform de Pulumi Cloud |
| Ejecución gestionada de Terraform u OpenTofu | Ejecución remota de Pulumi Cloud, tras validar su ejecutor basado en OpenTofu |
| Módulos de Terraform compartidos entre ecosistemas de lenguajes | Registro de módulos y componentes generados de Pulumi Cloud |
| Módulos de Terraform dentro de programas de Pulumi | Integración Any HCL Module |
| Configuración HCL gestionada por el motor de Pulumi | Pulumi HCL con importación explícita del estado y de los recursos |
| Infraestructura existente estable sin una necesidad de migración convincente | Mantener el flujo de trabajo actual de Terraform |
La elección correcta depende del problema operativo. Un nuevo backend de estado puede ayudar a un equipo que necesita controles centralizados. Los módulos compartidos pueden ayudar a organizaciones que trabajan con varios lenguajes de programación. Un motor de ejecución diferente puede tener sentido cuando un equipo quiere el modelo de programación más amplio de Pulumi.
Ninguna de esas ventajas justifica automáticamente migrar un conjunto de infraestructura consolidado que ya funciona.
Límites operativos que siguen importando
Hay tres áreas que merecen especial atención antes de adoptar estas opciones en producción.
Propiedad de los recursos. Cada recurso debe tener una única vía de gestión claramente definida. Los equipos deben saber qué motor aplica los cambios y qué sistema de estado registra el recurso.
Políticas y detección de desviaciones (drift detection). Pulumi Cloud puede ejecutar políticas de auditoría sobre stacks gestionados por Terraform, algo que su documentación indica para las ediciones Essentials, Pro y Enterprise. Las políticas preventivas que bloquean un apply que las incumple están disponibles mediante la ejecución remota, y están documentadas para las ediciones Pro y Enterprise. Sin embargo, la detección automatizada de desviaciones no está disponible actualmente para los stacks gestionados por Terraform. Es posible que las organizaciones necesiten planes programados u otro proceso de supervisión ya existente.
Costos y restricciones de ejecución. Los recursos de Terraform almacenados en Pulumi Cloud cuentan como recursos bajo gestión. La ejecución remota consume minutos de flujo de trabajo facturables. Los equipos también deben tener en cuenta las versiones de los proveedores, las limitaciones del ejecutor y los requisitos de integración con los despliegues existentes. Las actualizaciones de proveedores son una fuente habitual de este tipo de restricciones, como explica The Terraform AWS Provider Keeps Growing: Is Your Upgrade Process Ready?.
No son motivos para rechazar la interoperabilidad. Forman parte de determinar si una integración concreta mejora el modelo operativo actual de la organización.
Fuentes: Pulumi, Remote Execution for Terraform and OpenTofu y Store Terraform State in Pulumi Cloud.
Una vía práctica de adopción
Los equipos pueden evaluar la interoperabilidad sin lanzar una migración amplia. Si el objetivo es la gestión del estado, prueba el backend con un stack de Terraform representativo que no sea de producción. Confirma que la inicialización, la migración del estado, el bloqueo y la planificación funcionan como se espera.
Si el objetivo es reutilizar módulos, elige un módulo con dependencias significativas y verifica su comportamiento mediante la integración elegida. Si el objetivo es adoptar el motor de Pulumi, prueba el entorno de ejecución HCL con una importación controlada de recursos y verifica que la vista previa resultante no contiene cambios no deseados.
Estas pruebas responden a preguntas distintas. Una migración del backend que sale bien no demuestra la compatibilidad del entorno de ejecución HCL. Un módulo reutilizable no demuestra que todo el conjunto de Terraform pueda trasladarse sin rediseño. El objetivo debería ser una mejora verificada del flujo de trabajo actual, no simplemente la adopción de otra herramienta.
Lo que realmente cambia este lanzamiento
Las mejoras de interoperabilidad de Pulumi de agosto de 2026 ofrecen a los equipos de infraestructura más formas de conservar sus inversiones actuales en Terraform mientras adoptan determinadas capacidades de Pulumi. No hacen que Terraform, OpenTofu y Pulumi sean idénticos.
La distinción importante está entre dónde se almacena el estado, cómo se reutilizan los módulos y qué motor gestiona los recursos. Las organizaciones que entienden esos límites pueden adoptar la interoperabilidad de forma gradual, manteniendo una propiedad más clara y cambios de infraestructura más predecibles.
Referencias y lecturas adicionales
- Pulumi, Full Support for Terraform State, Modules and HCL. Agosto de 2026.
- Pulumi, Now Generally Available: Store Terraform State in Pulumi Cloud. 5 de marzo de 2026.
- Pulumi, Store Terraform State in Pulumi Cloud. Documentación técnica oficial.
- Pulumi, Remote Execution for Terraform and OpenTofu. Comportamiento y limitaciones oficiales de la ejecución.
- Pulumi, Use Terraform Modules in Pulumi. Interoperabilidad de módulos.
- Pulumi, HCL Language Documentation. Compatibilidad del motor y del estado.
- Pulumi, HCL Language Reference. Funciones no compatibles y requisitos de migración.
- Pulumi, Emulating Terraform on Pulumi’s Engine. 4 de agosto de 2026.
Verificación de fuentes: 5 de noviembre de 2026. Las capacidades y las afirmaciones de compatibilidad se basan en la documentación publicada por Pulumi y en sus informes de ingeniería. TechiesJournal no ha probado de forma independiente estas migraciones en producción. La cifra del 96 % se comprobó con la nota al pie de la propia publicación de Pulumi.