16 Most Useful Infrastructure as Code (IaC) Tools for 2026

Infrastructure as code (IaC) is how teams provision and manage IT resources today. You describe what you want in code, a tool reconciles your cloud or servers to match, and the same patterns that spin up a single dev environment can stand up a thousand production machines. Code reviews protect both, version control tracks every change, and a rollback is a git revert away.

The tools that make this possible have multiplied. In 2026, IaC covers everything from Terraform configurations and Pulumi programs to Kubernetes custom resources, cloud-vendor templates, and configuration management tools that were never designed to provision anything in the first place.

That makes “which IaC tool should I use” a harder question than it looks, because the right answer depends on whether you mean write, orchestrate, or converge. The 16 tools below are the ones worth knowing.

A decade ago, most infrastructure was managed by clicking through cloud consoles and SSHing into servers. By 2026, the same work happens through pull requests. The shift came down to a handful of operational changes that made infrastructure feel less like a craft and more like software.

• Drift stops being invisible – When the desired state lives in a Git repository and the actual state lives in a cloud, you can compare them. That’s the difference between finding out about a manual change during the next incident and catching it the morning after it was made.
• Environments stop being snowflakes – Staging, production, dev, and the disaster recovery region all come from the same module with different inputs. When something works in staging and breaks in production, “they’re configured differently” stops being a valid explanation.
• Infrastructure changes get reviewed like application changes – A misconfigured security group shows up as a pull request, gets a comment from the security engineer on the review, and gets fixed before it ships. Before IaC, the same change happened in a console and the security engineer found out about it during the postmortem.
• You stop being the only person who knows how the system was built – Every resource is declared in a file someone can grep. New hires can read the infrastructure the same way they read the application code.

When you might not need IaC tools: If you run one or two long-lived VMs on a single cloud, you have no plans to add more, and nobody else needs to reproduce your setup, IaC is overhead you don’t yet need. Click around in the console, document the setup in a wiki, and come back when the situation changes. For everyone else, we recommend checking out the tools below.

Here’s the list, grouped by what each tool is actually for.

Best IaC tools include:

1. OpenTofu
2. Terraform
3. Pulumi
4. AWS CDK
5. Spacelift
6. Terragrunt
7. AWS CloudFormation
8. Azure ARM
9. Google Infrastructure Manager (Infra Manager)
10. Kubernetes Operators
11. Crossplane
12. Ansible
13. Chef
14. Salt
15. Puppet
16. Vagrant

OpenTofu is the open-source fork of Terraform, maintained by the Linux Foundation and built by a vendor-neutral community. It was created in 2023 after HashiCorp relicensed Terraform from MPL 2.0 to the Business Source License, and forked from Terraform 1.6 to stay wire-compatible with existing Terraform providers and state files. Migration from Terraform to OpenTofu is typically a binary swap. 

Since the fork, OpenTofu has shipped features that diverge from Terraform, including state and plan encryption, early evaluation of variables in backend and module configuration, and provider iteration for declaring multiple instances of a provider with a single block.

Key features:

• Terraform-compatible: drop-in replacement for Terraform 1.6 and later, with the same HCL syntax and provider ecosystem.
• Built-in state and plan encryption: encrypts sensitive data at rest using configurable key providers, with rotation support.
• Early variable and locals evaluation: lets you use variables and locals inside the terraform block, backend configuration, and module sources, including encryption settings.
• Open-source governance: stewarded under a neutral Linux Foundation model, with the technical roadmap shaped by community RFCs.

License: MPL2.0 (open source)

Adoption signal:

• ~28.7k GitHub stars on opentofu/opentofu
• Four minor releases in the last 12 months (1.9, 1.10, 1.11, 1.12)

Code example:

Creates an S3 bucket with two tags. If you’ve written Terraform, this is exactly what you’d write. The language is identical, which is the whole point.

resource "aws_s3_bucket" "example" {
  bucket = "opentofubucket"

  tags = {
    Name        = "My OpenTofu Bucket"
    Environment = "dev"
  }
}

Terraform is the tool that established the IaC category. HashiCorp created it in 2014, and it now manages infrastructure across more than 4,000 providers using a single declarative language called HashiCorp Configuration Language (HCL). 

In August 2023, HashiCorp relicensed Terraform from MPL 2.0 to the Business Source License, which prompted the community fork that became OpenTofu. Terraform remains the most widely deployed IaC tool in production, with a deep provider ecosystem and a mature workflow built around plan, apply, and state.

Key features: 

• Declarative configuration: you describe the desired end state in HCL, and Terraform figures out the API calls to reach it.
• State tracking: a state file records what Terraform manages, so each run computes only the diff between desired and actual.
• Multicloud provider ecosystem: 4,000+ providers cover every major cloud and most SaaS platforms from the same workflow.
• Modules: reusable units of configuration that let you abstract patterns and share them across teams or via the public registry.

License: BSL

Terraform ratings and reviews:

• G2: 4.7/5 (96 reviews)

Code example:

A two-property EC2 instance, declared by end state. You describe what you want; Terraform figures out the API calls to get there.

resource "aws_instance" "example" {
  ami                 = "ami-id"
  instance_type       = "t2.micro"
}

If you are looking for HCP Terraform (formerly Terraform Cloud)Alternatives, we recommend reading the Terraform Cloud vs. Atlantis comparison blog post.

Pulumi lets you write infrastructure code in TypeScript, JavaScript, Python, Go, Java, C#, or YAML, using the same languages your applications are written in. Because configuration is real code, you get loops, conditionals, functions, classes, and unit tests for free, without inventing a templating layer on top of HCL. 

Pulumi reuses the same Terraform provider ecosystem under the hood, so coverage is comparable, and Pulumi Cloud provides a managed backend for state, secrets, and policy if you do not want to host it yourself.

Key features: 

• Real programming constructs: write infrastructure with the loops, functions, classes, and tests of your language of choice.
• Multicloud provider coverage: built on the Terraform provider ecosystem, so it manages resources across every major cloud and most SaaS platforms.
• Managed state and secrets: Pulumi Cloud stores state and encrypts secrets, or you can run your own backend on S3, GCS, or Azure Blob.
• Cross-language stack references: outputs from a Python stack can be consumed by a TypeScript stack and vice versa, so teams can mix languages without losing dependency wiring.

License: Apache 2.0 (open source)

Pulumi ratings and reviews:

• G2: 4.8/5 (25)

Code example:

The same S3 bucket as above, written in Python. The pulumi.export line makes the bucket name a stack output that other Pulumi programs or shell scripts can consume.

import pulumi
import pulumi_aws as aws

bucket = aws.s3.Bucket('my-bucket')
pulumi.export('bucket_name',  bucket.id)

More details about how Pulumi works are described in What is Pulumi? blog post. Check out also Pulumi vs. Terraform comparison.

AWS Cloud Development Kit (CDK) lets you define AWS infrastructure in TypeScript, JavaScript, Python, Java, C#, or Go. CDK code synthesizes to a CloudFormation template, which CloudFormation then deploys, so CDK is best understood as a higher-level authoring layer on top of CloudFormation rather than a separate deployment engine. 

The CDK ships with a Constructs library that bundles common patterns (a load-balanced ECS service, a CloudFront-fronted S3 bucket) into a single object, so common infrastructure ends up much shorter than the equivalent raw CloudFormation.

Key features:

• Real programming languages: TypeScript, JavaScript, Python, Java, C#, or Go, all first-class.
• First-party AWS service coverage: CDK targets the same CloudFormation resource types AWS itself maintains, so support tracks AWS service releases.
• Constructs library: high-level abstractions that compose common patterns (load-balanced services, three-tier networks) into a single object.
• CDK Pipelines: opinionated, self-mutating deployment pipelines defined in the same CDK code as the infrastructure they ship.

License: Open-source (Apache 2.0)

AWS Cloud Development Kit ratings and reviews:

• G2: 4.4/5 (125)

Code example:

Defines an S3 bucket using AWS CDK v2 in Python. The interesting part isn’t the code itself: it’s what happens next. cdk synth turns this Python into a CloudFormation template, and cdk deploy ships that template to AWS. CDK is a friendlier authoring layer on top of CloudFormation, not a separate deployment engine.

import aws_cdk as cdk
import aws_cdk.aws_s3 as s3

app = cdk.App()
stack = cdk.Stack(app, "my_stack")

s3.Bucket(stack, "testcdkbucketwest", versioned=True)

app.synth()

Read also: AWS CDK vs. Terraform

Spacelift is the infrastructure orchestration platform built for teams that do not live in a single IaC tool. It runs Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes workflows (including Crossplane) on one control plane, with shared policy, drift detection, and self-service across all of them.

Spacelift supports both production-grade IaC workflows and AI-assisted provisioning for non-critical workloads, so platform teams stop being the bottleneck between developers and infrastructure.

Key features:

• Multi-IaC workflows: orchestrate Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes from a single control plane.
• Stack dependencies: build nested dependencies between stacks so changes propagate in the right order and outputs flow between them automatically.
• Policy as code: write OPA-based policies that govern everything from approval requirements to which resources a run is allowed to create, applied consistently across every stack.
• Customizable workflows: run your own pre- and post-phase commands, bring your own container image, or override default workflow commands when you need to.
• Drift detection and remediation: detect when actual infrastructure no longer matches the code, and remediate automatically or on approval.

Spacelift ratings and reviews:

• G2: 4.9/5 (11 reviews)
• Spacelift is used by infrastructure teams at Airtime Rewards, Checkout.com, Figma, and others. The full customer list is at spacelift.io/customers.

Policy example:

A Spacelift approval policy, written in Rego. Attach it to your production stacks and any DESTROY run waits until your maintenance window is open. Approval policies gate runs at the decision point, so the rule fires every time without anyone wiring it in by hand.

package spacelift

reject {
    input.run.type == "DESTROY"
    input.stack.labels[_] == "env:prod"
    not is_maintenance_window
}

is_maintenance_window {
    # define your window logic here
    ...
}

Terragrunt is a thin wrapper around Terraform and OpenTofu that solves the problems you hit when running them at scale. It keeps configuration DRY across environments, manages remote state automatically, and orchestrates multi-module deployments through dependency graphs. Without it, every environment repeats the same backend block, provider configuration, and module wiring. With it, those live in one place and inherit downward. 

Terragrunt hit 1.0 on March 30, 2026, adding an explicit backwards-compatibility commitment and the Stacks feature for managing groups of related units as a single deployable unit.

Key features: 

• Wrapper for Terraform and OpenTofu: adds features on top of the underlying engine without changing how it runs.
• DRY configuration: define backend, provider, and inputs once at the root and inherit them across every environment.
• Automatic remote state management: creates and configures S3, GCS, or Azure backends for you, including locking.
• Dependency-aware multi-module runs: orchestrate plan and apply across dozens or hundreds of related modules, in dependency order.
• Stacks (1.0): group related units into a single deployable Stack with shared lifecycle commands.

License: MIT License (open source)

Adoption signal:

• ~9.5k GitHub stars on gruntwork-io/terragrunt
• Hit 1.0 on March 30, 2026

Code example:

A single terragrunt.hcl that points at a local module and configures S3 remote state with DynamoDB locking. Without Terragrunt, every environment would repeat the backend block; with it, the backend is defined once at the root and inherited everywhere.

terraform {
  source = "./"
}

inputs = {}

remote_state {
  backend = "s3"
  config = {
    bucket                 = "terragrunt-bucket-state"
    key                    = "config1/terraform.tfstate"
    region                 = "eu-west-1"
    encrypt                = true
    dynamodb_table         = "dynamodbtable"
    skip_bucket_versioning = true
  }
}

AWS CloudFormation is AWS’s first-party IaC service. You describe AWS resources in a YAML or JSON template, submit it to CloudFormation, and the service provisions, updates, or tears down the corresponding stack. 

Because CloudFormation is part of AWS itself, support for new services and properties typically lands at or near GA, and the service handles cross-resource dependencies and rollback on failure for you. Change Sets let you preview what an update will do before applying. StackSets extend the same workflow across multiple accounts and regions.

Key features: 

• First-party AWS integration: support for new AWS services and properties lands at or near GA.
• JSON or YAML templates: declarative configuration, with YAML the more readable of the two formats.
• Change Sets: preview the exact resource changes an update will produce before applying it.
• Stack management: groups resources into stacks for unified create, update, and delete operations, with automatic rollback on failure.
• StackSets: deploy the same template across multiple AWS accounts and regions from a single operation.

License: AWS proprietary

CloudFormation ratings and reviews:

• G2: 4.4/5 (207)

Code example:

A minimal CloudFormation template with one EC2 instance. YAML is the more readable of CloudFormation’s two formats – the same thing in JSON is roughly twice as long.

Resources:
  MyEC2Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      ImageId: "ami-0ff8a91507f77f867"

Azure Resource Manager (ARM) is Azure’s first-party deployment and management service. You submit a template describing the desired state of your Azure resources, and ARM provisions, updates, or deletes them to match. 

Templates can be authored in raw ARM JSON or in Bicep, a domain-specific language that Microsoft now positions as the recommended authoring experience. 

Bicep compiles to ARM JSON before deployment, so the underlying engine is identical; the difference is syntax. ARM is Azure-only and covers every resource type Azure exposes.

Key features: 

• Two authoring options: raw ARM JSON or Bicep, a cleaner DSL that transpiles to JSON. Both deploy through the same ARM engine.
• Role-based access control: ARM integrates with Azure RBAC, so deployment permissions follow your existing identity model.
• Conditional deployment: deploy resources only when conditions in the template are met, useful for environment-specific overrides.
• Deployment Stacks: manage the lifecycle of a group of resources together, replacing the older “complete” deployment mode that is being deprecated.

License: Microsoft proprietary

Azure Resource Manager ratings and reviews:

• G2: 4.2/5 (50)

Code example:

A storage account deployed into the eastus region. The apiVersion field pins the template to a specific Azure REST API version, which is one of the things ARM templates make you do explicitly and Bicep tries to hide.

{
  "$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": "examplestorage",
      "location": "eastus",
      "sku": { "name": "Standard_LRS" },
      "kind": "StorageV2"
    }
  ]
}

Google retired Cloud Deployment Manager (CDM) on March 31, 2026. The replacement is Infrastructure Manager (Infra Manager), Google Cloud’s managed service for running standard Terraform configurations against GCP. 

You write Terraform HCL exactly as you would anywhere else; Infra Manager handles execution, state, and credentials inside Google Cloud, integrated with IAM, Cloud Build, and Cloud Storage.

If you’re still on CDM, migration is no longer optional. If you’re starting fresh on GCP today, Infra Manager is the native path, although many teams skip it and run Terraform or OpenTofu directly to keep portability across providers.

Key features:

• Runs standard Terraform configurations as a managed service
• Integrates with Google Cloud IAM, Cloud Build, and Cloud Storage for state
• Supports private worker pools for network-isolated deployments

License: Google proprietary (managed service); underlying Terraform configs follow whichever license you use.

Code example:

A Compute Engine VM declared in Terraform HCL. Infrastructure Manager runs standard Terraform configurations as a managed Google Cloud service, so anything that works against the google Terraform provider works in Infra Manager.

resource "google_compute_instance" "vm" {
  name         = "my-vm"
  machine_type = "e2-medium"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
  }
}

Kubernetes Operators are application-specific controllers that extend the Kubernetes API with custom resources, then continuously reconcile those resources toward their declared state. 

Originally designed for managing complex stateful applications inside the cluster (databases, message queues, observability stacks), they are now also used to provision cloud infrastructure: AWS, Microsoft Azure, Google Cloud, and Oracle Cloud each ship their own Operators (AWS Controllers for Kubernetes, Azure Service Operator, Config Connector, OCI Service Operator) that let you manage cloud resources as Kubernetes objects.

Key features: 

• Extends Kubernetes API for specific applications
• Automates lifecycle management –  Manages complex stateful applications within Kubernetes
• Allows defining custom resources for Kubernetes
• Facilitates the development of new operators

License: AWS K8s Operators (Apache 2.0, open source)

Code example:

Provisions an AWS S3 bucket using the AWS Controllers for Kubernetes (ACK). The bucket is a Kubernetes object that you create, modify, and delete with kubectl, even though the actual resource lives in AWS.

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: bucket
spec:
  name: bucket
  tagging:
    tagSet:
    - key: name
      value: bucket

Crossplane is an open-source CNCF project that turns a Kubernetes cluster into a universal control plane for cloud infrastructure. You install Crossplane and a provider (AWS, Azure, GCP, etc.) into a cluster, and from then on you create, update, and delete cloud resources by applying YAML manifests with kubectl, the same way you manage in-cluster workloads. 

Compositions let platform teams build higher-level abstractions on top of the raw provider resources, so application teams can request a database or a service without writing provider-level YAML. Crossplane graduated within the CNCF on October 28, 2025.

License: Apache 2.0 (open source)

Key features: 

• It allows defining infrastructure directly from Kubernetes and supports multi-cloud deployments.
• Universal Control Plane – Turns Kubernetes cluster into a control plane for cloud services
• Kubernetes API extensions – Manages external resources via Kubernetes API

Adoption signal:

• ~11.7k GitHub stars on crossplane/crossplane
• CNCF status: Graduated late 2025

Code example:

Provisions an AWS VPC using the Upbound AWS provider for Crossplane. The forProvider block holds the AWS-specific arguments (CIDR block, region). The rest is standard Kubernetes object structure, which is the trick that lets one cluster manage resources across many clouds.

apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
  labels:
    name: vpc-example
  name: vpc-example
spec:
  forProvider:
    cidrBlock: 10.1.0.0/16
    region: eu-west-1
  providerConfigRef: 
    name: provider-aws-ec2

Ansible is an open-source IT automation engine designed for application deployment, configuration management, and orchestration. It runs over SSH (or WinRM on Windows) with no agent installed on managed nodes, and tasks are described in YAML playbooks that read close to plain English. 

Ansible started as a configuration tool, but Ansible collections now cover most major cloud providers, so the same playbooks that configure your operating system can also provision the VM it runs on.

Key features: 

• Agentless architecture: does not require agents on the target nodes
• Uses YAML to define automation tasks
• Modular design: supports reusable modules for various automation tasks

License: Apache 2.0 (open source)

Adoption signal:

• ~68.3k GitHub stars on ansible/ansible

Code example:

Ensures the latest version of the httpd package is installed on every host in the webservers inventory group. Ansible runs this over SSH, so the target machines need no agent installed. Re-running the playbook is safe; if httpd is already current, nothing happens.

- hosts: webservers
  tasks:
    - name: ensure apache is at the latest version
      yum:
        name: httpd
        state: latest

If you are interested in Ansible, here you will find useful Ansible content.

Chef is an automation platform for configuration management, originally released in 2009. You describe the desired state of a server in Ruby-based DSL recipes grouped into cookbooks, and the Chef client runs on each node and converges the system toward that state on every run. 

Chef is strongest in heterogeneous Linux and Windows fleets that need ongoing compliance enforcement, and its testing story (Test Kitchen for integration tests, InSpec for compliance assertions) is the deepest among the configuration management tools.

Key features: 

• It uses a Ruby-based DSL for writing system configurations
• Automates configuration management: manages and deploys server configurations
• Test-driven infrastructure: supports automated testing for infrastructure via ChefSpec and InSpec
• Policy as code: defines policies and configurations as code

License: Apache 2.0 (open source)

Adoption signal:

• ~7.7k GitHub stars on chef/chef

Code example:

A two-line Chef recipe that installs the ntp package. action :install is the desired state; the Chef client on each node decides what to actually run based on what’s currently installed.

package 'ntp' do
  action :install
end

Salt (originally SaltStack) is a Python-based open-source configuration management tool and remote execution engine. The original company was acquired by VMware in 2020, which Broadcom acquired in 2023 (Broadcom now sponsors the project). 

Salt’s distinguishing feature is its event-driven architecture and ZeroMQ-based transport, which lets it execute commands across thousands of nodes in seconds. The same CLI handles both declarative state enforcement (salt '*' state.apply) and imperative remote execution (salt '*' cmd.run 'uptime').

Key features: 

• Supports complex orchestration and configuration management across diverse environments
• Enables remote execution of commands and control
• Reacts to different system events for automation

License: Apache 2.0 (open source)

Adoption signal:

• ~15.4k GitHub stars on saltstack/salt

Code example:

A Salt state that installs the apache2 package on whatever nodes the state is applied to. Salt also supports imperative remote execution from the same CLI, which is what separates it from Puppet and Chef in practice.

install_apache:
  pkg.installed:
    - names:
      - apache2

Puppet is one of the older open-source configuration management tools, first released in 2005. It uses a declarative Ruby-based DSL (Puppet DSL) to describe the desired state of a system, and a Puppet agent runs on each managed node, pulling its configuration from a central Puppet server on a regular interval.

Puppet retains its strongest foothold in heavily regulated enterprise environments, where its compiler-and-catalog model and Puppet Enterprise’s reporting are well suited to compliance workflows.

Key features:

• It uses a Ruby DSL for writing system configurations
• Module ecosystem through Puppet Forge
• It’s idempotent – applying the same configuration multiple times will have the same effect as applying it once

License: Open-source (Apache 2.0) + Commercial version Puppet Enterprise

Adoption signal:

• ~7.8k GitHub stars on puppetlabs/puppet

Code example:

Declares that the apache2 package must be installed. The Puppet agent reapplies this on every run, so if someone manually removes apache2, the next run puts it back. That’s the idempotence guarantee in practice.

package { 'apache2':
 ensure => installed,
}

Read more: Puppet vs Ansible: Key Differences Explained

Vagrant is HashiCorp’s open-source tool for building and managing reproducible local development environments. You describe a VM (or a group of VMs) in a single Vagrantfile, and vagrant up boots an identical machine on any teammate’s laptop, regardless of host OS. 

Vagrant supports VirtualBox, VMware, Hyper-V, Docker, and several cloud providers as backends. It is a development tool, not a production deployment tool, and it remains the standard for sharing one-command dev environments across a team.

Key features:

• Works with VirtualBox, VMware, Docker, AWS, and other platforms
• Simple to use – you use only a vagrantfile for defining and configuring environments.
• A rich ecosystem of preconfigured boxes for different operating systems

License: Business Source License (BSL)

Vagrant ratings and reviews:

• G2: 4.6/5 (32)

Code example:

Defines a Vagrant environment that boots an Ubuntu VM and provisions apache2 with a shell command. A developer runs vagrant up and gets the exact same machine every teammate has.

Vagrant.configure("2") do |config|
 config.vm.box = "ubuntu/bionic64"
 config.vm.provision "shell", inline: "apt-get update && apt-get install -y apache2"
end

There is no single best IaC tool. There’s the right engine for what you’re writing, the right cloud service for where you’re deploying, and an orchestration layer that ties them together so a team can run them at scale without losing visibility.

The table below maps every tool in this article to four things you actually care about when picking one: what it’s for, where it can deploy, what you write configurations in, and how it’s licensed. Use it as the navigation layer.

#	Tool	Primary job	Cloud scope	Config language	License
1	OpenTofu	Provisioning	Any cloud + on-premises	HCL	MPL 2.0 (OSS)
2	Terraform	Provisioning	Any cloud + on-prem	HCL	BSL
3	Spacelift	Orchestration across engines	Any cloud + on-prem	None of its own; orchestrates Terraform, OpenTofu, Pulumi, CloudFormation, Ansible, K8s	Proprietary
4	Terragrunt	Orchestration wrapper for Terraform / OpenTofu	Same as engine	HCL	MIT (OSS)
5	Pulumi	Provisioning	Any cloud + on-prem	TypeScript, Python, Go, C#, Java, YAML	Apache 2.0 (OSS)
6	AWS CloudFormation	Provisioning	AWS only	YAML or JSON	AWS proprietary
7	Azure Resource Manager	Provisioning	Azure only	JSON or Bicep	Microsoft proprietary
8	Google Infrastructure Manager	Provisioning (managed Terraform)	GCP only	HCL	Google proprietary
9	Kubernetes Operators	Provisioning via Kubernetes	Any cloud (via K8s)	YAML (CRDs)	Apache 2.0 (most)
10	Crossplane	Provisioning via Kubernetes	Any cloud (via K8s)	YAML (CRDs)	Apache 2.0 (OSS)
11	Ansible	Configuration management + light provisioning	Any cloud + on-prem	YAML	GPL-3.0-or-later (OSS)
12	Chef	Configuration management	Any cloud + on-prem	Ruby DSL	Apache 2.0 (OSS)
13	Salt	Configuration management + remote execution	Any cloud + on-prem	YAML or Python	Apache 2.0 (OSS)
14	Puppet	Configuration management	Any cloud + on-prem	Puppet DSL	Apache 2.0 (OSS) + Puppet Enterprise
15	Vagrant	Local development environments (not production)	Local hypervisors and Docker	Ruby DSL	BSL
16	AWS CDK	Provisioning (synthesizes to CloudFormation)	AWS only	TypeScript, Python, Java, Go, C#	Apache 2.0 (OSS)

If you’re picking your first engine, OpenTofu or Terraform is the safe default. If you’re already running multiple engines across multiple teams, that’s where Spacelift sits: orchestration, policy, drift detection, and developer self-service across Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes, in one workflow.

Book a demo or start a free trial if you’d like to see how it fits.