Hace casi un año publiqué un artículo sobre Stacks y desde entonces incluso presenté el tema junto a ingenieros de HashiCorp. La promesa de ofrecer una experiencia multirregión, multicuenta y multientorno de forma nativa en el lenguaje de Terraform era muy atractiva. Con HashiConf a la vuelta de la esquina en cuatro semanas, vale la pena revisar dónde estamos y qué ha cambiado recientemente.
Recordemos primero qué es Stacks. Terraform Stacks permite agrupar y gestionar configuraciones de Terraform como unidades repetibles de infraestructura. Cada stack define qué desplegar, dónde desplegarlo y cómo mantenerlo sincronizado, lo que facilita manejar entornos complejos, reutilizar módulos y automatizar despliegues.
Spoiler: todo apunta a que Stacks llegará a GA alrededor de HashiConf. Una pista clara es que a partir del 25 de septiembre de 2025, el uso de Stacks contará para los límites de uso de recursos de HCP Terraform.
Una novedad importante es que el binario de Terraform incorporó recientemente el subcomando stacks, que antes vivía en el CLI tfstacks. Esto sugiere integración nativa, aunque los detalles de uso dejan entrever que su alcance operativo sigue atado a HCP Terraform. A diferencia de otros subcomandos, terraform stacks usa la opción usage en lugar de help y muestra las operaciones principales como init, providers-lock, validate, version y fmt. En la práctica, los mapeos del antiguo CLI quedan así: tfstacks init pasa a ser terraform stacks init, tfstacks validate pasa a terraform stacks validate, tfstacks providers lock pasa a terraform stacks providers-lock y tfstacks fmt pasa a terraform stacks fmt.
El subcomando version dentro de stacks reporta la versión del plugin de Stacks, no la de Terraform, lo que confirma que hay un componente de plugin gestionado aparte. Por otro lado, se echa de menos la operación plan que existía como tfstacks plan con parámetros de organización, stack y deployment; no está disponible del mismo modo en el nuevo flujo.
En HCP Terraform aparece además una opción de carga manual que parece posicionarse como sustituto del flujo clásico de plan, aunque la interfaz de usuario va un paso por delante de la API y la documentación enlaza de nuevo a la configuración de Stacks por ahora. Otro punto a vigilar es el límite de 20 deployments por stack en HCP Terraform. Para escenarios de plataforma con múltiples cuentas o regiones, donde cada deployment mapea a una cuenta o variante, este límite puede ser un freno y obligar a rediseñar la segmentación de stacks.
Si trabajas con Terraform para gestionar Stacks en HCP Terraform, el recurso tfe_stack permite definir programáticamente stacks en organizaciones o proyectos con Stacks habilitado, lo que facilita la estandarización del aprovisionamiento con infraestructura como código end to end.
Sobre los stacks enlazados, la idea es similar a los run triggers de los workspaces. Puedes declarar en tu configuración de despliegue un bloque upstream_input para consumir valores publicados por otro stack mediante publish_output. Esto crea una dependencia entre stacks. Un ejemplo habitual es un stack de aplicación que depende del stack de red. Más allá de usar data sources para leer recursos existentes, cualquier cambio en el stack de red puede reactivar el despliegue del stack de aplicación y así propagar valores actualizados de networking que afecten a la capa de aplicación.
Consejos prácticos al usar stacks enlazados: define siempre el tipo en los outputs del stack upstream. Es fácil pasar por alto este detalle porque en Terraform clásico no siempre se especifica. Si un output upstream puede ser vacío y no declaras su tipo correctamente, el downstream puede fallar con errores de metadatos ausentes poco claros. Ajustar los tipos en outputs suele corregirlo, aunque no siempre vuelve a disparar de forma automática el redeploy del downstream, por lo que quizá debas reejecutarlo.
En cuanto a cambios en los archivos, aunque la documentación menciona extensiones tfstack.hcl para componentes, el comando terraform stacks avisa de que estas extensiones quedan deprecadas y recomienda usar tfcomponent.hcl o tfcomponent.json. Al validar una configuración con terraform stacks validate, verás advertencias si mantienes tfstack.hcl. Es normal que en beta haya ajustes de nomenclatura y de API, así que conviene adoptar cuanto antes las nuevas extensiones para evitar futuras roturas.
Quedan abiertas varias cuestiones: existirá una herramienta de migración desde despliegues basados en workspace a despliegues basados en Stacks, se replicará el ecosistema actual alrededor de workspaces con políticas como código, integraciones de Day 2, health checks, notificaciones y despliegues en entornos regulados mediante agentes, y cuándo llegará el soporte completo en language servers para los bloques propios de Stacks como component, deployment y proveedores nombrados. Para quienes usan Sentinel, también será clave entender el encaje de las políticas en el nuevo flujo.
Desde Q2BSTUDIO, empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad y servicios cloud aws y azure, vemos Stacks como una pieza clave para escalar infraestructura con gobernanza y automatización. Podemos ayudarte a diseñar la arquitectura multicuenta y multirregión, orquestar pipelines de despliegue, aplicar mejores prácticas de seguridad y observabilidad, e integrar IaC con plataformas de negocio. Si estás modernizando tu plataforma cloud, descubre nuestros servicios cloud en AWS y Azure y cómo encajan con un modelo de despliegue basado en Stacks.
Nuestro enfoque combina software a medida, automatización y FinOps para optimizar costes y ciclos de entrega. Integramos políticas como código, escaneo de seguridad, y flujos de aprobación para compliance. Además, si buscas llevar esta infraestructura al siguiente nivel con automatización de flujos CI CD y tareas repetitivas, podemos ayudarte con automatización de procesos y orquestación basada en eventos. Complementamos con inteligencia artificial e ia para empresas, agentes IA que aceleran operaciones, ciberseguridad y pentesting, servicios inteligencia de negocio con power bi, y analítica para mejorar la toma de decisiones.
En resumen, Terraform Stacks avanza hacia su madurez con mayor integración en el CLI, nuevas capacidades para enlazar despliegues y un modelo más consistente de componentes. Queda por ver la evolución de límites, herramientas de migración y ecosistema, pero ya ofrece beneficios claros para organizaciones que buscan gobernanza, repetibilidad y seguridad en entornos complejos. En Q2BSTUDIO unimos infraestructura, aplicaciones a medida, software a medida y prácticas de plataforma para que puedas adoptar estos patrones con garantías y acelerar tu hoja de ruta cloud y de producto.