Terraform y Ansible resuelven dos problemas distintos y por eso la pregunta correcta casi nunca es cuál de los dos, sino cuál va primero. Terraform crea la infraestructura, es decir, las máquinas, las redes, los discos y las reglas de firewall que antes se pedían clic a clic en un panel. Ansible configura lo que ya existe, instala paquetes, deja servicios arrancados y aplica ajustes de seguridad dentro de cada máquina. Los dos son infraestructura como código, los dos guardan su verdad en archivos de texto versionados en Git y en la mayoría de proyectos acaban conviviendo. Aquí explicamos qué hace cada uno, en qué se diferencian de verdad y cuándo compensa adoptar uno, el otro o ambos.
Qué es la infraestructura como código
La infraestructura como código (IaC) consiste en definir la infraestructura (máquinas virtuales, redes, balanceadores, reglas de firewall, paquetes instalados, usuarios, servicios) en archivos de texto en lugar de configurarla a mano en un panel o comando a comando por SSH. Esos archivos viven en un repositorio de control de versiones, normalmente Git, igual que el código de una aplicación.
El cambio de fondo es que la infraestructura deja de ser algo que existe en un servidor sin que nadie recuerde cómo se montó y pasa a ser algo descrito, revisable y reproducible. Si quieres saber cómo está configurado un entorno, lo lees. Si quieres cambiar algo, editas el archivo y lo aplicas. Si algo se rompe, vuelves a la versión anterior con el mismo procedimiento que usarías para revertir un error de código.
Aprovisionar no es lo mismo que configurar
Aquí es donde entran las dos herramientas, y confundir sus capas lleva a usarlas mal.
Terraform aprovisiona. Le describes dos servidores en un proveedor cloud, una red privada entre ellos y un balanceador delante, y habla con la API del proveedor (AWS, Azure, Google Cloud, y también Proxmox, VMware u otros entornos propios) para crear exactamente eso. Guarda un estado de lo que existe, así que cuando pides un cambio calcula la diferencia y aplica solo lo que falta.
Ansible configura. Una vez existe la máquina, la deja lista. Instala paquetes, copia archivos de configuración, crea usuarios, arranca servicios y aplica endurecimiento del sistema. Describe el estado deseado por dentro de la máquina, no la máquina en sí, y se conecta por SSH sin instalar ningún agente.
La analogía habitual sigue siendo válida. Terraform construye la casa con sus cimientos e instalaciones, y Ansible la amuebla y la deja habitable.
Terraform vs Ansible, diferencia por diferencia
| Criterio | Terraform | Ansible |
|---|---|---|
| Para qué sirve | Crear, modificar y destruir recursos de infraestructura | Configurar el sistema operativo y las aplicaciones dentro de la máquina |
| Lenguaje | HCL, declarativo puro | YAML en playbooks, declarativo por tarea con orden de ejecución |
| Estado | Mantiene un fichero de estado con lo que existe | Sin estado, comprueba la situación real en cada ejecución |
| Conexión | Contra las API de los proveedores | Por SSH o WinRM, sin agentes en el destino |
| Licencia | BSL 1.1 (IBM) desde la versión 1.6 | GPLv3, software libre |
Hay una diferencia menos visible que importa mucho en el día a día. Terraform sabe lo que creó y por tanto sabe destruirlo, lo que lo convierte en la herramienta natural para entornos que nacen y mueren, como una copia de preproducción que se levanta el lunes y se apaga el viernes. Ansible no lleva esa contabilidad, comprueba el estado real de cada máquina en cada pasada y actúa solo si hace falta, que es justo lo que quieres en servidores de larga vida que ya estaban ahí antes de que existiera el repositorio.
Cuándo usar Terraform
Cuando la infraestructura se crea y se destruye con frecuencia, cuando trabajas en una nube pública y quieres que ninguna máquina nazca a mano, cuando necesitas replicar un entorno completo en otra región o cuenta, y cuando quieres poder responder qué hay desplegado leyendo un repositorio en lugar de recorriendo paneles.
Cuándo usar Ansible
Cuando el parque de servidores ya existe y el problema es que cada uno está configurado a su manera, cuando necesitas aplicar el mismo cambio en veinte máquinas sin entrar una a una, cuando quieres convertir el conocimiento que tenía el técnico que se marchó en un playbook legible, y cuando hay que aplicar endurecimiento del sistema de forma repetible siguiendo una referencia como los CIS Benchmarks. Esa misma disciplina aparece resumida en nuestros consejos para levantar un servidor bien desde el primer día.
Cuándo usar los dos
En cuanto la plataforma tiene más de un entorno y se toca con regularidad. El reparto es limpio, Terraform levanta y modifica la infraestructura, y Ansible entra después para dejar cada máquina lista. Si solo puedes empezar por uno, la regla que aplicamos es sencilla. Si gestionas servidores que ya existen, empieza por Ansible, no necesita agentes y se aprende en días. Si estás naciendo en cloud, empieza por Terraform y que ninguna máquina se cree a mano desde el primer día.
Licencias y coste real
Este punto cambió en los últimos años y conviene tenerlo claro antes de apostar por una herramienta. Terraform pasó de licencia libre a la Business Source License 1.1 con la versión 1.6, y hoy figura IBM como licenciante tras la compra de HashiCorp. En la práctica, una empresa que use Terraform para gestionar su propia infraestructura no paga nada y la restricción solo afecta a quien quiera ofrecer un producto que compita con los de HashiCorp; además, cada versión pasa a licencia libre MPL 2.0 cuatro años después de publicarse. Quien prefiera no depender de esa licencia tiene OpenTofu, un fork bajo MPL 2.0 alojado en la Linux Foundation, compatible con la configuración existente. Ansible, por su parte, es software libre bajo GPLv3; lo que se paga es la plataforma comercial de Red Hat con su interfaz, control de acceso y soporte, no el motor. En el momento de escribir esto, en septiembre de 2026, las versiones estables son Terraform 1.16.1, OpenTofu 1.12 y ansible-core 2.21.3.
Cuándo empieza a compensar para una pyme
La IaC tiene curva de aprendizaje y un coste inicial de montaje. Para un único servidor que casi nunca cambia, escribirlo todo en código puede ser más esfuerzo del que ahorra. Empieza a compensar cuando aparecen señales concretas, y con dos de ellas ya deja de ser un lujo.
- Tienes varios entornos que deberían ser iguales (desarrollo, preproducción, producción) y se desincronizan sin que nadie sepa exactamente en qué.
- Reconstruir un servidor lleva horas y depende de la memoria de una persona concreta.
- Escalas o replicas infraestructura con cierta frecuencia, ya sea por picos de trabajo o por proyectos nuevos.
- El conocimiento de cómo está montado todo vive en una sola cabeza, que es un riesgo operativo antes que técnico.
- Necesitas justificar cambios ante una auditoría y hoy no hay registro de quién tocó qué ni cuándo.
Un escenario típico: tres entornos que ya no se parecían
Una empresa de software de unas treinta personas con su aplicación en tres entornos sobre máquinas virtuales creadas a mano a lo largo de cuatro años. Cada vez que un despliegue fallaba en producción y funcionaba en preproducción, la investigación acababa igual, una versión distinta de una librería, un parámetro del servidor web que alguien cambió en caliente o un cron que solo existía en una máquina. Reconstruir el entorno de pruebas después de un fallo de disco costó dos días y medio de dos personas.
La salida no fue reescribirlo todo. Se empezó por el entorno de pruebas, que era el de menor riesgo. Terraform describió las máquinas, la red y las reglas de firewall; Ansible se encargó del sistema operativo, los paquetes, los usuarios y el endurecimiento. Cuando ese entorno se levantaba entero desde cero de forma repetible, se aplicaron las mismas plantillas a preproducción y por último a producción, con las diferencias reducidas a un fichero de variables por entorno.
Lo que cambió después es lo que se buscaba. Los despliegues dejaron de fallar por diferencias entre entornos, levantar una copia limpia para probar una migración pasó de días a una tarde, y cualquiera del equipo puede leer en el repositorio cómo está montada la plataforma en lugar de preguntar. El coste fue el de un proyecto acotado de unas semanas, no una reforma general.
Cómo los usamos nosotros
En nuestros proyectos casi siempre acaban juntos, cada uno en su capa. Terraform crea y modifica la infraestructura, incluidas las plataformas Proxmox de los clientes que no están en nube pública, y deja el estado versionado y con acceso restringido. Ansible entra después para paquetes, servicios, usuarios y endurecimiento. Las credenciales nunca van en los archivos, se resuelven con un gestor de secretos, y el estado de Terraform, que puede contener información sensible, se guarda cifrado y con acceso controlado.
La pieza que más se descuida es la de ejecutar todo esto de forma automática y auditable en lugar de desde el portátil de quien lo escribió, que es exactamente el terreno de una canalización de CI/CD bien planteada. Con clientes aplicamos una regla, que todo se pueda reconstruir mañana desde cero, se use la herramienta que se use.
Por dónde empezar
Coge el entorno menos crítico que tengas y llévalo a código de principio a fin, aprovisionamiento y configuración incluidos. Aprenderás las dos herramientas con riesgo bajo y saldrás con plantillas reutilizables para el resto. Lo que más cuesta es diseñar bien la estructura, gestionar el estado de forma segura y mantener la coherencia según crece, y ahí ahorra meses tener al lado a alguien que ya lo hace a diario, que es lo que cubre nuestro servicio de DevOps y automatización. Si quieres valorar por dónde empezar en tu caso concreto, cuéntanos tu situación y lo revisamos sin compromiso.
Si el siguiente paso es automatizar también los despliegues de tu aplicación, aquí explicamos qué es CI/CD y cómo montar despliegues seguros.