driftctl Alternatives: Replacing Drift and Coverage

• driftctl did two different jobs
• What Terraform gives you natively
• The alternatives, mapped to which half you need
• The limit every state-comparison tool shares
• Why we compare against a baseline rather than state
• Migrating off driftctl
• Frequently asked questions

driftctl answered a question terraform plan cannot: not just whether your managed resources have changed, but how much of your infrastructure is managed at all. Its README now states the project is in maintenance mode, and the most recent tagged release is v0.40.0 from December 2023. If you built a process on it, this page is about what replaces which half.

driftctl did two different jobs

This is the part that matters when choosing a replacement, because most tools do one and not the other.

Drift. Compare Terraform state against what is actually deployed and report the differences. Resources whose real configuration no longer matches what state says.

Coverage. Enumerate what exists in the cloud and report what is not in your state at all. That number, the percentage of infrastructure actually under IaC management, was driftctl's real contribution. Nothing in Terraform reports it, because Terraform only knows about resources it manages.

If you only needed drift, several things replace it. If you needed coverage, your options narrow sharply, and it is worth checking which number your dashboard was actually built around.

What Terraform gives you natively

Running terraform plan against a workspace with no pending code changes shows configuration drift on managed resources. It is free and it is honest about what it sees.

Two limits are worth being precise about, because they are why driftctl existed.

It is blind to unmanaged resources. A plan iterates the resources in your state. Something created by hand in the console is not in state, so a plan will never mention it. Your infrastructure can be half unmanaged and every plan comes back clean.

It is a point-in-time refresh, not a record. A plan tells you the state of things at the moment you ran it. If someone changes a security group and changes it back before your next run, the plan shows nothing. That change still happened, and in a security review it matters.

Terraform Cloud and Terraform Enterprise add scheduled drift detection on top, which addresses the second limit for managed resources. Neither addresses the first.

The alternatives, mapped to which half you need

AWS Config deserves a mention because it is often already switched on. It records configuration history for supported resource types and will tell you what changed and when, which is genuinely useful. It knows nothing about Terraform, so it cannot tell you whether a change was intended by your code. It is also billed per configuration item recorded, which surprises people at scale.

The limit every state-comparison tool shares

Worth understanding regardless of what you pick, because it changes what you should ask a vendor.

Comparing state to reality is a poll. It tells you the difference between two snapshots. It cannot tell you about a change that was made and reverted between polls, and it cannot tell you who made it or when.

Reading account events is a different mechanism. It records the change as it happens, along with the identity that made it. That catches the temporary change a poll misses entirely, which is often the one worth knowing about.

The trade is that event-sourced findings have no before-and-after values. The event says a change occurred, not what the previous configuration was. Any tool claiming a previous value on an event-sourced finding is narrating something it never observed. We treat those two classes of finding separately for exactly that reason, and the setup is described here.

Why we compare against a baseline rather than state

One design difference worth explaining, since it determines what you can detect.

A state file describes what Terraform believes it manages. Comparing against it inherits that blind spot: anything outside state is invisible. So instead of reading your state, a scan enumerates the account and compares against an approved baseline of what the account should look like.

That has a practical consequence. Resources nobody ever codified appear as findings rather than as silence, which is the coverage half of what driftctl gave you. It also means the comparison does not depend on having access to your state file, which for a customer's state in a customer's bucket is a meaningful difference in what you have to hand over.

Migrating off driftctl

1. Work out which number you were watching. If dashboards tracked coverage percentage, a plan-based replacement will not produce it and you will find that out late.
2. Keep driftctl running while you evaluate. It is in maintenance mode, not broken. Nothing forces a same-week migration.
3. Check provider coverage against your actual account. Every tool in this category supports a subset of resource types. The right test is your account, not a feature list.
4. Decide whether you need event-sourced detection. If you care about changes that were reverted before anyone looked, polling will not find them.
5. Confirm what access is required. Some tools need your state file, some need read-only cloud access, and those are different security conversations.

What drift actually is, and why the plan-based definition is narrower than most teams assume, is in the drift detection guide.

Frequently asked questions

Is driftctl still maintained?

Its README states the project is in maintenance mode and that contributions cannot be promised a review. The most recent tagged release is v0.40.0 from December 2023, though the repository is not archived and has seen activity since. It still runs; it is not moving forward.

What is the best driftctl alternative?

It depends which of driftctl's two jobs you relied on. For drift on resources Terraform already manages, terraform plan does it free and Terraform Cloud adds scheduling. For coverage, meaning resources that are not in your state at all, your options narrow sharply because a plan cannot see them by definition.

Can terraform plan detect drift on its own?

Yes, for resources in your state. Running a plan with no pending code changes shows configuration drift on managed resources. It cannot see anything that is not in state, so infrastructure created by hand in the console never appears, and a plan is a point-in-time refresh rather than a record of what happened between runs.

How do I find AWS resources that are not managed by Terraform?

Not with terraform plan, which iterates only what is already in state. You need something that enumerates the cloud account independently and compares that inventory against what your IaC manages. That coverage number was driftctl's main contribution and is the harder half to replace.

Is AWS Config a driftctl replacement?

Partly. AWS Config records configuration history for supported resource types and will tell you what changed and when, which is useful and often already enabled. It is not IaC-aware, so it cannot tell you whether a change contradicted your Terraform. It is also billed per configuration item recorded, which grows at scale.

What is the difference between state-based and event-based drift detection?

State comparison is a poll: it reports the difference between two snapshots and cannot see a change that was made and reverted in between, or say who made it. Event-based detection records the change as it happens along with the identity responsible. The trade is that event-sourced findings carry no before-and-after values, because the event records that a change occurred rather than what the previous configuration was.

Do I have to give a drift tool my Terraform state file?

It depends on the design. Tools that compare against state need access to it. A tool that enumerates the account and compares against an approved baseline does not, which is a different and usually smaller security conversation, particularly when the state lives in a customer's own bucket.

How urgently do I need to migrate off driftctl?

Not urgently. Maintenance mode is not the same as broken, and the tool still runs. Keep it in place while you evaluate, and test any replacement against your actual account rather than a feature list, because every tool in this category supports a different subset of resource types.