13 Infrastructure as Code Tools That Can Improve Your Workflow

Once you've become familiar with infrastructure as code (IaC), the next challenge is often knowing which tools fit your situation: a first provisioning tool spanning multiple cloud providers, configuration management on top, a single cloud vendor's native tooling, or a security gap before an audit finds it first.

This article sorts thirteen of them into four buckets, with a verified comparison table and each category in detail underneath.

What are infrastructure as code tools?

Infrastructure as code tools define infrastructure resources – servers, networks, load balancers, virtual machines, and databases – in configuration files instead of manual configuration through a console. The file becomes the source of truth, version control systems track every change to it, and the same configuration reproduces identical environments on demand instead of system administrators repeating manual processes with the hope that nothing drifts.

Here are the four most common implementations:

1. Provisioning tools handle infrastructure provisioning from nothing, across one or many major cloud providers.
2. Cloud-native tools do the same but only for the vendor that built them, making them useful for teams standardized on a single platform rather than multi-cloud setups.
3. Configuration management tools take over once a machine already exists, managing operating systems and application code alike.
4. Scanning tools sit across all three, catching security vulnerabilities a plan and apply cycle never will.

Comparing infrastructure as code tools

Stars are from each project's GitHub repository, while vendor-native platforms with no public core repository are marked "N/A (closed source)."

Tool	Category	1-sentence description	GitHub stars
Terraform	Provisioning and orchestration	Declarative, provider-agnostic tool with the largest module and provider ecosystem in the category.	49,557
OpenTofu	Provisioning and orchestration	Apache-2.0, Linux Foundation-governed fork of Terraform, compatible with existing configurations.	29,955
Pulumi	Provisioning and orchestration	Defines infrastructure in general-purpose programming languages instead of a config language.	25,621
Stategraph	Provisioning and orchestration	Replaces Terraform/OpenTofu's flat state file with a graph so plans scope to the affected subgraph.	1,269
AWS CloudFormation	Cloud-native and vendor-specific	Native AWS provisioning via JSON/YAML templates and stacks, no third-party dependency.	N/A (closed source)
AWS CDK	Cloud-native and vendor-specific	Compiles TypeScript, Python, Java, or C# into CloudFormation templates.	12,874
Azure Resource Manager	Cloud-native and vendor-specific	Azure's native deployment layer, authored via JSON or the open-source Bicep DSL.	N/A (closed source; Bicep: 3,635)
Ansible	Configuration management	Agentless configuration management over SSH/WinRM using YAML playbooks.	70,487
Chef	Configuration management	Ruby-based configuration management with strong compliance tooling via InSpec.	8,231
Puppet	Configuration management	Declarative, agent-based configuration management for large, heterogeneous fleets.	7,923
SaltStack	Configuration management	Agent-based or agentless remote execution built for speed at high host counts.	15,636
Checkov	IaC scanning and security	Open-source static analysis across Terraform, CloudFormation, Kubernetes, and more.	8,975
tfsec	IaC scanning and security	Terraform-focused scanner, now folded into Trivy per its own repository.	7,035 (now part of Trivy, 37,672)

Provisioning and orchestration tools for infrastructure as code

General-purpose engines provision infrastructure across any provider for large-scale deployments and hybrid environments alike, spanning both declarative and imperative approaches, not one vendor's console rebuilt as YAML.

Terraform

Best for: Teams that want the most widely adopted, provider-agnostic tool with the deepest module and provider ecosystem.

Terraform defines infrastructure in HashiCorp Configuration Language (HCL) and runs it through plan and apply: plan shows what will change, apply makes it happen, and state tracks what's already there.

That state file, and its lock, is what other tools in this list work around or replace. Terraform's real advantage is the ecosystem, with coverage for nearly every cloud service worth automating.

Features

• Provider registry breadth covering essentially every major cloud and dozens of smaller providers.
• for_each and count for generating similar resources without copy-pasting configuration.

Pros and cons

Pros	Cons
Largest provider and module ecosystem in the category	Business Source License restricts certain commercial uses
Mature tooling, documentation, and community support	State file and its global lock create coordination overhead at scale

OpenTofu

Best for: Teams that want Terraform's exact workflow without HashiCorp's Business Source License terms.

OpenTofu is a fork of Terraform, governed by the Linux Foundation under Apache 2.0. It was created following the 2023 licensing change, and existing Terraform configurations carry over with little rewriting.

It hasn't stood still since forking: native state encryption landed ahead of Terraform's own CLI, and a public RFC process governs new language features in the open.

Features

• Native state encryption at rest, independent of the backend.
• Early variable and locals evaluation in module sources and backend configuration, shipped in OpenTofu 1.8 well before equivalent flexibility in Terraform's own CLI.

Pros and cons

Pros	Cons
Apache 2.0 license, no Business Source License restrictions	Shorter independent track record than Terraform
Community governance instead of one vendor's roadmap	Shares Terraform's provider ecosystem rather than growing a separate one

Pulumi

Best for: Teams that want infrastructure defined in a general-purpose programming language instead of a config language.

Pulumi compiles real program logic – TypeScript, Python, Go, C#, or Java – into a resource graph rather than requiring a purpose-built language.

For developers fluent in one of those, that means unit-testing infrastructure code with the same tools used for application code. Pulumi ESC (Environments, Secrets, and Configuration) centralizes config and secrets across stacks instead of scattering them per project.

Features

• Pulumi ESC for centralized environment, secrets, and configuration management across stacks.
• Genuinely unit-testable infrastructure code, using the host language's own test frameworks.

Pros and cons

Pros	Cons
No new domain-specific language for developers already writing the target language	Smaller ecosystem than Terraform's
Real conditionals and functions instead of HCL's more limited expressions	Real learning curve for engineers whose background is HCL, not code

Stategraph

Best for: Enterprise teams that are already running Terraform or OpenTofu where the flat state file and its whole-state lock has become a bottleneck, not the provisioning language itself.

Stategraph is a state management and execution system sitting underneath the Terraform or OpenTofu you already write. Instead of a JSON blob read, locked, and rewritten in full on every operation, it stores state as a queryable graph on a server, so state itself starts behaving like a database: resource-level locking replaces one workspace-wide lock, and a plan scopes to the subgraph a change touches.

It's not a drop-in replacement for Terraform's file-based model, instead driving Terraform or OpenTofu underneath rather than replacing the language.

Features

• SQL queries over your entire estate of infrastructure resources and cloud resources, not a grep across scattered .tfstate files.
• Blast radius analysis showing what a change reaches before it ships.
• Non-destructive state import, exportable back to plain .tfstate anytime.
• Self-hosted and BYOC deployment for teams whose state can't leave the network.

Pros and cons

Pros	Cons
Solves lock contention and full-state plan time at the source	Not a drop-in migration; some HCL patterns need adjustment
Resource-level locking replaces a single global workspace lock	A smaller ecosystem than Terraform
SQL queries and blast radius address what a flat state file can't
Free tier covers state storage and insights before any commitment

Cloud-native and vendor-specific infrastructure as code tools

These four trade portability for depth: each is built by one of the major cloud providers for that vendor's own cloud services and infrastructure resources, meaning same-day support for new resources but no path to a second cloud.

AWS CloudFormation

Best for: Teams fully committed to AWS that want a native tool with zero third-party dependency.

CloudFormation defines AWS resources in JSON or YAML templates organized into stacks that AWS tracks and rolls back. A change set previews what a template update will do, similar to a Terraform plan but scoped entirely to AWS.

New AWS features typically get CloudFormation support the same day they launch, something no third-party tool can promise, at the cost of AWS-only scope.

Features

• StackSets for deploying one template across many AWS accounts and regions at once.
• Built-in drift detection directly in the console.

Pros and cons

Pros	Cons
No third-party dependency; runs inside AWS's own control plane	AWS-only, with no path to a second cloud provider
New AWS service support typically arrives on day one	JSON/YAML templates are considerably more verbose than HCL

AWS CDK

Best for: AWS-committed teams that want CloudFormation's guarantees authored in a real programming language.

The AWS Cloud Development Kit compiles TypeScript, Python, Java, or C# into CloudFormation templates, a layer on top of CloudFormation rather than a competing engine.

"Constructs" are reusable classes representing one resource or a whole pattern, and cdk diff shows what a deployment will change, similar in spirit to a Terraform plan but with real language tooling: type checking, autocomplete, and unit tests.

Features

• Construct libraries for sharing reusable patterns as versioned packages.
• cdk diff for reviewing generated template changes before deploying.

Pros and cons

Pros	Cons
Real language abstractions on top of CloudFormation's guarantees	Still fundamentally AWS-only, as output is a CloudFormation template
Type checking and IDE tooling catch mistakes before deployment	An extra compile step sits between code and the deployed template

Azure Resource Manager

Best for: Teams standardized on Azure that want native lifecycle management with role-based access control built into the platform.

Azure Resource Manager (ARM) is Azure's underlying deployment layer; every Azure resource is an ARM resource underneath.

Raw ARM JSON is verbose even by CloudFormation's standards, but Bicep sits on top as a genuinely open-source DSL compiling to that JSON. ARM is Azure's closed control plane; Bicep, the layer most teams write in today, is open source.

ARM's strength is governance: what-if previews and management groups applying policy across subscriptions.

Features

• What-if deployment previews, evaluated natively against Azure's control plane.
• Management groups for governance across many subscriptions at once.

Pros and cons

Pros	Cons
Deepest native RBAC and governance integration in this category	Azure-only, the same multi-cloud limitation as CloudFormation
Bicep closes the syntax gap with HCL	Raw ARM JSON remains painful to author and read by hand

Configuration management tools

Configuration management tools take over once a machine already exists: installing packages, managing operating systems and users, and catching configuration drift between what's declared and what's running.

They are distinct from the automation tools above that provision infrastructure in the first place; most real deployments in production environments use one tool from each category.

Ansible

Best for: Teams that want agentless configuration management over SSH/WinRM with the lowest overhead to get started.

Ansible defines configuration in YAML "playbooks," executed against an inventory of hosts without a persistent agent; it connects over SSH, runs its modules, and disconnects.

Modules are intentionally idempotent, so running a playbook twice produces the same end state, the same guarantee Terraform's plan gives for provisioning. With no agent to install, Ansible is typically the fastest configuration management tool to adopt.

Features

• Ansible Galaxy for sharing community and internal roles instead of writing from scratch.
• Ansible Vault for encrypting secrets directly inside playbooks.

Pros and cons

Pros	Cons
No agent to install, patch, or monitor across the fleet	SSH execution is slower at very large host counts than a persistent agent
Extremely low barrier to first automation	YAML playbooks can sprawl into logic harder to read than a purpose-built language

Chef

Best for: Teams that want a mature, Ruby-based configuration management system with strong compliance tooling.

Chef organizes configuration into "cookbooks" containing Ruby "recipes," applied through a client-server model where agents on each node pull and apply the source of truth on a schedule.

Chef InSpec extends that approach to compliance auditing, producing evidence rather than a checklist. Progress Software, Chef's owner since 2023, keeps Chef Infra Client, InSpec, and Habitat open source under Apache 2.0, with commercial support sold separately.

Features

• Chef Habitat for packaging applications independently of the underlying OS.
• Test Kitchen for validating cookbooks against multiple platforms before production.

Pros and cons

Pros	Cons
Strong, mature compliance-as-code story via InSpec	Ruby-based recipes are a steeper curve than Ansible's YAML
Client-server model gives centralized fleet visibility	Requires running Chef server infrastructure, unlike Ansible

Puppet

Best for: Large, heterogeneous fleets that need a declarative, agent-based model with mature reporting.

Puppet describes desired state in its own DSL, compiled server-side into a "catalog" that each agent applies locally, checking in on a schedule to correct drift.

That enforced convergence is Puppet's defining trait when compared to tools that only act when triggered. Perforce, which acquired Puppet in 2022, develops it alongside PuppetDB, a centralized store making "which hosts run this version?" a query instead of a fleet-wide scan.

Features

• PuppetDB for centralized, queryable facts and reports across every node.
• Puppet Bolt for agentless, one-off tasks alongside the agent-based core.

Pros and cons

Pros	Cons
Scheduled, automatic drift correction without manual triggers	Running both an agent and server tier is real operational overhead
PuppetDB makes fleet-wide state genuinely queryable	Puppet's own DSL is a separate thing to learn

SaltStack

Best for: Teams that are looking for the fastest remote execution model across large fleets, agent-based or agentless.

Salt centers on publish/subscribe over ZeroMQ: a master pushes commands to "minions" nearly instantly rather than each node polling, making execution faster than SSH-based tools at high host counts.

Configuration runs through "states" and "pillars" (host-specific data), similar in shape to Puppet's catalog but over Salt's own transport. VMware acquired SaltStack in 2020 and then was acquired by Broadcom in 2023; Broadcom still supports Salt, though feature cadence has slowed.

Features

• Event-driven reactors, triggering automated responses the moment a defined event fires.
• Salt SSH for agentless execution where installing a minion isn't an option.

Pros and cons

Pros	Cons
Fastest command-and-control execution of the tools here	Smaller community and slower feature cadence since the ownership changes
Works agent-based or agentless depending on the host	ZeroMQ-based architecture is a different operational model to learn

The best infrastructure as code scanning tools

Provisioning and configuration management tools apply exactly what you tell them to, including a public S3 bucket or a security group with a wildcard rule, identifying security vulnerabilities that can sit in infrastructure configurations for months. Essentially, scanning tools catch mistakes before a plan or apply.

Checkov

Best for: Teams looking for the broadest policy coverage across the widest range of IaC formats in one open-source scanner.

Checkov runs static analysis against Terraform, CloudFormation, Kubernetes manifests, Bicep, and other formats through one Python-based policy engine, backed by over 1,000 built-in policies across every major provider. A team can run one scanner across formats instead of one per tool.

Due to its graph-based checks, rather than evaluating resources in isolation, Checkov reasons about relationships between them, catching a security group that's locked down but exposed through the load balancer it's attached to.

Features

• Custom policies authored in Python or YAML for organization-specific rules.
• Graph-based checks that reason about relationships between resources.

Pros and cons

Pros	Cons
Broadest multi-format coverage of the scanning tools here	Can be genuinely noisy out of the box until tuned
Over 1,000 built-in policies across every major provider	Graph-based checks add scan time on very large configurations

tfsec (now part of Trivy)

Best for: Teams that need fast, Terraform-specific static analysis, with the caveat that tfsec no longer exists as an independent project.

tfsec's original pitch was speed and focus: a lightweight, Terraform-only scanner running quickly in CI without a broader tool's scope.

That project has since folded into Trivy. Trivy, from the same maintainer, covers container, filesystem, and IaC scanning in one consolidated tool, and new adoption should target it directly.

Features

• Unified scanning across containers, filesystems, and IaC in one tool instead of several.
• Inline suppression comments in HCL, a convention carried over from tfsec.

Pros and cons

Pros	Cons
Consolidation into Trivy means one actively maintained tool	Teams with tfsec-specific CI config must migrate for updates
Trivy's broader scope covers issues Terraform-only scanning missed	The tfsec name still works today but isn't where new checks land

Conclusion

Thirteen tools, four real jobs.

1. Terraform, OpenTofu, Pulumi, and Stategraph provision infrastructure and its execution model: ecosystem maturity, license freedom, a general-purpose language, or fixing the state file underneath the rest.
2. CloudFormation, AWS CDK, and Azure Resource Manager trade portability for native depth on one cloud.
3. Ansible, Chef, Puppet, and SaltStack manage a machine after it exists.
4. Checkov and tfsec (now part of Trivy) catch mistakes in what the rest apply, provided you pick one still maintained.

Star counts are worth verifying, and maintenance status (archived, folded elsewhere, or past end-of-support) is as important as key features.

If your bottleneck is the flat state file underneath a Terraform or OpenTofu setup you're otherwise happy with, that's the one problem this list doesn't solve. Try Stategraph free to see what scoping a plan to the affected subgraph changes on a large, busy estate.

Infrastructure as code tools FAQs

What tools are used for infrastructure as code?

There are provisioning tools like Terraform, OpenTofu, and Pulumi that create infrastructure across clouds, cloud-native tools like AWS CloudFormation built by a single vendor for its own resources, configuration management tools like Ansible and Puppet that manage machines that already exist, and scanning tools like Checkov that check configuration for security mistakes before it ships.

Is Terraform the same thing as infrastructure as code?

No. Terraform is one implementation of infrastructure as code, not a synonym for the category. AWS CloudFormation, Pulumi, and Ansible are all also infrastructure as code, just with different scopes, languages, and execution models; Terraform is simply the most widely adopted example.

Do I need a separate scanning tool if I already use Terraform?

Yes, if catching misconfigurations before they ship is a priority. Terraform's plan and apply cycle checks that a configuration is valid and produces the resources described, but it doesn't check whether a security group is too permissive or a bucket is public. That distinct job is what scanning tools like Checkov or Trivy do, typically run in CI before a merge.