How to Fix Configuration Drift with Ansible
Published September 19, 2026 · 6 min read
Configuration drift is one of the most common—and most quietly destructive—problems in infrastructure management. A server that worked perfectly last month suddenly fails a deployment, and nobody can say exactly why. This guide covers what drift actually is, why it happens, and the concrete Ansible practices that stop it for good.
What is configuration drift?
Configuration drift happens when a server's actual state gradually diverges from its intended state. It starts small: someone SSHes in to apply a quick patch, installs a package manually to unblock a deploy, or tweaks a config file during an incident and forgets to document it. Multiply that across dozens or hundreds of servers over months, and no two machines in your "identical" fleet are actually identical anymore.
Why drift is so dangerous
Drift doesn't announce itself. It surfaces later, as one of these symptoms:
- "Works on my machine" failures — a deploy succeeds on one node and fails on another with the same supposed configuration.
- Security gaps — a manually patched server today is an unpatched server in six months, with no record of what was ever applied.
- Unreproducible incidents — you can't roll back to a "known good" state, because no state was ever actually known or recorded.
- Failed disaster recovery — a DR server built from an old image doesn't match what production has silently become.
Step 1: Make every change idempotent
The foundation of drift-free infrastructure is idempotency: running the same playbook twice should produce the same result, with no side effects on the second run. Ansible modules are idempotent by design when used correctly—prefer the package, copy, template, and service modules over raw shell or command tasks, which don't track state and will happily re-apply changes every run.
Step 2: Run playbooks on a schedule, not just on deploy
Most drift creeps in between deployments, not during them. Scheduling your playbooks to run automatically—hourly or daily via cron, a CI/CD pipeline, or an orchestrator like AWX/Ansible Automation Controller—means any manual change gets silently reverted back to the defined state before it can cause damage. This turns Ansible from a one-time provisioning tool into a continuous enforcement layer.
Step 3: Detect drift before you fix it
Run playbooks in check mode (--check --diff) against production on a regular basis. This reports exactly what would change without applying anything—giving you a clear drift report you can review, rather than blindly overwriting a change that might have been intentional.
Step 4: Lock down manual access
Technical controls only work if they're paired with process. Restrict direct SSH access to production servers and route all changes through playbooks and pull requests. If engineers can't make ad-hoc changes, they can't introduce drift—full stop.
Step 5: Version-control everything
Playbooks, roles, and inventory should live in Git, with changes reviewed the same way you review application code. This gives you the audit trail that manual administration never had: who changed what, when, and why.
The result
Teams that follow this pattern stop firefighting drift-related incidents entirely. Every server matches its playbook definition, every change is reviewed and recorded, and "it works on my machine" becomes a non-issue because there's no longer a meaningful difference between machines.
Want this built for your infrastructure?
We design and implement drift-free Ansible automation for production environments—from a single quickstart sprint to full enterprise rollout.
Schedule an Automation Audit