Standing service terraform-drift-reviewed-monthly · revised 11 October 2026
Standing service
Check your Terraform for drift every month and get each difference explained
Each month a plan is run with a credential that cannot change your cloud resources, every difference from the live resources is explained, and you get a proposed fix for each.
This starts a conversation by email. Nothing is charged, and no plan is run, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Terraform describes what should exist, and the plan shows how reality differs. When people change resources by hand, or a provider changes defaults, the difference grows quietly until the plan is too noisy to trust. A plan that proposes to replace a resource that holds data is a risk, and an unexplained plan stops anyone applying a small change safely.
Who it’s for: A small engineering team that manages cloud resources with Terraform but where people also change things in the console, so nobody knows whether the code still describes reality.
Usually starts when: A plan that nobody dares apply because it shows unexplained changes, or a console fix made during an incident that was never written back into code.
The result: Once a month a plan is run for one named configuration with a credential that cannot change your cloud resources. Every difference between the code and the live resources is explained as an intended manual change, an accident or out-of-date code, with a proposed fix, and a plan with no changes is the aim for each month. You decide and apply.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A date for each monthly report and a target for raising a finding are agreed in writing before it starts.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer round-the-clock cover.
What must remain true
- The difference between the named configuration and the live resources is known and explained every month
- Any plan that would destroy or replace a resource is raised for a decision before anyone applies it
What we watch
- A monthly read-only plan for the named configuration
- Your own notes of manual changes and incident fixes
- Provider and Terraform release notes that affect the configuration
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| The monthly plan reports changes. | We classify each difference as an intended manual change, an accident or out-of-date code and propose the code change or the corrective apply. |
| The plan would destroy or replace a resource that holds data. | We stop and raise it in that month's report and before anything is applied, under the notification target agreed in writing before the service starts, with the plan lines and the risk. |
| A month ends. | We send the report: differences found, fixed, accepted and still open. |
We do on our own
- Run read-only plans through the agreed route
- Classify differences and prepare proposed code changes
- Write the monthly report
We ask you first
- Any apply, import or state change
- Merging a proposed change to your configuration repository
- Any change to provider or Terraform versions
We escalate to you when
- A plan would destroy or replace a data-bearing resource
- The plan fails in a way that suggests a state or credential problem
- A resource appears that nobody on your team recognises
How you know it held. Each month you get the plan summary, the classification of every difference and the status of each earlier one, so you can see whether drift is shrinking.
How we keep it true
This service is never finished. Each month's report shows whether the code and the live resources agree, and it continues until you end it.
Write one Terraform module for a defined resource set, with the plan reviewed Job Optional
One defined set of cloud resources is written as a reusable Terraform module with named inputs and outputs, and a plan against a test account is reviewed line by line before you apply anything.
A module with a reviewed plan gives the monthly comparison a clean starting point, but the review also works on an existing configuration without it.
What is included, and what is not
- The plan output, handled as sensitive, with a classification of each difference
- A proposed code change for each difference that should be written back, as a reviewable change
- A short monthly report and a list of decisions for you
Included
- One Terraform configuration and its remote state, in one cloud account
- A monthly plan run with a read-only credential that cannot change your cloud resources, plus the state lock the plan takes by default, and a refresh-only comparison where useful
- A line-by-line explanation of each difference, with a proposed change to the code or to the resource
- A monthly report of the differences found, fixed, accepted and still open
Not included
- Applying changes to your cloud account
- Bringing resources that Terraform does not manage under Terraform
- Writing new modules, which is a separate job
- Cloud security review or cost review
- Any promise that the plan will be clean in a given month
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month's report accounts for every resource change in the plan, with a classification and a proposed action for each.
Evidence: The plan summary and the classification table, one row per change.
Any destroy or replace line is identified, explained and raised with you before the month ends.
Evidence: The flagged lines and the date they were raised.
No change was made to your cloud resources by this service, and the only writes to your state backend are the plan's own lock entries.
Evidence: Your provider's audit log for the read-only credential showing only read calls on your resources, and the state's serial or version unchanged before and after the run, with the backend's lock entries, which you can check yourself.
The report states the status of every earlier difference: closed, accepted or still open.
Evidence: The status table across months.
Sign-off. You read each monthly report and decide on each difference. A month counts as delivered when you have received the report and the classification of every change.
If it fails. If a plan cannot be run safely we say why, you are not billed for a report we could not produce, and we do not guess at differences. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- The configuration already uses a remote backend and runs a plan successfully today
- You can provide a least-privilege, read-only credential for the cloud account that cannot change your cloud resources, plus read access to the state and permission to take and release its lock, all created and revoked by you
- A person on your side reviews each proposed change and applies it
- The configuration does not need production secrets in plain text to plan
We stop and tell you if
- A plan cannot run without write access to your cloud resources, or without a state lock that you will not allow
- The configuration is so large or so broken that a plan fails before it can be read
- The plan output would have to be stored somewhere you cannot control
- Most resources are not managed by Terraform at all
What could go wrong
The service changes nothing in your cloud resources. A code change we propose is a reviewable change that you can decline or revert. Ending the service leaves your configuration and state as they are, apart from any lock released when a run ends.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Plan output exposes sensitive values. | Run it through a route you control, handle the output as sensitive, do not keep it after the report is accepted and keep values out of the report. |
| A proposed fix applied without reading reverses an intended manual change. | Each proposal says which direction it takes and why, and you apply nothing without reading it. |
| A read-only credential is broader than intended. | You create it with the least privilege, review it and revoke it whenever you wish. |
| The state lock taken by the plan blocks a colleague's run, or is left behind if a run is interrupted. | Runs happen on the day agreed, a lock timeout is set so a plan waits rather than fails, and a stale lock is released only by you. |
A reviewer separate from the work that produced the classification reads each destroy or replace line and each proposed change. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review every proposed change
- You apply every change with your own credentials
Access we would need
- A read-only cloud credential that cannot change your cloud resources, plus read access to the state and permission to take and release its lock, created and revoked by you
- Read access to the configuration
Questions
Will you fix the drift?
We explain each difference and propose the fix. You apply it or merge it. We never apply changes to your account.
What is drift?
The difference between what your Terraform code says should exist and what actually exists, usually after a change made by hand in a console.
Is my state safe with you?
We read it only through a route you create and can revoke, treat plan output as sensitive and do not keep it after the report is accepted.
What if the plan is already clean?
Then the report says so, and still lists provider or version changes that may affect the next plan.
Send an enquiry
Send us
- The cloud provider, the Terraform version and where the state is stored
- How often people change resources by hand, in your experience
- Whether the plan is clean, noisy or unrun today
- Do not send credentials, state files or plan output in the first enquiry
Later, once you agree
- A read-only cloud credential that cannot change your cloud resources, plus read access to the state and permission to take and release its lock, created and revoked by you
- A read-only copy of the configuration through the agreed route
- The reviewer on your side and the day of the month for the report
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the cloud accounts, the configuration and the state. We run plans only through a route that you create and can revoke, treat plan output as sensitive and do not keep it after the monthly report is accepted. The cloud credential is read-only and cannot change your resources. terraform plan takes a lock on the state by default, which is a small write to the state backend, so the route also needs lock access to it; HashiCorp documents that turning the lock off is dangerous if anyone else might run Terraform at the same time, so we do that only if you tell us nobody else does and you approve it in writing. You apply any change with your own credentials.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “terraform-drift-reviewed-monthly” as the subject.