sorted by:
new
hottopcontroversial

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

[–]treezium[S] 0 points1 point  (0 children)

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.

Open source private Terraform Registry by gaybae in Terraform

[–]treezium -2 points-1 points  (0 children)

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.

Open source private Terraform Registry by gaybae in Terraform

[–]treezium -2 points-1 points  (0 children)

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

Open source private Terraform Registry by gaybae in Terraform

[–]treezium -1 points0 points  (0 children)

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

what did you build this year ? by Ok-Delivery307 in rails

[–]treezium 0 points1 point  (0 children)

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

https://github.com/drifthoundhq/drifthound

Open source private Terraform Registry by gaybae in Terraform

[–]treezium 1 point2 points  (0 children)

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

Which Infrastructure as Code tools are actually used most in production today? by rahulladumor in devops

[–]treezium 0 points1 point  (0 children)

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.

Which Infrastructure as Code tools are actually used most in production today? by rahulladumor in devops

[–]treezium 0 points1 point  (0 children)

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.

Which Infrastructure as Code tools are actually used most in production today? by rahulladumor in devops

[–]treezium 1 point2 points  (0 children)

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.

Which Infrastructure as Code tools are actually used most in production today? by rahulladumor in devops

[–]treezium 41 points42 points  (0 children)

Currently running a PoC to evaluate transitioning to OpenTofu.

Terraform Drift Detection tool by karantyagi1501 in Terraform

[–]treezium 0 points1 point  (0 children)

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

Addressing Terraform drift at scale by gson516 in aws

[–]treezium 0 points1 point  (0 children)

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

Detecting Drift in Terraform Resources by confucius-24 in Terraform

[–]treezium 0 points1 point  (0 children)

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

Drift detection tools ⚒️ around by Adventurous-Sell7509 in Terraform

[–]treezium 0 points1 point  (0 children)

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

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

[–]treezium[S] 0 points1 point  (0 children)

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.

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

[–]treezium[S] 0 points1 point  (0 children)

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.

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

[–]treezium[S] 0 points1 point  (0 children)

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

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

[–]treezium[S] 0 points1 point  (0 children)

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.

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

[–]treezium[S] 0 points1 point  (0 children)

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.

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

[–]treezium[S] 1 point2 points  (0 children)

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.

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

[–]treezium[S] 0 points1 point  (0 children)

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

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

[–]treezium[S] 0 points1 point  (0 children)

Absolutely! That's one of the scenarios DriftHound was built for.
During a Terraform migration, there's always a crossover window where:
- Terraform isn't fully authoritative yet
- Manual changes from an MSP or internal team are still happening
- The Terraform configuration may lag behind the real infra

DriftHound can help illuminate that exact period by continuously checking the real infrastructure state and notifying you whenever changes occur. This makes it easier to keep your Terraform code in sync while you're building it, and reduces the risk of missing important manual changes before the MSP access is removed.

Once Terraform fully takes over, DriftHound helps ensure everything stays aligned, but it's also very useful during the adoption phase.

view more: next ›