diff --git a/content/blog/infrastructure-as-code-tools/index.md b/content/blog/infrastructure-as-code-tools/index.md index 02a2d8be9def..290b9ace48c9 100644 --- a/content/blog/infrastructure-as-code-tools/index.md +++ b/content/blog/infrastructure-as-code-tools/index.md @@ -1,8 +1,8 @@ --- title: "Most Effective Infrastructure as Code (IaC) Tools" -date: 2025-06-26 +date: 2026-05-01 draft: false -meta_desc: "Complete guide to the most effective IaC tools. Compare Pulumi, Terraform, OpenTofu, AWS CDK, and more to find the perfect solution." +meta_desc: "Compare 2026's IaC tools — Pulumi, Terraform, OpenTofu, AWS CDK, Bicep, Crossplane, and more — by language, license, state model, and use case." meta_image: meta.png authors: - asaf-ashirov @@ -17,430 +17,135 @@ tags: - devops --- -Infrastructure as Code (IaC) has evolved beyond simple automation into a fundamental shift toward applying software engineering practices to infrastructure management. In 2025, leading organizations aren't just provisioning infrastructure—they're treating it as software, complete with testing, version control, code reviews, and continuous integration. +Infrastructure as code (IaC) is the practice of defining cloud and on-premises infrastructure in machine-readable files that are versioned, reviewed, and deployed the same way as application code. Instead of clicking through consoles or running ad-hoc scripts, teams describe the desired state of their infrastructure (networks, virtual machines, databases, Kubernetes clusters, DNS records) and let an IaC tool create, update, and destroy resources to match. The result: reproducible environments, faster recovery, fewer surprises, and a clear audit trail. -As infrastructure complexity grows, teams increasingly seek approaches that provide the same developer productivity tools they use for application development. While template-based and domain-specific language approaches serve many use cases effectively, teams with complex requirements or programming backgrounds often find that general-purpose programming languages offer advantages in testing, abstraction, and collaboration. +This guide compares the most widely used IaC tools in 2026 — what they do, where they fit, and how to pick one. It groups tools by category (multi-cloud provisioning, cloud-native, Kubernetes-native, configuration management, and abstraction frameworks) so you can quickly find the right shortlist for your situation. -This comprehensive guide examines the most effective infrastructure as code tools available today, providing detailed analysis of core IaC platforms, complementary tools, and related technologies through the lens of software engineering best practices. Whether you're starting fresh with IaC or evaluating alternatives to overcome limitations in your current toolchain, we'll help you navigate this complex landscape and choose solutions that truly bring software engineering to infrastructure. +*Updated May 1, 2026: refreshed the comparison table and licensing notes (Terraform BUSL post-IBM acquisition, OpenTofu 1.11 state encryption), added SST, restructured around tool categories and decision criteria, and noted CDK for Terraform's December 2025 deprecation.* -## What is Infrastructure as Code? +## TL;DR: the IaC tools that matter in 2026 -[Infrastructure as Code (IaC)](/what-is/what-is-infrastructure-as-code/) is an approach to automating the provisioning and management of infrastructure using software engineering principles, approaches, and tools. Rather than manually configuring servers, networks, and cloud resources through user interfaces or command-line tools, IaC enables you to define your entire infrastructure declaratively through code. +- **[Pulumi](#pulumi)** — Multi-cloud IaC in TypeScript, Python, Go, C#, Java, or YAML. Apache 2.0. +- **[Terraform](#terraform)** — HashiCorp's HCL-based provisioning tool with the largest provider ecosystem. BUSL 1.1. +- **[OpenTofu](#opentofu)** — Linux Foundation fork of Terraform 1.5.x with state encryption and an open governance model. MPL 2.0. +- **[AWS CloudFormation](#aws-cloudformation)** — AWS-native YAML/JSON templates. Proprietary. +- **[AWS CDK](#aws-cdk)** — AWS-only abstraction layer that synthesizes CloudFormation from TypeScript, Python, Java, .NET, or Go. Apache 2.0. +- **[Azure Resource Manager (ARM)](#azure-resource-manager-arm) / [Azure Bicep](#azure-bicep)** — Azure-native JSON templates and the cleaner Bicep DSL that compiles to them. Proprietary / MIT. +- **[Google Cloud Infrastructure Manager](#google-cloud-infrastructure-manager)** — Managed Terraform service for Google Cloud. Proprietary. +- **[Crossplane](#crossplane)** — Kubernetes-native control plane for cloud resources. CNCF, Apache 2.0. +- **[SST](#sst)** — TypeScript framework for full-stack apps that uses Pulumi under the hood. MIT. +- **[Ansible](#ansible) / [Chef](#chef) / [Puppet](#puppet) / [Salt](#salt)** — Configuration management for software running on existing systems. +- **[Checkov](#policy-and-security-tools-alongside-iac), [TFLint](#policy-and-security-tools-alongside-iac), [Pulumi CrossGuard](#policy-and-security-tools-alongside-iac), [HashiCorp Sentinel](#policy-and-security-tools-alongside-iac)** — Policy-as-code and security scanning that runs alongside any IaC tool. +- **[Pulumi Cloud](#iac-automation-and-management-platforms), [HCP Terraform](#iac-automation-and-management-platforms), [Spacelift](#iac-automation-and-management-platforms), [env0](#iac-automation-and-management-platforms), [Atlantis](#iac-automation-and-management-platforms)** — Automation platforms that orchestrate the tools above; not IaC tools themselves. -This approach brings the same benefits that have revolutionized software development—version control, automated testing, code reviews, and CI/CD pipelines—to infrastructure management. +## IaC tools comparison table -## What Are Infrastructure as Code Tools? +| Tool | Type | Language(s) | License | State management | Best for | +| --- | --- | --- | --- | --- | --- | +| [Pulumi](#pulumi) | Multi-cloud provisioning | TypeScript, Python, Go, C#, Java, YAML | Apache 2.0 | Managed service or self-hosted backend | Teams that prefer general-purpose languages and want testing, IDE support, and multi-cloud | +| [Terraform](#terraform) | Multi-cloud provisioning | HCL | BUSL 1.1 | Local file or remote backend (e.g. HCP Terraform, S3) | Teams with existing HCL expertise and access to the largest module/provider ecosystem | +| [OpenTofu](#opentofu) | Multi-cloud provisioning | HCL | MPL 2.0 | Local file or remote backend; client-side state encryption | Open-source-first teams that want Terraform compatibility without BUSL restrictions | +| [AWS CloudFormation](#aws-cloudformation) | AWS-native provisioning | YAML, JSON | Proprietary | Managed by AWS | AWS-only deployments needing day-zero service support | +| [AWS CDK](#aws-cdk) | AWS-native abstraction layer | TypeScript, Python, Java, .NET, Go (preview) | Apache 2.0 | Via CloudFormation | AWS teams who prefer programming languages over templates | +| [Azure Resource Manager (ARM)](#azure-resource-manager-arm) | Azure-native provisioning | JSON | Proprietary | Managed by Azure | Maximum-fidelity Azure deployments | +| [Azure Bicep](#azure-bicep) | Azure-native DSL | Bicep | MIT | Managed by Azure (compiles to ARM) | Azure-first teams who want a cleaner alternative to ARM JSON | +| [Google Cloud Infrastructure Manager](#google-cloud-infrastructure-manager) | GCP-native provisioning | HCL (Terraform) | Proprietary | Managed by Google | GCP teams standardized on Terraform | +| [Crossplane](#crossplane) | Kubernetes-native provisioning | YAML (CRDs) | Apache 2.0 (CNCF) | Reconciled continuously by Kubernetes | Platform teams building internal developer platforms on Kubernetes | +| [Kubernetes YAML](#kubernetes-yaml) | Container/workload provisioning | YAML | Apache 2.0 | Reconciled continuously by Kubernetes | Defining workloads, services, and networking on Kubernetes | +| [SST](#sst) | App and IaC framework | TypeScript | MIT | Via Pulumi | Full-stack TypeScript apps deployed primarily to AWS | +| [CDK for Terraform](#cdk-for-terraform-cdktf) | Terraform abstraction layer | TypeScript, Python, Java, C#, Go | MPL 2.0 | Via Terraform/OpenTofu | (Deprecated December 10, 2025; listed for historical reference) | +| [Ansible](#ansible) | Configuration management | YAML (playbooks) | GPL v3 | Stateless (idempotent) | Configuring software on existing systems | +| [Chef](#chef) | Configuration management | Ruby DSL | Apache 2.0 | Tracked per-node | Programmable configuration management at scale | +| [Puppet](#puppet) | Configuration management | Puppet DSL | Apache 2.0 | Tracked per-node | Compliance-heavy enterprise environments | +| [Salt](#salt) | Configuration management | YAML, Python | Apache 2.0 | Master/minion | Event-driven automation on large fleets | -Infrastructure as Code tools are platforms and frameworks that enable you to define, provision, and manage infrastructure resources through code rather than manual processes. These tools translate your infrastructure definitions into API calls that create, modify, or destroy cloud resources across various providers. +## What is infrastructure as code? -The most effective IaC tools share several key characteristics: +[Infrastructure as code](/what-is/what-is-infrastructure-as-code/) is an approach to provisioning and managing infrastructure by writing code rather than performing manual steps. You describe the resources you want — VPCs, subnets, instances, databases, Kubernetes namespaces, and so on — in files that live in version control. An IaC tool reads those files, compares them to the live state of the infrastructure, and makes whatever API calls are needed to bring the two into alignment. -- **Goal-state focus**: Define your desired infrastructure outcome, whether through declarative syntax (like YAML/JSON templates) or imperative languages that express declarative intent -- **Multi-cloud support**: Work across different cloud providers and services -- **State management**: Track the current state of your infrastructure -- **Preview capabilities**: Show what changes will be made before applying them -- **Idempotency**: Safe to run multiple times with consistent results +Two ideas distinguish modern IaC from older automation: -## Why Infrastructure as Code Tools Are Essential +1. **Desired state, not steps.** You describe the end result; the tool figures out how to get there. That makes the same definition idempotent and safe to re-run. +1. **Software engineering for infrastructure.** Because the definition is code, you can review it in pull requests, test it, refactor it, and roll back via Git history. -The shift to IaC tools addresses fundamental challenges that manual infrastructure management cannot solve at scale: +Together, these properties make IaC the foundation for repeatable environments, faster incident recovery, automated compliance, and platform engineering at scale. -**Accelerates Deployment Velocity**: Teams can provision complex multi-cloud architectures in minutes instead of weeks. This speed enables faster time-to-market and more frequent, reliable deployments. +## What are the main types of IaC tools? -**Enables True Collaboration**: Infrastructure becomes code that teams can review, test, and approve together. This collaborative approach reduces errors and ensures knowledge sharing across the organization. +IaC tools fall into five practical categories. Most teams end up using more than one. -**Eliminates Configuration Drift**: Manual changes lead to inconsistencies between environments. IaC ensures your production, staging, and development environments remain identical, eliminating the notorious "works on my machine" syndrome for infrastructure. +1. **Multi-cloud provisioning tools** — create and update cloud resources across providers (Pulumi, Terraform, OpenTofu). +1. **Cloud-native provisioning tools** — first-party tools tied to a single cloud (AWS CloudFormation and CDK; Azure ARM and Bicep; Google Cloud Infrastructure Manager). +1. **Kubernetes-native tools** — manage cloud resources through Kubernetes APIs and reconcilers (Crossplane, Kubernetes YAML). +1. **Application and abstraction frameworks** — higher-level frameworks built on top of provisioning engines (SST, CDK for Terraform). +1. **Configuration management tools** — configure operating systems and software on existing machines, complementary to provisioning (Ansible, Chef, Puppet, Salt). -**Provides Cost Control**: Automated provisioning and deprovisioning prevents resource sprawl. Teams can easily track infrastructure costs, set budget alerts, and optimize resource usage across environments. +A complete IaC toolchain usually pairs one provisioning tool with policy-as-code, CI/CD orchestration, and — when systems are running — a configuration management tool. -**Ensures Compliance and Security**: Codified security policies and compliance requirements are automatically enforced across all deployments. Audit trails become automatic, and policy violations are caught before deployment. +## Multi-cloud provisioning tools -**Guarantees Business Continuity**: Complete infrastructure definitions stored in version control enable rapid disaster recovery. Organizations can reconstruct entire environments from code, minimizing downtime and data loss. +These tools provision resources across many clouds and SaaS APIs from a single workflow. They are the closest thing to "general-purpose" IaC. -## Infrastructure as Code Tools Overview +### Pulumi -This guide covers the following infrastructure as code tools and platforms: +- License: Apache 2.0 +- Languages: TypeScript, Python, Go, C#, Java, YAML +- Best for: teams that want to use general-purpose programming languages, real testing, and a single tool across [150+ providers](/registry/) -### 10 Most Used IaC Tools in 2025 +[Pulumi](/docs/iac/) lets you define infrastructure in the same languages you already use for applications. The Pulumi engine reads your program, builds a desired-state graph, and reconciles it with the cloud through native provider SDKs. Because programs are real code, you get loops, conditionals, classes, packages, unit tests, IDE refactoring, and the option to publish reusable [components](/docs/iac/concepts/components/) as Pulumi packages consumable from any supported language. -1. **[Pulumi IaC](#1-pulumi)** - Modern IaC with general-purpose programming languages -2. **[Terraform](#2-terraform)** - BSL-licensed IaC from HashiCorp that uses the HCL domain-specific language -3. **[AWS CDK](#3-aws-cloud-development-kit-cdk)** - Cloud Development Kit for AWS -4. **[AWS CloudFormation](#4-aws-cloudformation)** - Native AWS integration -5. **[Azure Resource Manager (ARM)](#5-azure-resource-manager-arm)** - Native Azure JSON templates -6. **[Azure Bicep](#6-azure-bicep)** - Azure-native domain-specific language that compiles to ARM -7. **[Google Cloud Infrastructure Manager](#7-google-cloud-infrastructure-manager)** - Terraform-based solution for Google Cloud -8. **[Kubernetes YAML](#8-kubernetes-yaml)** - Native Kubernetes resource definitions -9. **[Crossplane](#9-crossplane)** - Kubernetes as universal control plane -10. **[OpenTofu](#10-opentofu)** - Open-source Terraform alternative - -### Configuration Management Tools - -- **[Chef](#chef)** - Configuration management and compliance automation -- **[Puppet](#puppet)** - Configuration management and compliance automation -- **[Salt](#salt)** - Configuration management and remote execution - -### Application and Platform Management Tools - -- **[Kubernetes](#kubernetes-container-orchestration-platform)** - Container orchestration platform - -### Security and Compliance Tools - -- **[Pulumi ESC](#pulumi-esc)** - Configuration and secrets management platform -- **[Pulumi Insights](#pulumi-insights)** - Cloud resource search, analytics, and compliance platform -- **[Snyk](#security-scanning-tools)** - Developer security platform with IaC scanning -- **[Wiz](#security-scanning-tools)** - Comprehensive cloud security platform -- **[HashiCorp Sentinel](#security-scanning-tools)** - Policy-as-code framework for Terraform -- **[Checkov](#security-scanning-tools)** - Static analysis for IaC security -- **[TFLint](#linting-and-validation-tools)** - Terraform linting and validation - -### Infrastructure Automation and Management Platforms - -- **[Pulumi Cloud](#iac-automation-platforms)** - Managed service for Pulumi IaC with enterprise features -- **[HashiCorp Cloud Platform](#iac-automation-platforms)** - Enterprise SaaS platform for Terraform management and automation -- **[Spacelift](#iac-automation-platforms)** - Automation platform for IaC workflows (not an IaC tool itself) -- **[Env0](#iac-automation-platforms)** - Governance and automation platform for existing IaC tools - -## Core Infrastructure as Code Tools - -### 1. Pulumi - -License: Apache 2.0 -Best For: Teams who want flexible, language-agnostic IaC for infrastructure and operations - -Pulumi IaC represents a modern approach to infrastructure as code, fundamentally changing how teams approach infrastructure by enabling the use of general-purpose programming languages like Python, TypeScript, Go, C#, and Java, plus YAML for simpler configurations. Unlike tools that force teams to learn proprietary domain-specific languages (DSLs), Pulumi leverages familiar languages and software engineering practices, providing unprecedented flexibility, powerful abstractions, and seamless integration with existing development workflows. - -Pulumi's approach combines the best of both imperative and declarative paradigms: you use imperative programming languages to define your desired infrastructure state, but the Pulumi engine processes this declaratively to determine what changes are needed to achieve your intended outcome. - -### Key Features: - -- **Universal language support**: Use Python, TypeScript, Go, C#, Java, or YAML configurations—no new DSL to learn -- **Any cloud, any architecture**: Deploy to AWS, Azure, Google Cloud, Kubernetes, and 100+ other providers -- **Real programming constructs**: Leverage loops, conditionals, functions, classes, packages, and third-party libraries -- **Superior developer experience**: Full IDE support with IntelliSense, debugging, and refactoring -- **Built-in testing**: [Unit and integration testing](/docs/using-pulumi/testing/) for infrastructure code -- **Policy as Code**: Enforce compliance and security policies with [CrossGuard](/docs/using-pulumi/crossguard/) -- **Component ecosystem**: Rich library of reusable infrastructure components - -Universal Language Code Examples: - -{{< chooser language "typescript,python,go,csharp,yaml" />}} - -{{% choosable language typescript %}} +State can live in [Pulumi Cloud](/docs/iac/concepts/pulumi-cloud/), in self-hosted Pulumi Cloud, or in a [DIY backend](/docs/iac/concepts/state-and-backends/) such as S3, Azure Blob, or GCS. Pulumi includes built-in secret encryption, [policy as code](/docs/insights/policy/) via CrossGuard, and [conversion tooling](/docs/iac/guides/migration/) for importing from Terraform, ARM, CloudFormation, and Kubernetes YAML. ```typescript -import * as pulumi from "@pulumi/pulumi"; import * as aws from "@pulumi/aws"; import * as awsx from "@pulumi/awsx"; -// Create a VPC with automatic subnets const vpc = new awsx.ec2.Vpc("main-vpc", { cidrBlock: "10.0.0.0/16", numberOfAvailabilityZones: 2, }); -// Create an ECS cluster const cluster = new aws.ecs.Cluster("app-cluster"); -// Create an Application Load Balancer const alb = new awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb", { vpcId: vpc.vpcId, subnetIds: vpc.publicSubnetIds, }); -// Deploy a containerized application -const service = new awsx.ecs.FargateService("app-service", { +new awsx.ecs.FargateService("app-service", { cluster: cluster.arn, taskDefinitionArgs: { container: { image: "nginx:latest", memory: 128, - ports: [{ - containerPort: 80, - targetGroup: alb.defaultTargetGroup, - }], + ports: [{ containerPort: 80, targetGroup: alb.defaultTargetGroup }], }, }, }); -export const vpcId = vpc.vpcId; -export const serviceUrl = alb.loadBalancer.dnsName; -``` - -{{% /choosable %}} - -{{% choosable language python %}} - -```python -import pulumi -import pulumi_aws as aws -import pulumi_awsx as awsx - -# Create a VPC with automatic subnets -vpc = awsx.ec2.Vpc("main-vpc", - cidr_block="10.0.0.0/16", - number_of_availability_zones=2) - -# Create an ECS cluster -cluster = aws.ecs.Cluster("app-cluster") - -# Create an Application Load Balancer -alb = awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb", - vpc_id=vpc.vpc_id, - subnet_ids=vpc.public_subnet_ids) - -# Deploy a containerized application -service = awsx.ecs.FargateService("app-service", - cluster=cluster.arn, - task_definition_args=awsx.ecs.FargateServiceTaskDefinitionArgs( - container=awsx.ecs.TaskDefinitionContainerDefinitionArgs( - image="nginx:latest", - memory=128, - ports=[awsx.ecs.TaskDefinitionPortMappingArgs( - container_port=80, - target_group=alb.default_target_group - )] - ) - )) - -pulumi.export("vpc_id", vpc.vpc_id) -pulumi.export("service_url", alb.load_balancer.dns_name) -``` - -{{% /choosable %}} - -{{% choosable language go %}} - -```go -package main - -import ( - "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ecs" - "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ec2" - "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/elasticloadbalancingv2" - awsxecs "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ecs" - "github.com/pulumi/pulumi/sdk/v3/go/pulumi" -) - -func main() { - pulumi.Run(func(ctx *pulumi.Context) error { - // Create a VPC with automatic subnets - vpc, err := ec2.NewVpc(ctx, "main-vpc", &ec2.VpcArgs{ - CidrBlock: pulumi.String("10.0.0.0/16"), - NumberOfAvailabilityZones: pulumi.Int(2), - }) - if err != nil { - return err - } - - // Create an ECS cluster - cluster, err := ecs.NewCluster(ctx, "app-cluster", nil) - if err != nil { - return err - } - - // Create an Application Load Balancer - alb, err := elasticloadbalancingv2.NewApplicationLoadBalancer(ctx, "app-alb", &elasticloadbalancingv2.ApplicationLoadBalancerArgs{ - VpcId: vpc.VpcId, - SubnetIds: vpc.PublicSubnetIds, - }) - if err != nil { - return err - } - - // Deploy a containerized application - _, err = awsxecs.NewFargateService(ctx, "app-service", &awsxecs.FargateServiceArgs{ - Cluster: cluster.Arn, - TaskDefinitionArgs: &awsxecs.FargateServiceTaskDefinitionArgs{ - Container: &awsxecs.TaskDefinitionContainerDefinitionArgs{ - Image: pulumi.String("nginx:latest"), - Memory: pulumi.Int(128), - Ports: awsxecs.TaskDefinitionPortMappingArray{ - &awsxecs.TaskDefinitionPortMappingArgs{ - ContainerPort: pulumi.Int(80), - TargetGroup: alb.DefaultTargetGroup, - }, - }, - }, - }, - }) - if err != nil { - return err - } - - ctx.Export("vpcId", vpc.VpcId) - ctx.Export("serviceUrl", alb.LoadBalancer.DnsName()) - return nil - }) -} -``` - -{{% /choosable %}} - -{{% choosable language csharp %}} - -```csharp -using System.Collections.Generic; -using Pulumi; -using Aws = Pulumi.Aws; -using Awsx = Pulumi.Awsx; - -return await Deployment.RunAsync(() => -{ - // Create a VPC with automatic subnets - var vpc = new Awsx.Ec2.Vpc("main-vpc", new() - { - CidrBlock = "10.0.0.0/16", - NumberOfAvailabilityZones = 2, - }); - - // Create an ECS cluster - var cluster = new Aws.Ecs.Cluster("app-cluster"); - - // Create an Application Load Balancer - var alb = new Awsx.ElasticLoadBalancingV2.ApplicationLoadBalancer("app-alb", new() - { - VpcId = vpc.VpcId, - SubnetIds = vpc.PublicSubnetIds, - }); - - // Deploy a containerized application - var service = new Awsx.Ecs.FargateService("app-service", new() - { - Cluster = cluster.Arn, - TaskDefinitionArgs = new Awsx.Ecs.Inputs.FargateServiceTaskDefinitionArgs - { - Container = new Awsx.Ecs.Inputs.TaskDefinitionContainerDefinitionArgs - { - Image = "nginx:latest", - Memory = 128, - Ports = new[] - { - new Awsx.Ecs.Inputs.TaskDefinitionPortMappingArgs - { - ContainerPort = 80, - TargetGroup = alb.DefaultTargetGroup, - }, - }, - }, - }, - }); - - return new Dictionary - { - ["vpcId"] = vpc.VpcId, - ["serviceUrl"] = alb.LoadBalancer.Apply(lb => lb.DnsName), - }; -}); -``` - -{{% /choosable %}} - -{{% choosable language yaml %}} - -```yaml -name: aws-ecs-example -runtime: yaml -description: An example that deploys an ECS Fargate service with load balancer - -resources: - # Create a VPC with automatic subnets - main-vpc: - type: awsx:ec2:Vpc - properties: - cidrBlock: "10.0.0.0/16" - numberOfAvailabilityZones: 2 - - # Create an ECS cluster - app-cluster: - type: aws:ecs:Cluster - - # Create an Application Load Balancer - app-alb: - type: awsx:elasticloadbalancingv2:ApplicationLoadBalancer - properties: - vpcId: ${main-vpc.vpcId} - subnetIds: ${main-vpc.publicSubnetIds} - - # Deploy a containerized application - app-service: - type: awsx:ecs:FargateService - properties: - cluster: ${app-cluster.arn} - taskDefinitionArgs: - container: - image: "nginx:latest" - memory: 128 - ports: - - containerPort: 80 - targetGroup: ${app-alb.defaultTargetGroup} - -outputs: - vpcId: ${main-vpc.vpcId} - serviceUrl: ${app-alb.loadBalancer.dnsName} +export const url = alb.loadBalancer.dnsName; ``` -{{% /choosable %}} - -Key Features: - -- **General-purpose language support**: Use Python, TypeScript, Go, C#, Java, or YAML without learning new DSLs -- **Software engineering practices**: Full IDE support, comprehensive testing frameworks, debugging capabilities -- **Multi-cloud flexibility**: Native cloud provider SDKs with same-day feature access across [150+ providers](/registry/) -- **Incremental adoption**: Migration tools and state integration for gradual transitions -- **Open source licensing**: Apache 2.0 ensures long-term freedom and flexibility - -Considerations: - -- **Learning curve**: Teams new to programming may prefer template-based approaches initially -- **Ecosystem maturity**: Smaller community compared to more established tools like Terraform -- **Tool complexity**: Advanced features may require more setup than simpler template systems - -Organizations like Unity, Snowflake, and Starburst have reported significant productivity improvements (80-90% deployment time reductions) when adopting programming language-based approaches. These improvements typically occur when transitioning from manual processes or basic template systems to automated approaches with comprehensive testing, IDE integration, and code reusability. Results vary based on starting point, team expertise, infrastructure complexity, and specific use cases. +External resources: [pulumi.com](https://www.pulumi.com/), [Pulumi Registry](/registry/), [Compare Pulumi to alternatives](/docs/iac/comparisons/). -> **Ready to get started?** [Experience Pulumi's programming language approach](/docs/get-started/) and see how familiar languages can transform your infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support. +### Terraform -### 2. Terraform +- License: Business Source License (BUSL) 1.1 — source-available, not OSI open source +- Languages: HCL (HashiCorp Configuration Language) +- Best for: teams with existing HCL expertise, large module ecosystems, and established Terraform workflows -License: Business Source License (BSL) 1.1 (Not Open Source) -Best For: Teams with existing Terraform expertise and established workflows +[Terraform](/docs/iac/comparisons/terraform/), maintained by HashiCorp (an IBM company since 2025), is the most widely deployed IaC tool. Its plan/apply lifecycle and provider model became the de-facto pattern for the industry. Terraform's main differentiators in 2026 are the size of its provider and module ecosystems and the depth of community knowledge. -[Terraform](/docs/iac/comparisons/terraform/) uses HashiCorp Configuration Language (HCL) to define infrastructure across multiple cloud providers. However, its 2023 licensing change to BSL (no longer open source) and inherent limitations with domain-specific languages create challenges for teams requiring advanced software engineering practices. - -Key Features: - -- **Extensive provider ecosystem**: Largest collection of community-maintained providers covering virtually every cloud service -- **Established workflows**: Mature plan-and-apply process with extensive tooling and CI/CD integrations -- **Community and resources**: Vast ecosystem of modules, extensive documentation, training materials, and community support -- **Enterprise adoption**: Widely adopted in enterprises with established processes and expertise -- **Module ecosystem**: Rich collection of reusable Terraform modules for common patterns - -When Terraform Works Well: - -- Teams with existing HCL expertise and Terraform investments -- Infrastructure patterns that fit well within HCL's declarative model -- Teams comfortable with template-based approaches - -Considerations for Complex Scenarios: - -- **Language constraints**: HCL's domain-specific nature can require workarounds for complex logic compared to general-purpose programming languages -- **Testing approach**: Primarily supports integration testing; teams needing comprehensive unit testing may require additional tooling -- **IDE experience**: While improving, HCL tooling provides less comprehensive support than mature programming language ecosystems -- **State management**: Requires manual backend configuration and locking setup for team collaboration - -Code Example: +In August 2023, HashiCorp moved Terraform from the Mozilla Public License (MPL) 2.0 to the Business Source License (BUSL) 1.1, which prohibits use in competing commercial products but otherwise permits production use. The license has not changed following IBM's acquisition; teams with strict open-source policies often pair or replace Terraform with [OpenTofu](#opentofu). ```hcl data "aws_availability_zones" "available" {} resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" - - tags = { - Name = "main-vpc" - } + tags = { Name = "main-vpc" } } resource "aws_subnet" "public" { @@ -448,319 +153,133 @@ resource "aws_subnet" "public" { vpc_id = aws_vpc.main.id cidr_block = "10.0.${count.index + 1}.0/24" availability_zone = data.aws_availability_zones.available.names[count.index] - - tags = { - Name = "public-subnet-${count.index + 1}" - } } ``` -### 3. AWS Cloud Development Kit (CDK) - -License: Apache 2.0 -Best For: AWS-focused teams who prefer programming languages over templates +External resources: [terraform.io](https://www.terraform.io/), [HashiCorp BUSL FAQ](https://www.hashicorp.com/license-faq). -AWS CDK allows you to define AWS infrastructure using familiar programming languages, synthesizing CloudFormation templates for deployment while providing higher-level abstractions. CDK addresses many limitations of traditional template-based approaches by enabling general-purpose programming languages. +### OpenTofu -Key Features: +- License: Mozilla Public License (MPL) 2.0 +- Languages: HCL +- Best for: teams that want a Terraform-compatible workflow under a permissive open-source license with neutral governance -- **General-purpose programming languages**: TypeScript, Python, Java, C#, JavaScript support with full IDE integration (Go available in Developer Preview) -- **AWS-optimized constructs**: High-level components encapsulating AWS best practices -- **Type safety**: Compile-time checking and IntelliSense support -- **CloudFormation reliability**: Built on AWS's proven deployment engine +[OpenTofu](/docs/iac/comparisons/opentofu/) is an open-source fork of Terraform 1.5.x created in 2023 in response to the BUSL change. It is governed by the Linux Foundation and developed by maintainers from Gruntwork, Spacelift, Harness, env0, Scalr, and the broader community. Most existing Terraform configurations, providers, and modules work with OpenTofu unchanged. -Notable Limitations: +OpenTofu has added features Terraform does not ship, including client-side state encryption (PBKDF2, AWS KMS, GCP KMS), early variable evaluation, dynamic provider configuration, and the `-exclude` flag for resource exclusion. The latest stable release is 1.11. -- **AWS-only ecosystem**: Locked into single cloud provider, limiting multi-cloud strategies -- **CloudFormation constraints**: Inherits template size limits and deployment restrictions -- **Vendor lock-in**: Deep AWS integration makes migration to other clouds challenging -- **Limited cross-cloud consistency**: Teams need different tools and approaches for multi-cloud deployments +External resources: [opentofu.org](https://opentofu.org/), [OpenTofu on GitHub](https://github.com/opentofu/opentofu). -CDK represents a significant improvement over CloudFormation templates but constrains organizations to AWS-only infrastructure strategies. +## Cloud-native provisioning tools -Code Example: - -```typescript -import * as cdk from 'aws-cdk-lib'; -import * as ec2 from 'aws-cdk-lib/aws-ec2'; -import * as ecs from 'aws-cdk-lib/aws-ecs'; -import { Construct } from 'constructs'; +These first-party tools are tied to a single cloud. They get day-zero support for new services and deep integration with the rest of the provider's platform, in exchange for vendor lock-in. -export class MyStack extends cdk.Stack { - constructor(scope: Construct, id: string, props?: cdk.StackProps) { - super(scope, id, props); +### AWS CloudFormation - const vpc = new ec2.Vpc(this, 'MyVpc', { - maxAzs: 2 - }); +- License: Proprietary AWS service +- Languages: YAML, JSON +- Best for: AWS-only workloads that need maximum service coverage and AWS-managed state - const cluster = new ecs.Cluster(this, 'MyCluster', { - vpc: vpc - }); - - const taskDefinition = new ecs.FargateTaskDefinition(this, 'TaskDef', { - memoryLimitMiB: 512, - cpu: 256 - }); - - taskDefinition.addContainer('web', { - image: ecs.ContainerImage.fromRegistry('nginx:latest'), - portMappings: [{ containerPort: 80 }] - }); - - new ecs.FargateService(this, 'MyService', { - cluster: cluster, - taskDefinition: taskDefinition - }); - } -} -``` - -### 4. AWS CloudFormation - -License: Proprietary (AWS Service) -Best For: AWS-only deployments requiring deep service integration - -AWS CloudFormation provides the foundation for infrastructure as code on AWS, offering native integration with all AWS services and deep platform-specific features. - -Pulumi Integration: Pulumi provides [native AWS providers](/docs/clouds/aws/) that offer the same comprehensive AWS service coverage as CloudFormation, with the added benefit of using general-purpose programming languages. You can also [import existing CloudFormation stacks](/docs/using-pulumi/adopting-pulumi/import/) into Pulumi for gradual migration or hybrid management approaches. - -Key Features: - -- **AWS-native**: First-party support for all AWS services -- **JSON/YAML templates**: Declarative resource definitions -- **Stack management**: Organized resource grouping and lifecycle management -- **Change sets**: Preview infrastructure changes before deployment -- **Service integration**: Deep integration with other AWS services - -Code Example: +[AWS CloudFormation](/docs/iac/comparisons/cloud-templates/cloudformation/) is the AWS-native IaC service. Templates describe stacks of AWS resources, and CloudFormation handles dependency ordering, change sets (preview), drift detection, and rollback. State is stored and managed by AWS — there is no separate state file to manage. ```yaml -AWSTemplateFormatVersion: '2010-09-09' +AWSTemplateFormatVersion: "2010-09-09" Resources: MyVPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsHostnames: true - Tags: - - Key: Name - Value: MyVPC - - MySubnet: - Type: AWS::EC2::Subnet - Properties: - VpcId: !Ref MyVPC - CidrBlock: 10.0.1.0/24 - AvailabilityZone: !Select [0, !GetAZs ''] ``` -### 5. Azure Resource Manager (ARM) +External resources: [aws.amazon.com/cloudformation](https://aws.amazon.com/cloudformation/). -License: Proprietary (Microsoft Service) -Best For: Azure-native deployments requiring comprehensive platform integration +### AWS CDK -Azure Resource Manager provides the foundational infrastructure as code solution for Microsoft Azure, offering complete support for Azure services through JSON-based ARM templates. As Azure's native IaC solution, ARM templates provide the most comprehensive coverage of Azure services and features. +- License: Apache 2.0 +- Languages: TypeScript, Python, Java, .NET, Go (developer preview) +- Best for: AWS-only teams who want programming-language abstractions on top of CloudFormation -Pulumi Integration: Pulumi's [native Azure providers](/docs/clouds/azure/) offer equivalent comprehensive Azure service coverage with general-purpose programming languages. ARM templates can be [imported into Pulumi](/docs/using-pulumi/adopting-pulumi/import/), and you can reference ARM deployments from Pulumi programs for hybrid scenarios. +[AWS Cloud Development Kit (CDK)](/docs/iac/comparisons/cloud-template-transpilers/aws-cdk/) lets you define AWS infrastructure in familiar programming languages, then synthesizes CloudFormation templates that AWS deploys. CDK ships high-level "L2" and "L3" constructs that encode AWS best practices (VPCs with sensible defaults, ECS patterns, etc.), giving CDK an opinionated developer experience. Because CDK targets CloudFormation, it inherits both its strengths (managed state, deep AWS integration) and its constraints (template size limits, AWS-only). -Key Features: +```typescript +import * as cdk from "aws-cdk-lib"; +import * as ec2 from "aws-cdk-lib/aws-ec2"; +import * as ecs from "aws-cdk-lib/aws-ecs"; +import { Construct } from "constructs"; -- **Azure-native**: Complete Azure service coverage with first-party support -- **JSON templates**: Declarative resource definitions in JSON format -- **Resource groups**: Logical organization of related resources -- **Deployment modes**: Complete or incremental deployment options -- **Comprehensive integration**: Deep integration with Azure services and features +export class MyStack extends cdk.Stack { + constructor(scope: Construct, id: string, props?: cdk.StackProps) { + super(scope, id, props); -Code Example: + const vpc = new ec2.Vpc(this, "MyVpc", { maxAzs: 2 }); + const cluster = new ecs.Cluster(this, "MyCluster", { vpc }); -```json -{ - "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", - "contentVersion": "1.0.0.0", - "resources": [ - { - "type": "Microsoft.Storage/storageAccounts", - "apiVersion": "2023-01-01", - "name": "mystorageaccount", - "location": "[resourceGroup().location]", - "sku": { - "name": "Standard_LRS" - }, - "kind": "StorageV2" - } - ] + const task = new ecs.FargateTaskDefinition(this, "TaskDef"); + task.addContainer("web", { + image: ecs.ContainerImage.fromRegistry("nginx:latest"), + portMappings: [{ containerPort: 80 }], + }); + + new ecs.FargateService(this, "MyService", { cluster, taskDefinition: task }); + } } ``` -### 6. Azure Bicep +External resources: [aws.amazon.com/cdk](https://aws.amazon.com/cdk/). + +### Azure Resource Manager (ARM) -License: MIT -Best For: Azure deployments requiring improved readability and developer experience +- License: Proprietary Microsoft service +- Languages: JSON +- Best for: Azure deployments that need maximum-fidelity, ARM-template-only tooling -Azure Bicep is a domain-specific language (DSL) that simplifies Azure Resource Manager template authoring. Bicep files compile transparently to ARM templates, providing all the capabilities of ARM with significantly improved syntax and developer experience. +Azure Resource Manager is the underlying deployment service for Azure. ARM templates declare resources in JSON; Azure manages state, ordering, and rollback. ARM templates remain the lowest common denominator on Azure — every Azure deployment, including from Bicep or third-party tools, ultimately resolves to ARM. -Key Features: +External resources: [Azure Resource Manager docs](https://learn.microsoft.com/azure/azure-resource-manager/). -- **Simplified syntax**: Clean, readable syntax compared to JSON ARM templates -- **ARM compilation**: Compiles to ARM templates for deployment, ensuring full compatibility -- **Type safety**: Strong typing and IntelliSense support in development environments -- **Modular design**: Support for modules and code reuse across projects -- **Azure-native**: Complete Azure service coverage through ARM template compilation +### Azure Bicep -Code Example: +- License: MIT +- Languages: Bicep (a domain-specific language) +- Best for: Azure-first teams who want a cleaner authoring experience than ARM JSON + +[Bicep](https://learn.microsoft.com/azure/azure-resource-manager/bicep/overview) is Microsoft's open-source DSL for Azure that compiles transparently to ARM templates. It is roughly 50% less verbose than the equivalent JSON, supports modules, has strong type safety and IntelliSense in VS Code, and gets day-zero support for new Azure resource types and API versions. ```bicep -@description('Storage Account type') -@allowed([ - 'Standard_LRS' - 'Standard_GRS' - 'Standard_ZRS' - 'Premium_LRS' -]) -param storageAccountType string = 'Standard_LRS' - -@description('Location for the storage account.') param location string = resourceGroup().location -resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = { - name: 'mystorageaccount' +resource storage 'Microsoft.Storage/storageAccounts@2023-05-01' = { + name: 'mystorageacct' location: location - sku: { - name: storageAccountType - } + sku: { name: 'Standard_LRS' } kind: 'StorageV2' - properties: {} } ``` -### 7. Google Cloud Infrastructure Manager - -License: Proprietary (Google Service) -Best For: Google Cloud Platform deployments using Terraform +External resources: [Bicep on GitHub](https://github.com/Azure/bicep), [Bicep documentation](https://learn.microsoft.com/azure/azure-resource-manager/bicep/). -Google Cloud Infrastructure Manager automates the deployment and management of Google Cloud infrastructure resources using Terraform configurations, representing Google's modern approach to infrastructure as code. Infrastructure Manager replaces Google Cloud Deployment Manager, which will reach end of support on December 31, 2025. +### Google Cloud Infrastructure Manager -Key Features: +- License: Proprietary Google service +- Languages: HCL (standard Terraform configurations) +- Best for: GCP-standardized teams that want a managed Terraform runner -- **Terraform-based**: Uses standard Terraform configurations declaratively -- **Automated workflows**: Handles Terraform init, validate, and apply operations -- **Version control integration**: Supports Git repositories and Cloud Storage -- **Deployment tracking**: Comprehensive metadata storage and logging -- **Multiple Terraform versions**: Flexibility in Terraform version selection -- **Cloud Build integration**: Leverages Google Cloud Build for execution environment -- **Migration path**: Provides upgrade path from legacy Cloud Deployment Manager +Google Cloud Infrastructure Manager is a managed service that runs Terraform configurations against Google Cloud, with deployment metadata, audit logging, and Cloud Build-based execution. It is the supported successor to Google Cloud Deployment Manager, which reaches end of support on December 31, 2025. -Code Example: +External resources: [Infrastructure Manager docs](https://cloud.google.com/infrastructure-manager/docs). -```hcl -# main.tf - Terraform configuration for Infrastructure Manager -resource "google_compute_instance" "vm_instance" { - name = "my-vm" - machine_type = "e2-medium" - zone = "us-central1-a" - - boot_disk { - initialize_params { - image = "debian-cloud/debian-11" - } - } +## Kubernetes-native tools - network_interface { - network = "default" - access_config { - // Ephemeral public IP - } - } +These tools manage infrastructure through the Kubernetes API. The Kubernetes control loop continuously reconciles the live state of resources to match what is declared in YAML manifests. - metadata = { - startup-script = "echo Hello from Infrastructure Manager!" - } -} +### Crossplane -output "instance_ip" { - value = google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip -} -``` +- License: Apache 2.0 (CNCF project) +- Languages: YAML (Kubernetes Custom Resource Definitions) +- Best for: platform engineering teams building internal developer platforms on Kubernetes -### 8. Kubernetes YAML - -License: Apache 2.0 -Best For: Teams managing container-native applications and cloud-native infrastructure - -Kubernetes YAML manifests represent one of the most widely adopted forms of infrastructure as code, enabling teams to define, version, and manage containerized applications and their supporting infrastructure through declarative configuration files. - -Key Features: - -- **Declarative configuration**: Define desired state through human-readable YAML files -- **Native Kubernetes integration**: Direct integration with Kubernetes API without additional tools -- **GitOps compatibility**: Version control YAML files for automated deployment workflows -- **Resource relationships**: Define dependencies and relationships between Kubernetes resources -- **Extensive ecosystem**: Rich ecosystem of operators and custom resources extending functionality - -Code Example: - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: web-app - labels: - app: web-app -spec: - replicas: 3 - selector: - matchLabels: - app: web-app - template: - metadata: - labels: - app: web-app - spec: - containers: - - name: web-app - image: nginx:1.21 - ports: - - containerPort: 80 - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" ---- -apiVersion: v1 -kind: Service -metadata: - name: web-app-service -spec: - selector: - app: web-app - ports: - - port: 80 - targetPort: 80 - type: LoadBalancer -``` - -### 9. Crossplane - -License: Apache 2.0 -Best For: Kubernetes-first organizations managing multi-cloud infrastructure - -Crossplane is a Cloud-Native Framework for Platform Engineering that extends Kubernetes to help organizations build custom infrastructure management platforms, allowing teams to provision and manage cloud resources using Kubernetes APIs and patterns. - -Pulumi Integration: Pulumi offers the [Pulumi Kubernetes Operator (PKO)](/docs/using-pulumi/continuous-delivery/pulumi-kubernetes-operator/) that provides similar Kubernetes-native infrastructure management capabilities, plus support for YAML-based definitions. Teams can also use Pulumi programs to provision the underlying infrastructure that Crossplane manages, creating layered infrastructure management approaches. - -Key Features: - -- **Kubernetes-native**: Uses CRDs and standard Kubernetes patterns -- **Composite resources**: Create higher-level infrastructure abstractions -- **GitOps compatibility**: Seamless integration with GitOps workflows -- **Multi-cloud support**: Provision resources across cloud providers -- **Policy integration**: Leverage Kubernetes RBAC and admission controllers - -Code Example: +[Crossplane](/docs/iac/comparisons/crossplane/) extends Kubernetes with Custom Resource Definitions for cloud resources, so you can `kubectl apply` an S3 bucket, an RDS database, or a Cloud SQL instance the same way you would a Deployment. Composite Resource Definitions (XRDs) let platform teams package higher-level abstractions (for example, a "Database" XR that provisions backups, networking, and IAM behind one API). Crossplane v2 became generally available in 2025. ```yaml apiVersion: ec2.aws.crossplane.io/v1alpha1 @@ -770,622 +289,211 @@ metadata: spec: cidrBlock: 10.0.0.0/16 region: us-east-1 - tags: - Name: sample-vpc providerConfigRef: name: aws-provider-config ``` -### 10. OpenTofu - -License: Mozilla Public License 2.0 -Best For: Teams seeking an open-source Terraform alternative with community governance - -OpenTofu emerged as a fork of Terraform v1.5.x following HashiCorp's license change, maintained by the Linux Foundation. It provides [full compatibility with Terraform](/docs/iac/concepts/vs/opentofu/) while ensuring long-term open-source availability under MPL 2.0 licensing. - -Key Features: - -- **True open source**: MPL 2.0 license with community governance via Linux Foundation ensuring long-term accessibility -- **Terraform compatibility**: Drop-in replacement maintaining existing workflows, modules, and provider ecosystem -- **Community-driven development**: Transparent roadmap, open contribution process, and vendor-neutral governance -- **License certainty**: Removes concerns about future licensing restrictions for commercial use - -When OpenTofu Makes Sense: - -- Organizations requiring guaranteed open-source licensing for compliance or philosophical reasons -- Teams with significant Terraform investments wanting to avoid vendor lock-in -- Environments where community governance and transparency are priorities -- Projects needing long-term license stability - -Architectural Considerations: -As a Terraform fork, OpenTofu inherits the same architectural approach, which means teams evaluating it should consider whether HCL-based infrastructure definition meets their long-term needs for testing, IDE integration, and developer productivity, or whether a programming language-based approach might better serve complex scenarios. - -Code Example: - -```hcl -resource "aws_instance" "web" { - ami = "ami-0c55b159cbfafe1d0" - instance_type = "t3.micro" - - tags = { - Name = "HelloWorld" - } -} - -output "instance_ip" { - value = aws_instance.web.public_ip -} -``` - -### Ansible - -License: GPL v3 -Best For: Configuration management with some infrastructure provisioning capabilities - -> [!INFO] -> Ansible is primarily a configuration management tool, not a pure Infrastructure as Code tool. While Ansible can provision some cloud resources, its core strength lies in configuring and managing software on existing systems rather than comprehensive infrastructure provisioning. - -Ansible provides configuration management and limited infrastructure provisioning through its agentless architecture and simple YAML-based playbooks. - -Pulumi Integration: Rather than competing with Ansible, Pulumi complements it perfectly. Use Pulumi for infrastructure provisioning and Ansible for configuration management. Pulumi's Command provider can execute Ansible playbooks as part of your infrastructure deployment, and many Pulumi customers use both tools together for comprehensive infrastructure automation. [See example: Deploy WordPress to AWS using Pulumi and Ansible](/blog/deploy-wordpress-aws-pulumi-ansible/). - -Key Features: - -- **Agentless architecture**: No software installation required on target systems -- **YAML playbooks**: Human-readable automation definitions -- **Idempotent operations**: Safe to run multiple times -- **Large module library**: Extensive built-in functionality for various systems -- **Push-based execution**: Centralized control and execution - -Code Example: - -```yaml ---- -- name: Provision AWS infrastructure - hosts: localhost - tasks: - - name: Create VPC - amazon.aws.ec2_vpc_net: - name: ansible-vpc - cidr_block: 10.0.0.0/16 - region: us-east-1 - tags: - Environment: production - register: vpc - - - name: Create subnet - amazon.aws.ec2_vpc_subnet: - vpc_id: "{{ vpc.vpc.id }}" - cidr: 10.0.1.0/24 - region: us-east-1 - tags: - Name: ansible-subnet -``` - -### Chef - -License: Apache 2.0 -Best For: Complex configuration management scenarios requiring programmable logic - -> [!INFO] -> Chef is a configuration management tool, not an Infrastructure as Code tool. Chef focuses on configuring and maintaining software, services, and system settings on existing infrastructure rather than provisioning cloud resources. - -Chef provides configuration management and system automation using Ruby-based recipes and cookbooks, offering powerful programmability for complex configuration scenarios. - -Key Features: - -- **Ruby DSL**: Full programming language for configuration logic -- **Agent-based architecture**: Continuous compliance and drift detection -- **Cookbook ecosystem**: Reusable configuration patterns and community recipes -- **Test Kitchen**: Infrastructure testing and validation framework -- **Enterprise features**: Advanced reporting and compliance capabilities - -Code Example: - -```ruby -# cookbook/recipes/default.rb -package 'nginx' do - action :install -end - -service 'nginx' do - action [:enable, :start] -end - -template '/etc/nginx/sites-available/default' do - source 'default.erb' - owner 'root' - group 'root' - mode '0644' - notifies :restart, 'service[nginx]' -end -``` - -### Puppet - -License: Apache 2.0 -Best For: Enterprise environments requiring strong governance and compliance - -> [!INFO] -> Puppet is a configuration management tool, not an Infrastructure as Code tool. Puppet specializes in maintaining desired configuration state on existing systems and ensuring compliance, rather than provisioning cloud infrastructure. - -Puppet offers enterprise-grade configuration management with a focus on compliance, governance, and declarative system state management. - -Key Features: - -- **Declarative language**: Puppet DSL for describing desired system state -- **Compliance reporting**: Built-in governance and audit capabilities -- **Forge marketplace**: Community modules and enterprise content -- **Enterprise support**: Professional services and enterprise features -- **Continuous enforcement**: Ongoing configuration compliance monitoring - -Code Example: - -```puppet -# manifests/webserver.pp -class webserver { - package { 'nginx': - ensure => installed, - } - - service { 'nginx': - ensure => running, - enable => true, - require => Package['nginx'], - } - - file { '/var/www/html/index.html': - ensure => file, - content => '

Hello from Puppet!

', - owner => 'www-data', - group => 'www-data', - mode => '0644', - } -} -``` - -### Salt - -License: Apache 2.0 -Best For: Python-oriented teams requiring high-performance configuration management - -> [!INFO] -> Salt is primarily a configuration management and remote execution tool, not a pure Infrastructure as Code tool. While Salt can manage some infrastructure components, its primary focus is on configuring systems and executing commands across large infrastructures. - -Salt provides fast, scalable configuration management and remote execution using Python, designed for high-performance system automation at scale. - -Key Features: - -- **Python-based**: Leverage the Python ecosystem and libraries -- **High performance**: Fast execution across large infrastructures -- **Event-driven automation**: Reactive automation and orchestration -- **Pillar data system**: Secure, hierarchical data management -- **Flexible communication**: Support for various communication patterns - -Code Example: - -```yaml -# /srv/salt/webserver.sls -nginx: - pkg.installed: [] - service.running: - - enable: True - - require: - - pkg: nginx - -/var/www/html/index.html: - file.managed: - - source: salt://files/index.html - - user: www-data - - group: www-data - - mode: 644 -``` - -## Infrastructure as Code Tools - -### Kubernetes - Container Orchestration Platform - -License: Apache 2.0 -Best For: Container-native infrastructure and application management - -While primarily a [container orchestration](/topics/containers/) platform, Kubernetes itself serves as an infrastructure as code tool through its declarative YAML manifests and API-driven resource management. +External resources: [crossplane.io](https://www.crossplane.io/). -Key Features: +### Kubernetes YAML -- **Declarative configuration**: YAML-based resource definitions -- **API-driven**: RESTful API for all resource operations -- **Self-healing**: Automatic recovery and reconciliation -- **Extensible**: Custom resources and controllers -- **GitOps compatible**: Works seamlessly with Git-based workflows +- License: Apache 2.0 +- Languages: YAML +- Best for: defining the workloads, services, ingresses, and policies that run on a Kubernetes cluster -Code Example: +Kubernetes YAML manifests are themselves a form of IaC. The Kubernetes API server validates them; controllers and operators reconcile them continuously. They pair well with GitOps tools (Argo CD, Flux) and with provisioning tools that create the cluster and its supporting cloud resources. ```yaml apiVersion: apps/v1 kind: Deployment metadata: - name: nginx-deployment + name: web-app spec: replicas: 3 selector: - matchLabels: - app: nginx + matchLabels: { app: web-app } template: metadata: - labels: - app: nginx + labels: { app: web-app } spec: containers: - - name: nginx - image: nginx:1.21 - ports: - - containerPort: 80 ---- -apiVersion: v1 -kind: Service -metadata: - name: nginx-service -spec: - selector: - app: nginx - ports: - - port: 80 - targetPort: 80 - type: LoadBalancer -``` - -## Infrastructure as Code Security and Compliance Tools - -While the tools above focus on provisioning and managing infrastructure, a complete IaC ecosystem includes security scanning and compliance tools. These tools complement your primary IaC tool by providing security analysis, policy enforcement, and compliance checking: - -### Security Scanning Tools - -Snyk - License: Proprietary -Leading developer security platform that includes comprehensive infrastructure as code scanning alongside container and application security. Provides real-time vulnerability detection, compliance checking, and automated remediation guidance. Integrates with popular development tools and CI/CD pipelines with extensive enterprise adoption. - -Wiz - License: Proprietary -Comprehensive cloud security platform that includes infrastructure as code scanning capabilities. Provides vulnerability management, compliance monitoring, and security posture assessment across cloud environments. Offers integration with development workflows and supports multiple IaC formats with strong enterprise presence. - -Checkov - License: Apache 2.0 -Popular open-source static analysis tool for infrastructure as code that scans cloud infrastructure configurations for security and compliance issues. Supports Terraform, CloudFormation, Kubernetes, Helm, ARM templates, and more. Integrates with CI/CD pipelines and provides over 1000+ built-in policies covering CIS benchmarks, PCI DSS, and GDPR compliance. - -### Linting and Validation Tools - -TFLint - License: MPL 2.0 -Terraform linter focused on possible errors, best practices, and security issues in Terraform configurations. Provides pluggable rule sets for cloud providers (AWS, Azure, GCP) and helps enforce coding standards, detect deprecated syntax, and prevent common configuration errors. - -These security tools integrate into CI/CD pipelines alongside your chosen IaC tool to provide comprehensive security coverage throughout the infrastructure lifecycle. - -### Pulumi ESC - -License: Apache 2.0 (Open Source) / Proprietary (SaaS) -Best For: Teams needing centralized configuration and secrets management across environments and tools - -Pulumi ESC (Environments, Secrets, and Configuration) is a comprehensive platform for managing configuration data, secrets, and environment variables across your entire infrastructure and application stack. ESC provides a single source of truth for configuration that works with any infrastructure tool, not just Pulumi. - -Key Features: - -- **Universal configuration management**: Works with any infrastructure tool, CI/CD system, or application -- **Hierarchical environments**: Compose configuration from multiple sources with inheritance and overrides -- **Dynamic secrets**: Integration with cloud providers for short-lived credentials and just-in-time access -- **Policy-based access control**: Fine-grained permissions and audit logging for configuration access -- **Multiple consumption methods**: CLI, REST API, SDK integration, and direct cloud provider integration -- **GitOps workflows**: Version control integration with pull request-based configuration management - -Code Example: - -```yaml -# Production environment configuration -values: - app: - name: myapp - version: ${fn.fromJSON(aws.ecr.getAuthorizationToken).password} - database: - connectionString: ${pulumi.database.connectionString} -imports: - - shared/common - - aws/production + - name: web-app + image: nginx:1.27 + ports: [{ containerPort: 80 }] ``` -### Pulumi Insights - -License: Proprietary (SaaS) -Best For: Organizations needing comprehensive cloud resource visibility, search, and compliance monitoring - -Pulumi Insights provides cloud resource search, analytics, and compliance capabilities across your entire multi-cloud infrastructure, regardless of how resources were provisioned. It offers a unified view of your cloud resources with powerful search, cost analysis, and policy enforcement. - -Key Features: - -- **Universal cloud inventory**: Discover and catalog resources across AWS, Azure, Google Cloud, and Kubernetes -- **Advanced search and analytics**: Query resources by tags, properties, relationships, and compliance status -- **Cost optimization insights**: Resource cost analysis, trends, and optimization recommendations -- **Compliance monitoring**: Continuous policy evaluation and drift detection across all cloud resources -- **Resource relationships**: Understand dependencies and relationships between cloud resources -- **Integration with any IaC tool**: Works with resources created by Pulumi, Terraform, CloudFormation, or manually - -Use Cases: - -- **Cloud governance**: Ensure compliance with organizational policies and industry standards -- **Cost management**: Identify unused resources and optimization opportunities -- **Security auditing**: Track resource configurations and detect security misconfigurations -- **Multi-cloud visibility**: Single pane of glass for resources across different cloud providers - -## Infrastructure Automation and Management Platforms - -While the above tools focus on defining and provisioning infrastructure, several platforms provide automation, orchestration, and management capabilities that work with Infrastructure as Code tools. Important: These are not IaC tools themselves, but rather automation platforms that rely on underlying IaC tools. - -### IaC Automation Platforms - -Pulumi Cloud -Best For: Teams using Pulumi IaC who need enterprise-grade collaboration, security, and governance - -Pulumi Cloud is the smartest and easiest way to automate, secure, and manage everything you run in the cloud. It serves as the managed service companion to Pulumi's open-source infrastructure as code tool, providing enterprise capabilities that extend beyond basic IaC functionality. - -The relationship between Pulumi IaC and Pulumi Cloud follows a Git/GitHub model: Pulumi IaC is like Git (fully open source and functional on its own), while Pulumi Cloud is like GitHub (a managed service that makes the open-source tool much easier to use securely at scale with teams). - -Key Features: - -- **Managed state backend**: Secure, scalable state management with transactional protocols -- **Team collaboration**: Full audit logs, RBAC, and identity provider integration -- **Centralized secrets management**: Pulumi ESC for configuration and secrets across environments -- **Cloud inventory and insights**: Pulumi Insights for search, compliance, and drift detection -- **Remote deployments**: CI/CD integrations and automated workflows -- **Policy enforcement**: Built-in security and compliance policy as code -- **Multi-product platform**: Integrated IaC, secrets management, and cloud insights - -Pulumi IaC works with or without Pulumi Cloud - you can use DIY backends (S3, Azure Blob, etc.) or the managed service. However, Pulumi Cloud becomes the default experience when you install the Pulumi CLI, providing instant collaboration capabilities without the overhead of building and maintaining your own infrastructure management platform. - -HashiCorp Cloud Platform (HCP) - License: Proprietary (SaaS) -Best For: Organizations standardizing on HashiCorp tools across infrastructure and security lifecycle management - -HashiCorp Cloud Platform (HCP) is an enterprise-grade SaaS platform that provides unified lifecycle management for infrastructure and security operations. HCP Terraform (formerly Terraform Cloud) serves as the managed service for Terraform/OpenTofu workflows, while the broader platform integrates multiple HashiCorp tools. - -Key Features: - -- **HCP Terraform management**: Workspace organization, remote execution, and state management for Terraform -- **Infrastructure lifecycle automation**: Continuous validation, drift detection, and module lifecycle management -- **Private VCS access**: Secure integration with private version control repositories -- **Policy enforcement**: Sentinel policy-as-code framework for compliance and governance -- **Integrated security services**: HCP Vault for secrets management, HCP Consul for service networking -- **Enterprise access controls**: RBAC, SAML SSO integration, and fine-grained permissions -- **Module and image management**: HCP Packer for automated machine/container image creation - -HCP focuses specifically on HashiCorp tool integration and provides a comprehensive platform for organizations that have standardized on the HashiCorp ecosystem for infrastructure and security operations. - -Spacelift - Spacelift is not an Infrastructure as Code tool—it's an automation and workflow platform that relies on other IaC tools like Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes. Spacelift provides CI/CD pipelines, policy enforcement, and collaboration features for teams using these underlying IaC tools. - -Env0 - Env0 is not an Infrastructure as Code tool—it's an automation platform that provides workflow management, governance, and collaboration features for existing IaC tools like Terraform, OpenTofu, and Terragrunt. It adds CI/CD pipelines, cost management, and policy enforcement on top of these tools. - -Atlantis - An open-source tool that provides GitOps-style workflows for Terraform and OpenTofu by automatically running terraform plan and apply operations via pull request automation. - -### Development Environment Tools - -Vagrant - Vagrant is not an Infrastructure as Code tool—it's a development environment management tool that creates and configures lightweight, reproducible virtual development environments. While it can provision VMs, its focus is on local development environments rather than cloud infrastructure provisioning. - -Docker Compose - While not an IaC tool, Docker Compose defines multi-container applications and can be used alongside IaC tools for application deployment after infrastructure provisioning. - -These platforms and tools serve important roles in the infrastructure automation ecosystem but should not be confused with Infrastructure as Code tools themselves. They enhance and orchestrate the work of actual IaC tools rather than replacing them. - -## The Future of Infrastructure as Code - -The infrastructure as code landscape is rapidly evolving toward software engineering maturity, with several transformative trends reshaping how organizations approach infrastructure: - -Software Engineering Convergence: The most significant trend is the convergence of infrastructure and software engineering practices. Organizations are moving away from limited DSLs toward full programming languages that enable testing, debugging, refactoring, and other software engineering best practices. This shift enables infrastructure teams to leverage the same tools, skills, and methodologies that have proven successful in application development. - -Real-Time Cloud Integration: Native cloud provider SDK integration is becoming the standard, replacing community-maintained providers that lag behind new cloud features. Organizations expect same-day access to new cloud services without waiting weeks or months for provider updates. - -Comprehensive Testing Paradigms: Infrastructure testing is evolving beyond basic integration tests to include unit testing, property-based testing, and continuous validation. Teams are applying test-driven development principles to infrastructure, catching issues before deployment rather than discovering them in production. - -Internal Developer Platform Evolution: Organizations are building sophisticated Internal Developer Platforms that provide self-service infrastructure capabilities while maintaining governance and compliance. These platforms leverage infrastructure as code tools to create standardized, reusable components that accelerate development velocity. +## Application and abstraction frameworks -AI-Enhanced Development: Integration of AI tools to help generate, optimize, and troubleshoot infrastructure code, with particular strength in environments that use familiar programming languages where AI assistance is most mature. Emerging technologies like Model Context Protocol (MCP) and AI prompt templates are beginning to enable more sophisticated AI-infrastructure interactions. +These frameworks sit on top of an underlying provisioning engine and trade some flexibility for a more opinionated developer experience. -These trends favor tools that embrace software engineering principles from the ground up, rather than attempting to retrofit programming capabilities onto template-based or DSL-limited approaches. +### SST -## Migration and Adoption Strategies +- License: MIT +- Languages: TypeScript +- Best for: full-stack TypeScript apps deployed primarily to AWS, with optional Cloudflare and other providers -Organizations don't need to choose between maintaining existing infrastructure and adopting modern IaC approaches. Proven migration strategies enable gradual adoption while preserving operational stability. +[SST](https://sst.dev/) is a framework for building full-stack applications where backend, frontend, and infrastructure are defined together in a single `sst.config.ts`. SST v3 ("Ion") and later use Pulumi as the underlying provisioning engine, which gives SST users access to Pulumi's provider catalog without learning Pulumi directly. SST is a strong fit for Next.js, Remix, and Astro apps on AWS. -### Incremental Adoption Approaches +External resources: [sst.dev](https://sst.dev/), [SST on GitHub](https://github.com/sst/sst). -Team-by-Team Migration: Start with new projects or specific teams, allowing gradual skill development and process refinement. Teams can maintain existing infrastructure while building new capabilities with modern tools. +### CDK for Terraform (CDKTF) -Project-by-Project Transition: Migrate individual applications or services incrementally, enabling teams to learn and optimize approaches before expanding scope. +- License: MPL 2.0 +- Languages: TypeScript, Python, Java, C#, Go +- Best for: historical reference — **CDKTF was deprecated by HashiCorp on December 10, 2025** -Hybrid Operations: Use state integration and import tools to reference existing infrastructure while building new components with modern IaC tools. +CDK for Terraform let teams author Terraform configurations in general-purpose languages by synthesizing them to Terraform JSON. HashiCorp announced CDKTF's deprecation on December 10, 2025; the tool is no longer supported or maintained, although existing configurations continue to work with current Terraform/OpenTofu providers. Teams that wanted programming-language IaC for Terraform-style workflows have moved to Pulumi or to Terraform with hand-written HCL. -### Proven Migration Timelines +External resources: [CDKTF documentation (archived)](https://developer.hashicorp.com/terraform/cdktf). -Real-world migrations demonstrate that adoption can be remarkably fast with proper tooling: +## Configuration management tools -- **Atlassian Bitbucket**: Complete Terraform to Pulumi migration in 2 days using automated conversion tools. This rapid migration was enabled by existing Python expertise on the team, well-structured Terraform code, and straightforward infrastructure patterns that converted cleanly. -- **Enterprise migrations**: Typical team migrations complete in weeks, not months, depending on infrastructure complexity and team preparation -- **Learning curve**: Teams with programming experience adapt to language-based IaC approaches within days, while those new to programming may require additional training time +Configuration management tools are not provisioning tools. They configure operating systems and applications on machines that already exist — installing packages, writing files, managing services, ensuring users and permissions. Most teams pair one of these with a provisioning tool: provision a VM with Pulumi/Terraform, then configure it with Ansible (or Chef, Puppet, Salt). -### Migration Tools and Resources - -Automated Conversion: Tools like tf2pulumi and pulumi convert automatically translate existing infrastructure definitions, preserving logic and structure while upgrading to modern approaches. - -State Integration: Import existing cloud resources and reference Terraform state during transition periods, enabling zero-downtime migrations. - -Training and Support: Comprehensive documentation, tutorials, and community resources accelerate team onboarding and reduce migration risks. - -### Best Practices for Successful Adoption - -1. **Start with pilot projects** to build confidence and establish patterns -2. **Leverage automated migration tools** to reduce manual conversion effort -3. **Maintain state integration** during transition periods for operational continuity -4. **Invest in team training** to maximize productivity gains from modern approaches -5. **Establish testing practices** early to realize reliability and quality benefits - -The key insight: migration to modern IaC approaches is a technical upgrade, not a complete rebuild. Organizations can preserve existing investments while gaining access to superior tooling and practices. - -## Frequently Asked Questions - -### Which IaC tool should I choose for AWS? - -For teams wanting programming languages: Pulumi IaC and AWS CDK both offer excellent developer experiences with general-purpose programming languages. Pulumi provides multi-cloud flexibility, while CDK offers deep AWS-native integration. - -For AWS-only deployments: CloudFormation provides the deepest native AWS service support and direct integration with AWS services. - -For Terraform ecosystem users: OpenTofu provides open-source licensing with Terraform compatibility, while Terraform offers extensive community resources and established workflows. - -### Is Terraform still worth learning in 2025? - -Terraform remains a valuable skill and viable choice for many scenarios, though teams should consider their specific needs and long-term goals: - -When Terraform Makes Sense: - -- Teams building on existing Terraform infrastructure and expertise -- Organizations with successful Terraform workflows and established processes -- Projects that benefit from Terraform's extensive module ecosystem -- Teams comfortable with HCL and template-based approaches - -When to Consider Alternatives: - -- Teams wanting comprehensive testing capabilities (unit, property, integration testing) -- Organizations requiring full IDE support with debugging and refactoring -- Projects needing complex programmatic logic or extensive code reuse -- Teams with strong programming backgrounds who prefer familiar languages - -Key Considerations: - -- **Licensing**: Terraform's Business Source License may create restrictions for some commercial scenarios -- **Ecosystem**: Terraform has the largest provider ecosystem and community resources -- **Learning investment**: Consider whether learning HCL aligns with your team's skill development goals -- **Migration options**: Tools exist for migrating between different IaC platforms when needs change - -The choice often depends on team background, infrastructure complexity, and development workflow preferences rather than one approach being universally superior. - -### How do I get started with infrastructure as code? - -Choose Based on Your Team Profile: - -1. **Programming-oriented teams**: Consider Pulumi IaC for familiar languages with full IDE support, testing frameworks, and multi-cloud flexibility -2. **Template-oriented teams**: OpenTofu or Terraform offer extensive community resources, established workflows, and broad ecosystem support -3. **Cloud-specific teams**: Native tools (AWS CDK/CloudFormation, Azure ARM/Bicep, Google Cloud Infrastructure Manager) provide deep platform integration -4. **Kubernetes-focused teams**: Consider Crossplane or Pulumi Kubernetes Operator for container-native approaches - -Getting Started Steps: - -1. **Start small**: Begin with simple projects like deploying a single application or basic infrastructure -2. **Use examples**: Leverage existing templates, tutorials, and community examples to accelerate learning -3. **Plan for growth**: Consider how your tool choice will scale with team size and infrastructure complexity -4. **Experiment**: Most tools offer free tiers or trials - try multiple approaches with simple projects to find what fits your team best - -### What's the difference between configuration management and infrastructure provisioning? - -- Infrastructure provisioning (Pulumi IaC, Terraform, CloudFormation) creates and manages cloud resources like VMs, networks, and databases -- Configuration management (Ansible, Chef, Puppet) configures and maintains software on existing systems -- Many modern tools do both, with Pulumi IaC and Ansible offering comprehensive capabilities across both domains - -### Can I use multiple IaC tools together? - -Absolutely! Many organizations use complementary tools for different aspects of infrastructure management: - -Pulumi + Configuration Management: +### Ansible -- Pulumi + Ansible: Infrastructure provisioning + server configuration ([example](/blog/deploy-wordpress-aws-pulumi-ansible/)) -- Pulumi + Chef/Puppet: [Cloud resources](/docs/get-started/) + complex configuration management +- License: GPL v3 (community); commercial Red Hat Ansible Automation Platform +- Languages: YAML (playbooks) +- Best for: agentless configuration of Linux/Windows fleets and ad-hoc automation over SSH/WinRM -Pulumi + Native Cloud Tools: +Ansible runs playbooks over SSH or WinRM with no agent on target machines. It has a large module library covering operating-system configuration, application deployment, and many cloud and network APIs. Ansible can call cloud APIs directly, but its sweet spot is configuring software on existing systems rather than full lifecycle management of cloud resources. Pulumi and Ansible compose well: provision with Pulumi, configure with Ansible (see [Deploy WordPress to AWS using Pulumi and Ansible](/blog/deploy-wordpress-aws-pulumi-ansible/)). -- Reference existing CloudFormation/ARM deployments from Pulumi programs -- Import CloudFormation/ARM resources into Pulumi for gradual migration -- Use Pulumi alongside CDK for different parts of AWS infrastructure +External resources: [ansible.com](https://www.ansible.com/). -Pulumi + Kubernetes: +### Chef -- [Pulumi Kubernetes Operator (PKO)](/docs/using-pulumi/continuous-delivery/pulumi-kubernetes-operator/) for GitOps workflows -- Pulumi + Crossplane for layered infrastructure management -- Pulumi + security scanners like Checkov or Terrascan for compliance +- License: Apache 2.0 (Chef Infra Client); commercial Progress Chef Enterprise Automation Stack +- Languages: Ruby (cookbooks and recipes) +- Best for: programmable, agent-based configuration management at scale -Terraform + Pulumi Coexistence: +Chef uses Ruby cookbooks executed by an agent on each node, with optional pull-based reconciliation against a Chef server. Its strengths are programmable logic in real Ruby, the Test Kitchen testing framework, and Chef InSpec for compliance. -- Use Terraform for base infrastructure and Pulumi for Internal Developer Platforms (IDPs) -- Reference existing Terraform state from Pulumi programs during gradual migration -- Manage different infrastructure layers with different tools based on team expertise +External resources: [chef.io](https://www.chef.io/). -Pulumi IaC is designed for heterogeneous environments where multiple tools may be in use. For example, you can manage existing Terraform or CloudFormation resources with Pulumi, either using both tools in tandem or for temporary management while migrating to native Pulumi IaC code. Other Pulumi tools, like Pulumi IDP, also enable you to manage IaC self-service workflows like other tools on this list. See what's possible when [migrating to Pulumi](/docs/iac/adopting-pulumi/migrating-to-pulumi/). +### Puppet -### Which tool has the best learning resources? +- License: Apache 2.0 (Open Source Puppet); commercial Puppet Enterprise +- Languages: Puppet DSL +- Best for: compliance-driven enterprises with large heterogeneous fleets -- Pulumi: Excellent documentation with examples in multiple languages, comprehensive tutorials -- Terraform/OpenTofu: Extensive community content, many courses and books available -- AWS CDK: Outstanding official documentation with workshops and examples -- Kubernetes: Vast ecosystem but steeper learning curve +Puppet uses a declarative DSL and a pull-based agent model. Its main differentiator is reporting, drift detection, and compliance dashboards in Puppet Enterprise — features that resonate in regulated environments. -### How important is open-source licensing for IaC tools? +External resources: [puppet.com](https://www.puppet.com/). -Very important for long-term strategy: +### Salt -- Apache 2.0 (Pulumi, CDK) offers maximum flexibility -- MPL 2.0 (OpenTofu) ensures open-source availability -- BSL (Terraform) restricts commercial competitors -- Proprietary (CloudFormation, ARM) ties you to specific vendors +- License: Apache 2.0 (open-source); commercial VMware Aria Automation Config (formerly SaltStack) +- Languages: YAML (states), Python (modules and reactors) +- Best for: high-throughput, event-driven automation across very large fleets -Choose open-source tools like Pulumi or OpenTofu to avoid vendor lock-in. +Salt's master/minion architecture and ZeroMQ messaging make it fast at issuing commands across large numbers of hosts, and its event/reactor system enables event-driven automation patterns. -### What about security and compliance? +External resources: [saltproject.io](https://saltproject.io/). -All major IaC tools support security best practices: +## Policy and security tools alongside IaC -- Built-in policy engines: Pulumi CrossGuard, AWS Config, Azure Policy -- Third-party scanners: Checkov, KICS, Terrascan work with all tools -- Compliance frameworks: Most tools support SOC 2, PCI DSS, CIS benchmarks -- Secret management: Integration with Vault, AWS Secrets Manager, Azure Key Vault +These tools do not provision infrastructure but layer onto whichever provisioning tool you use: -Pulumi offers the most comprehensive built-in security features with CrossGuard policy as code. +- **[Pulumi CrossGuard](/docs/insights/policy/)** — policy as code in TypeScript or Python, enforced at preview/update time on Pulumi programs. +- **[HashiCorp Sentinel](https://www.hashicorp.com/sentinel)** — policy as code for Terraform/HCP Terraform. +- **[Open Policy Agent (OPA) / Conftest](https://www.openpolicyagent.org/)** — Rego-based policy across Terraform, Kubernetes, and CI/CD pipelines. +- **[Checkov](https://www.checkov.io/)** — open-source static analysis for Terraform, OpenTofu, CloudFormation, Kubernetes, ARM/Bicep, and more, with thousands of built-in policies. +- **[TFLint](https://github.com/terraform-linters/tflint)** — pluggable linter for Terraform and OpenTofu with cloud-provider rule sets. +- **[Snyk IaC](https://snyk.io/product/infrastructure-as-code-security/) / [Wiz](https://www.wiz.io/)** — commercial security platforms that scan IaC and live cloud configurations. -### Can I migrate from one IaC tool to another? +## IaC automation and management platforms -Yes, and many organizations are successfully migrating to overcome limitations in their current tools. Migration tools and proven approaches exist: +These platforms run the provisioning tools above in CI/CD with collaboration, RBAC, drift detection, cost controls, and policy enforcement. They are not IaC tools themselves; they orchestrate the tools you already use. -Proven Migration Success Stories: +- **[Pulumi Cloud](/docs/iac/concepts/pulumi-cloud/)** — managed service for Pulumi state, secrets ([Pulumi ESC](/docs/esc/)), policy, deployments, and resource search ([Pulumi Insights](/docs/insights/)). +- **HCP Terraform / Terraform Enterprise** — HashiCorp's managed and self-hosted services for Terraform/OpenTofu workflows. +- **[Spacelift](https://spacelift.io/)** — multi-tool platform that orchestrates Terraform, OpenTofu, Pulumi, CloudFormation, Ansible, and Kubernetes. +- **[env0](https://www.env0.com/)** — automation and governance for Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes. +- **[Atlantis](https://www.runatlantis.io/)** — open-source GitOps-style PR automation for Terraform and OpenTofu. -- **Atlassian Bitbucket**: Completed migration from Terraform to Pulumi's Python-based IaC in just 2 days using migration tools -- **Starburst**: Achieved 112x faster deployments after incrementally migrating from Terraform -- **Multiple organizations**: Report 80-90% deployment time reductions after moving to programming language-based approaches +## Which IaC tool should I choose? -Available Migration Tools: +There is no universally best tool. The best tool is the one your team can write, review, and operate confidently. Use these criteria to narrow the field: -- **Pulumi**: Offers [`pulumi convert`](/docs/using-pulumi/adopting-pulumi/migrating-to-pulumi/#conversion) for importing from Terraform, ARM, and CloudFormation with state integration -- **Terraformer**: Can import existing cloud resources into Terraform/OpenTofu -- **CDK Migrate**: Helps move from CloudFormation to CDK -- **Manual migration**: Always possible by recreating resources in the new tool +1. **Where does your infrastructure run?** Single-cloud teams default to the native tool (CloudFormation/CDK, Bicep, Infrastructure Manager) for the deepest integration. Multi-cloud or hybrid teams end up with Pulumi, Terraform, or OpenTofu. +1. **What languages does your team know?** Pulumi, AWS CDK, and SST use general-purpose languages. Terraform, OpenTofu, Bicep, and CloudFormation use DSLs or templates. CDKTF used to bridge the two but is deprecated. +1. **What are your licensing constraints?** If "must be OSI-approved open source" is a hard requirement, Pulumi (Apache 2.0) and OpenTofu (MPL 2.0) qualify; current Terraform releases under BUSL 1.1 do not. +1. **How important is testing?** Real unit-test frameworks exist for Pulumi and AWS CDK. Terraform and OpenTofu support integration-style tests via the `terraform test` framework but are weaker on unit testing. +1. **Where does state live?** Pulumi, Terraform, and OpenTofu have explicit state stores you manage (or use a managed service for). CloudFormation, ARM/Bicep, Crossplane, and Infrastructure Manager keep state inside the cloud or Kubernetes API. +1. **Are you building a platform?** Platform/IDP teams pick the tool with the strongest abstraction story — Pulumi components, AWS CDK constructs, or Crossplane XRs — depending on whether the platform's audience is multi-cloud, AWS-only, or Kubernetes-first. -Migration Strategies: +A simple decision tree: -- **Incremental adoption**: Migrate team-by-team or project-by-project without disruption -- **State integration**: Reference existing infrastructure during transition periods -- **Zero downtime**: Tools like Pulumi enable seamless migration without service interruption +- AWS only, want a programming language → **AWS CDK** (or **Pulumi** if you might add other clouds later). +- AWS only, prefer templates → **CloudFormation**. +- Azure only → **Bicep** (and **ARM** for resources Bicep doesn't yet support). +- GCP only → **Google Cloud Infrastructure Manager**. +- Multi-cloud, prefer programming languages → **Pulumi**. +- Multi-cloud, prefer HCL, fine with BUSL → **Terraform**. +- Multi-cloud, prefer HCL, want OSS license → **OpenTofu**. +- Kubernetes is your control plane → **Crossplane** (often combined with Pulumi or Terraform to provision the cluster itself). +- Configuring software on existing servers → **Ansible** (or Chef/Puppet/Salt for specialized needs). -The key is choosing tools that provide comprehensive migration support and incremental adoption paths rather than requiring "rip and replace" approaches. +## Is Terraform or Pulumi better? -## Conclusion: The Evolution of Infrastructure as Code +It depends on team and constraints, but the practical differences in 2026 are: -The infrastructure as code landscape in 2025 reflects a maturing field where different approaches serve different organizational needs and team preferences. The evolution from manual processes to automated infrastructure has branched into multiple viable paths, each with distinct advantages. +- **Language.** Terraform uses HCL, a configuration language scoped to infrastructure. Pulumi uses general-purpose languages (TypeScript, Python, Go, C#, Java, plus YAML), which means real loops, conditionals, classes, packages, and unit tests, but also a steeper ramp for engineers without programming experience. +- **License.** Terraform is BUSL 1.1; Pulumi is Apache 2.0. If license matters to your organization, that is often the deciding factor — and OpenTofu is the third option. +- **Provider ecosystem.** Terraform has the largest community provider ecosystem. Pulumi ships [native providers built from cloud APIs](/blog/announcing-aws-native/) — same-day coverage of new AWS, Azure, and Google Cloud features — and supports Terraform-bridged providers for everything else. In practice, both cover the major clouds well. +- **State and secrets.** Pulumi has built-in encrypted secrets and a managed state service (Pulumi Cloud) by default; Terraform's equivalents (HCP Terraform, remote backends, Vault) are configured separately. +- **Testing and abstractions.** Pulumi has unit-test frameworks in TypeScript, Python, Go, and .NET, and reusable [components](/docs/iac/concepts/components/) consumable from any supported language. Terraform's testing story is integration-focused; modules are the reuse primitive. +- **Coexistence.** You don't have to choose only one. Pulumi can [reference Terraform state](/docs/iac/guides/migration/), import existing Terraform-managed resources, and run alongside Terraform — common during incremental migrations. -The Spectrum of Approaches: +For a longer side-by-side, see [Pulumi vs. Terraform](/docs/iac/comparisons/terraform/). -Template-based tools like Terraform and OpenTofu continue to serve teams effectively, particularly those comfortable with declarative configuration and established HCL workflows. Cloud-native solutions provide deep platform integration for single-cloud strategies. Programming language-based approaches offer familiar development experiences for teams seeking comprehensive testing, IDE integration, and code reusability. +## How do I migrate from one IaC tool to another? -Evidence of Success Across Approaches: +Migrations between IaC tools are usually incremental rather than rip-and-replace: -Organizations achieve significant improvements regardless of their chosen path—the key is selecting tools that align with team expertise and infrastructure requirements. Understanding [what DevOps is](/what-is/what-is-devops/) and [platform engineering concepts](/what-is/what-is-platform-engineering/) helps inform these decisions. Success stories span the entire ecosystem, from Terraform's widespread enterprise adoption to programming language approaches enabling dramatic productivity gains at companies like Unity, Snowflake, and Starburst. +1. **Inventory the existing estate** — what resources exist, which tool owns them, where state lives. +1. **Convert configurations** with automation where possible. [`pulumi convert`](/docs/iac/guides/migration/) translates Terraform HCL, ARM, CloudFormation, and Kubernetes YAML into Pulumi programs in any supported language. AWS provides CDK Migrate for CloudFormation → CDK. Terraformer imports live cloud resources into Terraform/OpenTofu. +1. **Adopt resources, don't recreate them.** Most provisioning tools support importing existing resources into state, so you can take ownership without destroying and recreating production infrastructure. +1. **Run two tools side-by-side** during the transition. Pulumi can reference Terraform state via the `terraform-state` reference; Crossplane can wrap resources provisioned by other tools. +1. **Move tests, policies, and CI last.** Once the new tool owns a service, port the policy-as-code rules and CI workflows that protected it. -Choosing Your Path: +For Pulumi-bound migrations, see [Migrating to Pulumi](/docs/iac/guides/migration/). -The most successful organizations focus on key decision criteria: +## What's next for IaC? -- **Team background**: Match tools to existing skills and preferred development approaches -- **Infrastructure complexity**: Consider testing, abstraction, and maintainability needs -- **Organizational constraints**: Factor in licensing, governance, and compliance requirements -- **Growth trajectory**: Plan for how needs may evolve with scale and team expansion -- **Integration requirements**: Ensure compatibility with existing workflows and toolchains +Three trends are shaping IaC tooling in 2026: -The Future of Infrastructure: +1. **Software engineering practices for infrastructure.** Unit tests, type checking, refactoring, and shared libraries are no longer aspirations — they are the table-stakes developer experience for IaC, and they favor tools built around general-purpose languages. +1. **Native, day-zero cloud coverage.** Teams expect new cloud services to be usable in IaC the day they are announced. Native providers generated from cloud APIs (Pulumi, Bicep, CloudFormation, ARM) outpace community-maintained ones. +1. **Platform engineering and IDPs.** Most large organizations are now building internal developer platforms that expose curated, policy-checked, self-service infrastructure. Whether the platform is built on Pulumi components, AWS CDK constructs, or Crossplane XRDs, the goal is the same: turn raw IaC into a paved road that application teams can use without becoming infrastructure experts. -The industry continues evolving toward treating infrastructure as software, but this transformation takes many forms. Organizations exploring [serverless architectures](/serverless/) and container strategies particularly benefit from programmable infrastructure approaches. Whether through enhanced DSLs, visual design tools, programming languages, or hybrid approaches, the goal remains consistent: enabling teams to manage infrastructure with the same reliability, collaboration, and velocity they expect from modern software development. +Whichever tool you choose, the underlying shift is durable: infrastructure is software, and the tools that treat it that way will keep winning. To try Pulumi, [get started](/docs/get-started/) in the language you already use. -For teams ready to embrace programming language-based infrastructure as code, [Get started with Pulumi](/docs/get-started/) to experience how familiar languages and software engineering practices can transform infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support. +