Skip to main content

Account Level Drift Detection

For detecting changes made outside of Spacelift (e.g., via the console, like assigning a target group to a load balancer), im asking for an integration built in via Terraformer. This can complement Spacelift by allowing reconciliation between the actual infrastructure and Terraform state despite those external changes. A visual representation of the one to one maps and therefore the dependent modules would be an amazingly useful suite of tools and add more value to spacelift usage.

Workaround
Problem
Status: ⬆️ Gathering votes3 comments

Log in to comment and vote

Comments3

  • Natalia Gazda

    Team•

    Jul 18, 2025

    Hi @Erick Toledo , thanks for submitting this! Few more questions to improve my understanding of your problem:

    • What specific problems have external, untracked changes caused for your team so far?

    • How frequently do you see drift introduced outside of Terraform workflows—and by whom?

    • What would success look like? Just visibility? Or automatic reconciliation suggestions? Or even re-importing into managed state?

    • How would you expect this to work across multiple Terraform states and stacks? Should Spacelift try to stitch these together?

    • Would this be a regular scan (e.g. daily) or more of a triggered audit workflow?

    • Is the goal purely visibility—or would you want this to inform policy decisions or block certain actions?

    • Apricot Mat

      •

      Jul 18, 2025

      • What specific problems have external, untracked changes caused for your team so far? - the constant need for development or operation usually occurs faster in terms of iteration than it does for infrastructure. This blind spot can cause changes that were made but not checked in to cause configurations to drop upon recreation. We need drift detection to account for all resources.

        How frequently do you see drift introduced outside of Terraform workflows—and by whom? Frequently from everyone- developers, operations, even infrastructure because of time constraints.


      What would success look like? Just visibility? Or automatic reconciliation suggestions? Or even re-importing into managed state? visibility would be minimum, because spacelift designs differ based on modularization it would be difficult to offer reconcilliation suggestions, but that would be a grereat offering even if its a hard coded resources added . However usually there is an adoption in a strong development culture (rather than a bank or something requiring more structure) that says what is up right now is more correct or up to date than infrastructure resources that lag behind by configuration.

      How would you expect this to work across multiple Terraform states and stacks? Should Spacelift try to stitch these together?
      I think it would be best to have a concept that ties the stacks to an account so that the scope of the diffs can show the difference against the account itself.

      Would this be a regular scan (e.g. daily) or more of a triggered audit workflow?
      weekly report and adhoc, i dont believe any one functions for infrastructure resources that change more frequently than that except for those who create ad hoc infrastructures with differening requirements for clients.

      Is the goal purely visibility—or would you want this to inform policy decisions or block certain actions? I would say the best benefit is visiblity, proper practice is that if one assumes that something changed they can verify this way and then importas an extra step if requested.

      • Natalia Gazda

        Team•

        Aug 14, 2025

        Thanks for the replay! I understand the problem, and we know very well that drift is an inevitable part of infrastructure handling.

        What I would recommend for now is to focus on the “prevention” layer, rather than trying to clean up afterwards.

        We might be doing something in that area later this year, though, so I’ll keep you posted. Leaving it to “Gathering votes” in the mean time :)