driftctl is the tool most people mean when they say “just use a CLI for drift.” It’s free, it’s open source, and for years it was the default answer. It is also, by its own maintainers’ words, no longer being actively developed. This page is for teams who used driftctl, still like what it does, and are looking at what replaces it.
Every claim about driftctl below is sourced from its own GitHub repository and README, linked at the bottom.
Start with its own words
driftctl’s README carries this banner, verbatim, at the top of the file:
This project is now in maintenance mode. We cannot promise to review contributions. Please feel free to fork the project to apply any changes you might want to make.
That is maintenance mode, not deprecated or archived. The repository is live (last pushed 2026-08-27), the license is Apache-2.0, and it still works today. But “we cannot promise to review contributions” is a maintainer telling you, plainly, not to expect new features.
What driftctl actually does
Its own README describes it in one line: a free and open-source CLI that scans a cloud provider, maps resources against your Terraform code, and warns about drift and unwanted unmanaged resources. Four features, by its own list: scan, analyze diffs and warn, ignore resources you don’t want flagged, and multiple output formats.
That is a real, useful tool for what it does. It is also the whole tool: a CLI you run, that produces a report. There is no server, no UI, no scheduler, and no persistence between runs.
Where the gap is
- Continuous vs. one-shot. driftctl scans when you run it. Cloudkeel-DD scans on a schedule you set, and keeps a history: drift is a row in a database, not a paragraph in a terminal that scrolls away.
- No Kubernetes at all. driftctl’s own README lists its cloud providers as Terraform against AWS, Azure, GCP and GitHub. Kubernetes and Helm are not mentioned anywhere in its docs. Cloudkeel-DD reads the live cluster: Helm, ArgoCD and Flux, sixteen kinds, including unmanaged workload detection.
- No severity, no suppression, no ownership. driftctl’s own feature list stops at “ignore resources.” There is no severity model, no reason-and-expiry suppression, and nothing that attributes a change to a person. A CLI report has no persistent state to attach any of that to.
- No policy layer. driftctl warns about drift and unmanaged resources; it
does not evaluate a resource against a rule like “no ingress open to
0.0.0.0/0.” That check does not exist in its feature list.
Where that leaves you
| Cloudkeel-DD | driftctl | |
|---|---|---|
| Entry price | Not set (pilot stage) | Free, open source (Apache-2.0) |
| Deployment | Self-hosted Helm chart, standalone, runs continuously | CLI binary, runs anywhere, one-shot per invocation |
| Unmanaged resource discovery | Yes: AWS, Azure, GCP | Yes: its original purpose |
| Kubernetes | Live cluster read: Helm, ArgoCD, Flux, sixteen kinds | Not supported: AWS, Azure, GCP, GitHub only |
| Change attribution (who made it) | Best-effort, all three clouds’ native audit logs, within a lookback window | Not documented; a CLI report has no concept of history to attach it to |
| Severity / suppression | Per-type, per-environment severity; suppression needs a reason and expires | “Ignore” a resource, no severity model, no expiry |
| Policy checks (open ingress, root containers, etc.) | Yes, on every scan | Not part of the tool |
| Scan cadence | Scheduled, continuous | Manual, or whatever you wrap it in yourself |
| Cloud write access | None: read-only, enforced in code | None: read-only CLI |
| Project status | Pre-1.0, pilot | Maintenance mode |
The difference that actually matters
driftctl tells you drift happened the moment you ask. Cloudkeel-DD is already watching.
A CLI is exactly right for a one-time audit or a CI step you already own. It is the wrong shape for “did anything change since Tuesday,” because nothing persists between runs to answer that question. Maintenance mode makes this sharper: the gaps above (Kubernetes, severity, policy, attribution) are not on a roadmap anymore.
Where driftctl is ahead
Said plainly, because a comparison that only lists our wins is an advert.
- It is free and open source today, with no pricing page to read and no vendor to trust with anything. Cloudkeel-DD’s pricing is not set yet.
- It needs nothing installed in your infrastructure. A CLI binary you run once has a smaller footprint than a Helm chart running continuously in your cluster, if a continuous view isn’t what you’re after.
- It already has 2,600+ GitHub stars and years of production use, even in maintenance mode. Cloudkeel-DD is pre-1.0, pilot stage.
- Multi-cloud from day one, without a “path-dependent” caveat: driftctl’s own docs cover AWS, Azure, GCP and GitHub uniformly, because it’s a single scan-and-diff mechanism rather than a system with per-cloud spec depth.
What we do not do
The limits, in the same breath as the claims:
- Unmanaged detection needs a Terraform state source. Something has to define “managed.” A cloud credential on its own produces nothing.
- Attribution is best-effort and can fail quietly. If the IAM permission it needs is missing, the actor is simply absent and nothing on screen says why.
- Kubernetes coverage is sixteen kinds, not arbitrary custom resources.
- No PDF export. CSV exists, is generated in the browser, and carries aggregate report metrics only; there is no per-finding export in any format.
- No cost governance and no pull-request-time gate beyond the CI/CD policy templates for Terraform changes.
- Scans are point-in-time, on a schedule you set. This is not a live feed and we will not describe it as one.
- Nothing phones home: no telemetry, no analytics, no licence server, and it runs air-gapped. But three paths do carry finding data outward when you configure them: notification webhooks, and the GitHub and GitLab integrations that open remediation pull requests. We will not tell you nothing leaves your environment, because that would not be true.
Which one to pick
Choose driftctl if a one-shot or CI-wrapped scan is genuinely all you need, you’re comfortable being on your own for support, and Kubernetes isn’t part of what you’re checking.
Choose Cloudkeel-DD if you want a continuous, scheduled view with history, severity, suppression and policy checks built in, and your estate includes a Kubernetes cluster you also want covered, running entirely inside infrastructure you already control.
They are not mutually exclusive. Nothing stops you running driftctl as a point check and Cloudkeel-DD as the continuous layer underneath it.
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
- What Cloudkeel-DD is: the product page
- Exactly where the depth ends: coverage, generated from the engine
- Install it yourself: no call, no account
Sources
- driftctl README and maintenance-mode notice, feature list, license, cloud provider coverage: github.com/snyk/driftctl
- Repository metadata (archived status, last push, license, star count): the GitHub API, read directly, 2026-09-12.
Read 2026-09-12. If any of this has changed, tell us and we will correct it: a comparison that goes stale is worse than none.