Drift Detection

Detect when infrastructure state diverges from the desired blueprint configuration

Overview

Drift detection helps you identify when a deployed environment no longer matches its defined blueprint. In Bluebricks, you can continuously compare the actual cloud state with the desired state declared in your Infrastructure as Code. If resources were modified manually, changed outside the pipeline, or partially failed during execution, we surface that difference as drift. This gives you clear visibility into what changed, where it changed, and whether action is required, so you can restore consistency and keep your environments reliable and automation-ready.

How drift detection works

When a drift check runs, Bluebricks performs a plan-only execution against the environment’s current blueprint configuration. This run does not apply changes. It safely evaluates the difference between the declared state and the live resources in the connected collection.

During the run, Bluebricks:

• Executes a plan-only run using the latest Blueprint configuration

• Compares the declared state with the actual cloud resources

• Identifies differences such as added, changed, or deleted resources

• Records the result as a drift detection activity in the environment history

If the plan returns zero changes, the environment matches the declared code and no further action is required. If differences are detected, the environment status is flagged as Drifted, indicating that the live infrastructure no longer aligns with the Blueprint and review is required.

How to enable automatic drift detection

You enable drift detection per environment. Once enabled, Bluebricks runs drift checks on the configured schedule.

1. Open the environment detail page

2. Go to the Drift tab

3. Toggle drift detection to On

4. Optionally, enable Auto-Remediate to automatically correct detected drift

The drift detection label shows the current state: On, Off, or Paused.

By default, checks run every 24 hours at 2:00 AM UTC.

Auto-Remediation

Auto-remediation automatically corrects detected drift by reapplying the declared configuration.

How it works

1. A drift detection run executes a plan-only check

2. If the plan detects drift, Bluebricks automatically initiates a second run

3. The second run executes with auto-approve, applying the plan without waiting for manual approval

4. The environment is brought back to its declared state

Both the detection run and the remediation run appear in the environment's activity history as separate entries.

Safeguards

• No concurrent tasks: Bluebricks does not start a remediation run if another task is already in progress on the same environment.

• Respects collection policies: auto-remediation follows the same policy framework as regular runs.

• Full audit trail: every auto-remediation run is logged with plan output, apply logs, and state changes.

When to enable auto-remediation

• You maintain a strict desired-state model and want zero tolerance for drift.

• Your environments enforce compliance or security baselines that must not diverge.

• Your team has confidence in the declared configuration and wants hands-off correction.

When to avoid auto-remediation

• Your team makes intentional manual changes that should persist (for example, during incident response).

• Your blueprints include resources where the live state is expected to diverge from the declared configuration.

• You prefer to review drift diffs before taking corrective action.

Auto-remediation applies changes automatically. Make sure your blueprint configuration is accurate and tested before enabling it on production environments.

Drift runs history

Drift detection runs appear in the environment's activity history alongside regular runs. You can distinguish them by:

• Task type: drift runs are labeled with the drift_detection task type.

• Plan-only indicator: drift runs are always plan-only and never include an apply phase.

• Drift tab: the Drift tab on the environment detail page provides a focused view of drift status, including the latest result and historical drift runs.

When drift is detected, the drift details show which resources changed, the attribute-level diffs, and whether resources were added, modified, or deleted outside of Bluebricks.