The comparison usually arrives as a feature matrix, which is why it rarely settles anything. Every tool in this category runs terraform plan when a pull request opens and terraform apply when it merges. That is the product. The matrix compares the trim around it.
Three things genuinely differ, and none of them are a row you can tick: where your cloud credentials end up, what a policy is allowed to stop, and how the bill grows.
What do all of them actually do?
The same four things.
They watch a repository. They run a plan when a pull request opens and post the diff as a comment. They hold state and lock it so two runs cannot fight. They run an apply once somebody approves.
Atlantis, Digger, HCP Terraform, Spacelift, env0 and Scalr all do this. If your requirement genuinely stops there, Atlantis has done it since 2017 and costs nothing beyond the machine it runs on.
Everything past that point is about who operates the thing, and what it is allowed to refuse.
Where do your cloud credentials end up?
This is the first fork, and for a regulated team it is usually the only one that decides anything.
You host it. Atlantis is a server you run. Credentials never leave your network. You also own its uptime, its upgrades, its webhook secrets, and the uncomfortable fact that you now operate a machine holding apply rights to production. That server is production infrastructure, and teams routinely fail to treat it that way.
They host it. The control plane runs in the vendor's account. You either hand over credentials or, much better, wire up OIDC so they exchange a signed token for a short-lived role session instead of holding a static key.
OIDC changes this conversation more than the hosting model does. A vendor holding a long-lived AWS access key is a different risk from a vendor exchanging a token for a fifteen-minute session your account issued. Ask about that before you ask about anything else, and ask what happens to the plan output, which contains a readable description of your infrastructure whether or not it contains secrets.
There is a middle position worth knowing about. Private or self-hosted runners keep the orchestration hosted while execution happens on your compute, inside your network. Spacelift, env0, Scalr and the paid tiers of HCP Terraform all offer some version of it. It is usually the right answer for a team that wants neither a server to babysit nor credentials in someone else's account.
What sits between plan and apply?
Atlantis answers this with a comment. Somebody types atlantis apply and it applies. Who is allowed to do that comes down to your VCS permissions and Atlantis's own configuration, which is workable and is also the whole model.
The hosted platforms add policy as code. Spacelift and env0 use OPA. HCP Terraform uses Sentinel on paid tiers. Atlantis has no policy engine of its own; the usual answer is conftest in a pre-workflow hook, which works and which you now maintain.
The question worth asking in a demo is narrower than "do you support policy". It is what can a policy stop, and at what point?
A policy that runs before the plan can reject a repository or a variable. A policy that runs against the plan output can reject a specific change: a security group opening to the world, a database being replaced rather than updated, an IAM policy gaining a wildcard. The second kind is what catches real incidents, and it needs the plan JSON rather than the HCL.
What happens to a destructive plan?
Every one of these will show you a plan. Almost none of them will stop on a delete unless you tell them to.
The machine-readable form is the same everywhere:
terraform show -json tfplan > plan.json
{
"resource_changes": [
{
"address": "aws_db_instance.main",
"change": { "actions": ["delete", "create"] }
}
]
}
Any actions array containing delete is destructive. The one people miss is the replace, which arrives as ["delete", "create"] and reads as a create if you only look at the last element. A replaced RDS instance is a restore from snapshot, not an update.
Whether a platform surfaces that as its own state that blocks, or as another green check with the detail three clicks away, is a real difference between products that demo identically. Ask to see it on a replace, not on a create.
How does the bill grow?
Three shapes, and they fail in different directions.
Per seat. Predictable, and it quietly discourages giving read access to the people who should have it. If your reviewers cannot see a plan without a licence, they will approve without reading it.
Per run, or per runner minute. Tracks actual usage, which is fair, and it taxes frequent plans. Frequent plans are the habit you are trying to build.
Per resource under management. Tracks the size of your infrastructure rather than your use of the tool. The bill grows when you grow, whether or not you ran anything.
The third is the one that surprises people, and HCP Terraform moved to it. Before you price any of these, count what you actually have:
terraform state list | wc -l
Run it across every workspace and add it up. The number is almost always higher than the guess, because modules create resources nobody counts by hand.
Does it run OpenTofu?
Terraform's licence changed in 2023 and OpenTofu is the fork that stayed open source under the Linux Foundation. Whether that matters to you is a procurement and policy question rather than a technical one, but it constrains the shortlist either way.
HCP Terraform runs Terraform. Spacelift, env0, Scalr and Digger will run OpenTofu as well.
If you have not made that decision yet, picking a platform that only runs one of them makes it for you.
How do you decide?
Five questions, in order.
- Do credentials have to stay inside your network? If yes, you are choosing between self-hosting and a vendor with private workers plus OIDC. That eliminates most of the list before you look at features.
- Do you need to refuse a change based on what the plan contains? If yes, you need policy evaluated against plan output. Plain Atlantis does not do this without work you own.
- How many resources are under management? Count them. This decides whether per-resource pricing is a rounding error or the largest line on the invoice.
- Can your VCS permissions alone express who may apply to production? If not, you need a platform with its own access model rather than one that borrows GitHub's.
- Do you have someone to operate a server that holds production apply rights? If not, do not self-host Atlantis. Not because it is bad, but because an unpatched box with admin credentials is worse than a subscription.
If the first four do not decide it and you have the platform capacity for the fifth, take Atlantis. It is free, it has been doing this for years, and the pattern it invented is the one the paid tools copied.
The short version
They all run plan on a pull request and apply on merge. Choose on where credentials live, on what a policy is allowed to stop, and on how the bill grows, in that order.
The middle one is the one that gets skipped, and it is the one you will care about at two in the morning. A tool that shows you a destructive plan and a tool that refuses to apply one are different products, and in a demo they look the same.
DevLift generates Terraform and Terragrunt, runs the plan in CI, and holds the change at a human gate when the plan contains a delete. Book a walkthrough, or read how to catch a destructive plan.