Why We Chose CFEngine Instead of Ansible for Configuration Management

Ask ten engineers which configuration management tool to use and nine will say Ansible. We went the other way. Our fleet, both on-premise and cloud, for clients who expect things to just keep running, is managed by CFEngine. Here are the ten reasons why, and where Ansible still earns its place in our stack.

1. Continuous convergence, not point-in-time runs

Ansible configures a host at the moment you run a playbook. Between runs, nothing watches the machine. CFEngine's agent runs every five minutes, every day, forever. Someone hand-edits a config, a package update overwrites a file, a service dies in the middle of the night, the agent quietly puts it back.

2. Self-healing by design

Because the agent converges continuously, repair isn't a special event, it's the default behaviour. We don't get paged to re-run a playbook; drift is corrected before monitoring even fires. For a managed hosting company, that's not a nice-to-have.

3. Pull beats push at scale

Ansible pushes over SSH from a control node: one machine fanning out to hundreds. Slow runs, timeouts, and a controller that becomes a bottleneck and a single point of failure. CFEngine hosts pull their policy from a hub and execute locally. A thousand hosts converging is no harder than ten, the work is distributed to the machines themselves.

4. A tiny, dependency-free footprint

The CFEngine agent is written in C. It uses a few megabytes of memory and needs no interpreter on the managed host. Ansible needs Python on every target, a real constraint on minimal installs, appliances, and BSD systems. We run infrastructure on machines where a Python runtime is either unwelcome or unavailable. The C agent runs everywhere, including the smallest VPS we manage.

5. Speed

An agent run over our full policy set completes in seconds. Comparable Ansible playbooks take minutes per host, dominated by SSH round-trips and module transfer. Multiply that across a fleet and across every change, and the difference stops being academic.

6. Hosts stay autonomous

Every CFEngine host caches its policy. If the policy server is unreachable, due to network partition, hub maintenance, or datacenter issue, hosts keep enforcing the last known-good policy on their own. An Ansible-managed fleet with an unreachable control node is simply unmanaged until it comes back.

7. A stronger security posture

An Ansible control node holds SSH keys with root access to your entire estate, a high-value target. CFEngine inverts this: no inbound management connections needed, mutual authentication between agent and hub, and policy distributed over a trusted channel. Compromising the hub doesn't hand an attacker an interactive root shell on every host.

8. Promise theory makes intent explicit

Ansible playbooks are ordered task lists, closer to structured scripting than desired state. CFEngine policies are promises: declarations of the state a host should converge to, with the agent deciding what needs doing. The learning curve is steeper, but once it clicks, policies are more predictable and genuinely idempotent, not idempotent-if-every-module-author-did-their-job.

9. Drift detection and reporting built in

Because agents evaluate state constantly, CFEngine knows what changed, on which host, and when fleet-wide inventory and compliance reporting come with the model. With Ansible you only learn about drift when you happen to run a playbook in check mode. For compliance conversations with clients, "here's a continuous report" beats "we ran a scan last Tuesday."

10. Boring in the best way

CFEngine has been maintaining production systems since 1993. The language and the model are stable; policies we wrote years ago still run unmodified. That predictability matters when you're promising clients long-term managed infrastructure, not chasing this year's tooling refresh.

Where Ansible still fits

This isn't a takedown. We use Ansible too, for orchestration, one-off rollouts, and provisioning steps where an ordered, imperative run is exactly what you want. The distinction we draw: Ansible deploys, CFEngine maintains. For the job of keeping hundreds of hosts continuously correct with minimal overhead, CFEngine was the right call, and years of quiet nights due to self-repairs have confirmed it.

Questions about configuration management for your own infrastructure? That's what we do. We build it, we run it, we manage it.