Luca BertonPulumi vs Ansible: Two Layers of Infrastructure Automation
Pulumi vs Ansible, in short: Pulumi is an infrastructure provisioning tool — declarative, stateful, using programming languages (TypeScript, Python, Go) to define cloud resources. Ansible is a configuration management tool — procedural, agentless, using YAML to configure servers and deploy applications. They're complementary, not competitors: Pulumi provisions infrastructure (VPCs, VMs, managed services); Ansible configures what runs on it. Terraform occupies Pulumi's provisioning role but uses HCL instead of general languages. Most regulated enterprises use both a provisioning tool (Terraform or Pulumi) and Ansible together for complete infrastructure automation. Understanding when to use each — and how they complement each other — is the real enterprise question.
Architecture & Model
Ansible
- Model: Procedural, push-based. Playbooks describe tasks to execute in order.
- State: Stateless — no state file. Each run evaluates current state and applies changes.
- Language: YAML playbooks with Jinja2 templating. Low learning curve.
- Strengths: Configuration management, application deployment, orchestration, ad-hoc tasks, OS-level automation
- Agent: Agentless — connects via SSH/WinRM. Nothing to install on managed hosts.
- Idempotency: Module-dependent. Most modules are idempotent, but shell/command modules require careful handling.
Terraform
Terraform fills the same provisioning role as Pulumi — declarative infrastructure state — but in HCL instead of a general-purpose language. Like Pulumi, it doesn't replace Ansible for configuration management.
- Model: Declarative, plan-and-apply. HCL describes desired end state.
- State: Stateful — state file tracks all managed resources. Critical for drift detection.
- Language: HCL (HashiCorp Configuration Language). Domain-specific, moderate learning curve.
- Strengths: Cloud infrastructure provisioning, resource lifecycle management, dependency graphs, drift detection
- Providers: 4,000+ providers covering every major cloud, SaaS, and infrastructure platform
- Licensing: BSL since August 2023. OpenTofu is the community fork (MPL 2.0).
Pulumi
- Model: Declarative desired state, but defined in general-purpose languages (TypeScript, Python, Go, C#, Java).
- State: Stateful — managed by Pulumi Cloud (SaaS) or self-hosted backend (S3, Azure Blob).
- Language: Real programming languages. Full IDE support, type checking, testing frameworks.
- Strengths: Complex logic (loops, conditionals, abstractions), existing language expertise, strong typing, unit testing
- Trade-off: More powerful but higher complexity. YAML/HCL prevents over-engineering; Pulumi enables it.
Enterprise Decision Matrix
| Use Case | Best Tool | Why |
|---|---|---|
| Cloud infrastructure (VPCs, K8s clusters, databases) | Terraform/Pulumi | Declarative state management, dependency graphs |
| Server configuration (packages, users, files) | Ansible | Agentless, OS-level automation, push-based |
| Application deployment | Ansible | Procedural workflow, rolling updates, orchestration |
| Complex multi-cloud with shared logic | Pulumi | Abstractions, component reuse, type safety |
| Compliance guardrails | Terraform + Sentinel/OPA | Policy-as-code in the provisioning pipeline |
| Network device configuration | Ansible | Extensive network module library, agentless |
Kubernetes Recipes
Practical guide for container orchestration and deployment — hands-on patterns you can use today.
View on Amazon →The Enterprise Pattern: Terraform + Ansible
Most regulated enterprises use both:
- Terraform provisions infrastructure — VPCs, subnets, VMs, managed services, IAM roles, DNS records
- Ansible configures what's on the infrastructure — OS hardening, package installation, application deployment, certificate rotation
- Integration: Terraform outputs (IP addresses, hostnames) feed into Ansible dynamic inventory. Terraform creates the servers; Ansible configures them.
- Compliance benefit: Terraform state provides a source of truth for what infrastructure exists. Ansible playbooks document how it's configured. Together, they provide full auditability.