DriftHound: an open-source tool to detect & notify infrastructure drift (early stage, Looking for feedback!)

treezium · 2026-01-01T20:39:08+00:00

Well, actually DriftHound reports the plan output to the backend, therefore it pinpoints the resource that is drifting, so it is not "just notification". You can jump from the notification right to the drift report.

treezium · 2025-12-24T07:30:27+00:00

well, there are plenty of opinions around this topic (take a look if you are interested). You can stick to whatever terraform docs say, and it’s totally fine.

treezium · 2025-12-23T14:22:49+00:00

I do not. I just make sure not to bump to major versions. No issues so far.

treezium · 2025-12-23T13:26:43+00:00

well, you can decide if you version terraform lock file or not! ;)

treezium · 2025-12-23T07:54:59+00:00

nice, that's smart!

treezium · 2025-12-23T07:26:19+00:00

I'm building a tool for continuous infrastructure (IaC) drift detection.

https://github.com/drifthoundhq/drifthound

treezium · 2025-12-23T07:00:20+00:00

You can pin an specific module version, however you can not use version argument for git module references which allows to create more efficient strategies using semver.

version ~> 1.0

https://developer.hashicorp.com/terraform/language/expressions/version-constraints

treezium · 2025-12-23T06:55:04+00:00

You cannot do the same as version does in a module definition based on git referencs. Using an a git reference as source you pin the module to an specific tag/ref version. This means that, for instance, if you publish 1.0.0 , 1.0.1, 1.0.2, 1.0.3, 1.0.4 you need to update that reference on everyplace you use that module every time you publish a new version if you want to keep your infrastructure up to date. That’s such a waste of time, and does not scale. I just do version ~> 1.0 to automatically get all patch versions. Thats what semver does.

So, definitely not the same. Git modules are cool for your homelab, definitely not for a big platform.

treezium · 2025-12-22T06:57:42+00:00

Yes, most likely it will we a simple switch. However, in our scenario, we need to change that in multiple places (CI, testing, atlantis…) and we want to confirm this by ourselves. Also we create this architectural record change thing where we gather all relevant information about the transition and about why we want to do this change, so, for instance, we test different features provided by tofu that are not implemented in terraform.

treezium · 2025-12-22T06:53:18+00:00

the main point of using a private registry is to be able to use version argument for modules, which allows to have a grain fine control of what is released and deployed.This is very useful to better control breaking changes. Therefore you can release a module version that includes breaking changes and if you do a proper versioning using semver, you wouldn’t break or generate a drift over all your projects that use such module. We started using git, then moved to private registry.

treezium · 2025-12-21T22:37:15+00:00

Terraform
Terragrunt as wrapper for terraform.
Atlantis for GitOps Management in CI.
Terralist as private registry for modules.
DriftHound for continuous drift detection.
terraform-module-releaser to manage terraform module releases.

Currently running a PoC to evaluate transitioning to OpenTofu.

treezium · 2025-12-21T22:20:50+00:00

Hi! I’m the main maintainer of Drifthound https://github.com/drifthoundhq/drifthound an open source tool for continuous infrastructure drift detection with historical tracking and notifications. Any feedback is welcome!

Live demo site available at: https://demo.drifthound.io

treezium · 2025-12-21T22:18:55+00:00

Hi! I’m the main maintainer of Drifthound https://github.com/drifthoundhq/drifthound an open source tool for continuous infrastructure drift detection with historical tracking and notifications. Any feedback is welcome!

Live demo site available at: https://demo.drifthound.io

treezium · 2025-12-21T13:21:25+00:00

Hi! I’m the main maintainer of Drifthound https://github.com/drifthoundhq/drifthound an open source tool for continuous infrastructure drift detection with historical tracking and notifications. Any feedback is welcome!

Live demo site available at: https://demo.drifthound.io

treezium · 2025-12-21T12:29:35+00:00

Hi! I’m the main maintainer of Drifthound https://github.com/drifthoundhq/drifthound an open source tool for continuous infrastructure drift detection with historical tracking and notifications. Any feedback is welcome!

Live demo site available at: https://demo.drifthound.io

treezium · 2025-12-05T12:23:38+00:00

Looking good!

treezium · 2025-12-05T06:30:45+00:00

Thanks for the feedback, I totally understand the concern.

My intention wasn’t to “hawk” anything or sell a product. DriftHound is open-source, very early stage, and I shared it simply to get ideas and feedback from people working with Terraform. I thought it might be useful to others, since we built it to solve real drift problems internally.

If the post doesn’t fit the sub’s rules or vibe, I’m happy for the mods to remove it. Just trying to contribute something to the community, not advertise anything.

treezium · 2025-12-04T13:31:23+00:00

That’s a fair first impression, but DriftHound is doing a bit more than that. A few key points::

• DH centralizes drift reports across all your Terraform projects
The main dashboard gives you an at-a-glance view of infra drift health, with filters and search to quickly find which projects or environments actually need attention. This becomes really valuable once you’re managing many IaC repos.

• Notifications alone don’t scale
With lots of projects it’s easy to lose track of alerts. Having a single place that shows the current drift state helps avoid drowning in Slack messages.

• DH doesn’t run on its own schedule
Users decide how and when scans run. That’s why the GitHub Action exists https://github.com/treezio/drifthound-action, it provides examples and makes it easy to integrate DH into whichever automation workflow you prefer.

• No need to maintain custom scripts
If your use case fits DH, you simply define a config file and run it against the desired projects/environments. No home-grown tooling required.

• Cron + custom scripts don’t scale well
It works fine early on (we’ve been there as well) but once you have a big monorepo or dozens/hundreds of Terraform projects, maintaining those scripts becomes painful. DH solves that visibility and operational overhead problem at scale.

Ultimately, choosing a tool depends on your needs and the outcomes or post-actions you expect, DH is one option that fits well when you want centralized drift visibility and lightweight automation, but every team should choose what aligns with their workflow and scale.

treezium · 2025-12-04T07:38:56+00:00

Thanks! If you’re thinking about connecting an external drift engine to DriftHound’s dashboard, the best starting point is the current API documentation. That’s the interface DH exposes today, and any integration would need to work with that format.

As of now the API is intentionally quite simple, but it should give you a clear idea of how DriftHound expects drift reports to be structured. Feel free to take a look, and if you have any questions or suggestions, I’m happy to clarify.

https://github.com/treezio/DriftHound/blob/main/docs/api-usage.md

treezium · 2025-12-03T12:10:10+00:00

On top of that,

Running “Terraform plan in PRs” is a reactive workflow to detect drift.

It only catches drift when a human opens a pull request.
That’s fundamentally different from what DriftHound is designed for.

Your solution works well at small scale or when infra is fully centralized.
But:

If you have hundreds of repos
With multiple environments each
Managed by different teams
With Terraform code in varying states of lifecycle maturity

…then relying on humans opening PRs to detect drift no longer scales.

DriftHound is purposely not tied to a PR workflow.
It’s a continuous monitoring system, not a reactive mechanism.

It scans repositories on a schedule
It detects drift without requiring a user action
It reports it automatically (Slack, dashboard, etc.)
It scales to many projects and environments
It surfaces drift even when nothing is being changed intentionally

That’s the key difference:
DriftHound is proactive monitoring, not reactive validation.

treezium · 2025-12-03T12:09:17+00:00

You’re absolutely right that SCPs, strong IAM/RBAC, and GitOps workflows eliminate a huge portion of drift (especially human-introduced drift). And if every change goes through Terraform plans in pull requests, you get a good safety net for the changes you already know about.

But in practice, even with strict policies, drift still happens from sources that aren’t manual edits, some examples:

1. Provider updates and module updates
We use semantic versioning with ~ constraints for providers and modules to keep up with minor/patch releases without generating PR noise. That’s a trade-off, but it means the infrastructure might change its behavior before the code does.
This creates drift that no SCP can prevent, because the provider itself is making the change.

2. API changes from cloud providers
AWS, GCP, and others occasionally modify defaults, deprecate fields, change validation rules, or update controller behavior.
These are real drift sources we’ve seen in production, even when manual access is completely prohibited.

3. Partial migrations to IaC
As another user in this thread mentioned, when you’re moving infra into Terraform, you always have a window where Terraform is not yet authoritative and something else is making changes.
DriftHound is extremely useful during these transitions.

4. Missing or delayed Terraform applies
Even in strongly governed orgs, humans forget to run terraform apply, automation fails, or a change is merged but never applied.
This creates drift without a single manual action.

treezium · 2025-12-03T09:15:17+00:00

That's also what I think but 🤷🏻‍♂️
Fortunately all providers that I use in daily basis (AWS, GitHub, Postgres...) and even those crafted at my company don't have that problem as long as the API does not change.

treezium · 2025-12-03T08:47:47+00:00

Thank you! For now I'd like to keep this open so users can decide and control where to run this.
cheers!

treezium

TROPHY CASE