How InfraOrcinus Detects and Reconciles Cloud Drift

By Chirag Panchal · Founder & Lead Architect · 2026-10-18 · 8 min read

How InfraOrcinus finds drift with scheduled, plan-only checks on every engine, shows the per-resource diff, alerts the team, and fixes drift only through the normal named approval gate. What a check does and does not tell you, and the limits today.

Development Status & Architectural Evolution: InfraOrcinus is in active development. Architecture specifications, internal interfaces, and operational protocols described herein reflect our current engineering design and are continuously refined to make InfraOrcinus robust, resilient, and enterprise-grade.

Infrastructure code and real infrastructure drift apart. An on-call engineer opens a security group in the console during an outage at 2 a.m. Another pipeline touches a resource it should not own. A cloud provider changes a default.

The cost appears later, when nobody is looking:

• Surprising plans. The next routine change also reverts the emergency fix, because nobody knew it was there.
• Silent exposure. An ingress rule opened "temporarily" stays open for weeks.
• Lost trust in the code. Once people suspect the repository no longer describes production, they stop relying on it.

Most teams find drift by accident, in the middle of an unrelated change. InfraOrcinus checks for it on a schedule, shows exactly what differs, and routes any fix through the same human approval as every other change.

1. A Drift Check Is a Plan That Never Applies

InfraOrcinus does not need a separate drift engine. Every IaC tool already knows how to compare declared code with real infrastructure: that is what a plan is. A drift check is therefore an ordinary validate → plan run that stops after the plan. It never reaches approval or apply.

[Schedule or "Check now"]
          │
          ▼
  [Claim the environment]   one run at a time; a busy environment is skipped
          │
          ▼
  [Validate → Plan]         on a runner, in a disposable container
          │
          ▼
  [Normalize the plan]      the same per-resource model every engine produces
          │
     ┌────┴─────┐
     ▼          ▼
 [In sync]   [Drifted] ──► bell alert + drift.detected notification
                    │
                    ▼
        [A person decides how to fix it]

What "plan" means depends on the engine:

Because the check is a normal plan, it uses the same runner, the same credentials and the same normalized plan as a real run. The diff an engineer sees during a drift check is the same diff an approver would see.

2. When Checks Run

• Scheduled. Every eligible environment is checked on an interval an administrator sets under Settings → Drift detection. The default is every 6 hours. A change to the interval takes effect from the next cycle, with no restart.
• Manual. Check now on the Drift page starts a check for one environment at any time.
• Opt-out. An environment can be excluded from the scheduled scan without affecting manual checks. This is useful for sandboxes that are expected to change by hand.
• After a change plan. When a multi-stack change plan finishes a wave, InfraOrcinus runs drift checks on the stacks it touched. The wave counts as verified only if those checks are clean.

A check never competes with a real change. An environment runs one job at a time, enforced by an atomic claim in PostgreSQL. If an apply is in progress when the schedule fires, that environment is skipped for this cycle rather than queued behind it. Archived environments are never checked, and an environment with no credential attached is refused with a clear message.

3. Reading the Result

A finished check is either in sync or drifted. A drifted run shows:

• Counts: resources that would be added, changed or destroyed if the environment were reconciled to its code.
• The per-resource diff: which resource, and which action (create, update, delete, or replace), not just a number. The same expandable list appears on a normal run's page.

One property of plan-based detection is worth stating clearly. A plan compares your code with reality. It cannot tell you which side moved. A drifted result can mean that someone changed the cloud, or that someone changed the code and nobody applied it. The per-resource diff and the environment's run history usually make the cause obvious, and the AI assistant is good at reading them. But the product does not label a change as "out-of-band" for you.

Checks that never finish

A drift run becomes in sync or drifted only when its plan reports back. If the plan job fails, is cancelled, is deleted, or finishes without its result being recorded, the run would otherwise say "scanning" forever. A background reconciler runs at startup and every 2 minutes and closes such runs as error, with a specific reason:

• The plan failed, so drift could not be checked.
• Validation failed, so drift could not be checked.
• The drift plan job was cancelled.
• The plan finished but its result was never recorded. (after 10 minutes)
• Drift check timed out before the plan reported back. (after 2 hours)

An errored run is not retried automatically. Use Check now once the cause is fixed.

4. Alerts

A drifted environment appears in the notification bell in the top bar for everyone who can see that environment, next to runs awaiting approval. It also fires the drift.detected event to any configured notification channel (Slack, Microsoft Teams, email or a webhook), with the environment, the run and the counts.

Dismissing a bell alert is local to your browser. It does not change the drift status, so a teammate still sees it.

5. Fixing Drift: Always Through the Approval Gate

Rolling back an out-of-band change automatically is dangerous. During an incident, the "drift" may be the fix. So InfraOrcinus never reconciles on its own. A person chooses one of two directions:

Bring the infrastructure back to the code

If the code is right and the live resource should match it again, start a normal run: validate → plan → named approval → apply. The approver sees exactly what will be reverted, and for Terraform and OpenTofu the apply runs the saved plan that was approved.

Bring the code up to the infrastructure

If the live state is the correct one, for example a hotfix that should stay, change the environment's variables or edit the blueprint so the code describes reality. The next check then comes back clean.

With the AI assistant

Ask AI on a drifted run opens the assistant with that run's actual resource diff. It explains the likely cause and proposes one of the two paths above:

• Reconcile: it can propose a reconciliation run. This only raises a confirmation card. If you confirm, it starts an ordinary run that still stops at the approval gate. The assistant cannot apply anything by itself, for drift or anything else.
• Adopt: it can propose a variable update (also confirmation-gated), or tell you which file to edit for anything beyond variables.

6. Limits Today

• No severity classification. Every difference counts as drift. A changed tag and an opened firewall rule are both "changed". Read the diff before deciding how urgent it is.
• No automatic pull request. Adopting a change into code is a manual edit. InfraOrcinus does not generate code or open a pull request for it.
• Plan-based, not refresh-only. The check uses each engine's normal plan, so it also reports code changes that have not been applied (see section 3).
• Some engines report noise. Azure what-if can report benign property differences for some resource types. Review a Bicep result before treating it as an incident.
• One organization-wide interval. The schedule is set once for the installation. The only per-environment control is the opt-out, and there is no per-project schedule.

Summary

InfraOrcinus detects drift by running each engine's own plan on a schedule and stopping before apply. It works the same way for Terraform, OpenTofu, Pulumi, Bicep and CloudFormation. The result is a per-resource diff, an alert in the product and in your notification channels, and an AI explanation if you want one. Fixing drift is never automatic: whether the infrastructure moves back to the code or the code moves to the infrastructure, it goes through the same named human approval as every other change.