Introducing Drift Detection

When infrastructure lives across hundreds of customer environments, keeping track of which environments have silently drifted away from their intended configuration is critical.

Today, we’re excited to announce Drift Detection, a unified way to detect configuration drift across Terraform, Helm, and Kubernetes manifest components, purpose-built for Bring Your Own Cloud (BYOC). In a future post, we’ll share a behind-the-scenes look at how we built this capability into our platform.

ICYMI: Check out all of our latest Launch Week Blogs: Day 1 Change Controls, Day 2 Approvals, Day 4 Break Glass.

Why Drift Detection Matters

In BYOC setups, every customer install runs in their own cloud account. While that gives customers control, it also means they can make direct changes such as editing a Helm value, patching a Kubernetes resource, or tweaking a Terraform-managed IAM policy.

Over time, these manual or automated changes cause the state of that particular install to drift away from the intended state. The result: failed upgrades, inconsistent environments, and hidden security gaps.

Drift can appear in many forms:

• Customer Drift: when a customer intentionally or accidentally modifies or deletes a resource. For example, a user might scale down a node pool or remove a secret they thought was unused.
• Automation Drift: when an automated system such as an operator, external controller, or cloud policy reverts or mutates a configuration unexpectedly.
• Lost State: when resources are provisioned successfully but are no longer tracked, such as a missing Terraform state. For example, imagine a machine crashes unexpectedly during a terraform apply, right after a resource has been created but before its state is written to the Terraform backend.

Automated and On-Demand Checks

With Drift Detection, teams can now:

• Run ad-hoc scans to compare live resources against their defined configuration.
• Schedule drift checks on a cron per component, such as nightly checks for Terraform or weekly checks for Helm charts.
• Have an audit trail of the changes that have been made over time.

Whether you manage ten environments or hundreds, Drift Detection keeps each one aligned with your intended configuration.

Unified Across Terraform, Helm, and Kubernetes

Our approach works seamlessly across multiple resource types:

• Terraform: detect manual edits to cloud resources that were managed by Terraform.
• Helm: identify chart value or manifest changes made directly in clusters.
• Kubernetes Manifests: identify drift between the current and desired manifest.

Each scan highlights which resources have diverged and what changed, helping teams decide whether to reconcile or accept the new state by discussing the needs of customers and updating components.

Designed for Scale in BYOC Environments

Drift Detection is lightweight, parallelizable across various installs, and built to operate in customer environments with minimal permissions. It is especially powerful in large-scale BYOC setups, where installations evolve independently and traditional drift tools cannot reach.

By centralizing drift visibility, platform teams can:

• Spot inconsistencies early
• Ensure smooth, predictable upgrades
• Maintain compliance and security baselines across all installations

Why Constant Reconciliation Isn’t Always Possible in BYOC

Continuous reconciliation, where a controller constantly syncs live state back to the desired configuration, is rising in popularity as a way to manage drift. We believe constant reconciliation can’t work in a BYOC model. Here’s why:

• Permission Boundaries Change Over Time. When provisioning the install, vendors often use a Provision role with broad permissions to create resources. Later, customers may revoke this and limit vendors to a Maintenance role for ongoing updates or health checks. So if a customer accidentally deletes a resource such as a bucket or IAM role, the vendor might not have permission to recreate it automatically.
• Visibility Is Critical. As part of meeting the vendor's SLA, the vendor needs to quickly see what changed and why a service might be down, not attempt blind reconciliation. Along with the audit trail, a clear diff helps explain to the customer what changed. Then, the vendor can guide them to restore the necessary permissions before fixing the issue.
• Some Changes Are Intentional. Customers may modify a component to meet specific security or compliance requirements. In these cases, the vendor should adopt and validate the change rather than blindly rolling it back. Drift visibility allows both sides to make informed decisions about what should remain and what should be corrected.

Constant reconciliation tools often assume full, continuous access to make changes. In BYOC setups, that assumption simply does not hold true.

Drift Happens. Stay Ahead of It.

Drift is inevitable, but surprises are not. With automated Drift Detection across Terraform, Helm, and Kubernetes, you can stay confident that every customer environment matches the state you intended to deploy.

Run your first drift scan today and keep every installation in sync.