Comparison

Cloudkeel-DD vs Spacelift

Spacelift orchestrates Terraform runs and can apply fixes. Cloudkeel-DD is read-only and self-hosted, and finds resources no state file declares. Every claim here is sourced from Spacelift's own docs.

Spacelift orchestrates Terraform runs. Cloudkeel-DD reads what your Terraform does not declare. Both do drift detection on resources you declared, and diverge on everything either side of it, so the comparison is only useful if it says which job you are actually hiring for.

Every claim about Spacelift below is from their own pricing page or documentation, linked at the bottom. Where they are ahead, it says so.

Start with the gap

A scheduled plan check catches fields that changed on resources you declared. Two things sit outside it entirely:

Where they differ

Ordered by the gap first, then by what each tool is allowed to do about it.

Cloudkeel-DDSpacelift
Unmanaged resource discoveryYes (AWS, Azure, GCP)Listed as “Unmanaged Resources (coming soon)”, Enterprise+
KubernetesLive cluster read: Helm, ArgoCD, Flux, sixteen kindsVia IaC orchestration, not a Kubernetes-native lens
Change attribution: who made itBest-effort, all three clouds, within a lookback windowNot mentioned in their drift documentation
Drift on managed resourcesYesYes, Starter and above (private workers only)
Cloud write accessNone (read-only, enforced in code)Applies runs
RemediationReviewed pull request, never an unattended writeApply
DeploymentSelf-hosted Helm chart, standaloneSaaS; self-hosted on Enterprise+ only
Entry priceNot set (pilot stage)Free tier; Starter and above from $20,000/yr

The difference that actually matters

Spacelift applies. We do not.

That is not a limitation we are apologising for. A tool that can apply needs credentials that can write to your cloud, and that is the thing a security review spends its time on. Cloudkeel-DD holds read-only credentials, in your own cluster, and the read-only guarantee is enforced in code rather than promised in a policy document: "apply" sits in a denied-prefix list, checked both at runtime and by a static gate.

The cost is real: we cannot fix anything for you. Remediation ships as a pull request against your repository, which your engineers review and merge on your schedule. If you want drift corrected automatically, Spacelift does that and we never will.

Where Spacelift is ahead

Said plainly, because a comparison that only lists our wins is an advert.

What we do not do

The limits, in the same breath as the claims:

Which one to pick

Choose Spacelift if you want your Terraform runs orchestrated and gated in one place, and you are comfortable with a platform that holds apply-capable credentials.

Choose Cloudkeel-DD if you need to know what your cloud is actually running (including the parts Terraform never declared) without granting write access to anything, and you would rather run it yourself than send your estate to a vendor.

They are not mutually exclusive. Nothing about running Spacelift stops you reading your own estate.

What about the clouds’ own tools?

Azure Policy, AWS Config and GCP Asset Inventory each answer part of this: inside their own cloud, in their own query language, without reference to your Terraform. If your estate is one cloud, evaluate them first; they are already paid for. If it spans clouds, the check becomes three different checks, and none of them can say “this resource is in no Terraform state”, because that comparison needs your state, which is the input they do not take.

Read more

Sources

Read 2026-07-31; re-read for change attribution 2026-08-15. If any of this has changed, tell us and we will correct it: a comparison that goes stale is worse than none.