This content originally appeared on DEV Community and was authored by Sibusiso Mfana

About three months ago, I started my journey with Ansible, a configuration and Infrastructure as Code (IaC) tool used by over 20,000 companies.
At first, I really liked it.

There were some genuinely great things about Ansible that made it enjoyable to work with:

Push-based: I write the config, and it just goes over SSH. No need for a big control plane or cloud API.

Agentless: No weird daemons to install on every server. Just SSH and vibes.

Collections: A whole ecosystem of plugins for AWS, Docker, Kubernetes — you name it.

But the problems started early.

The friction

Ansible had me debugging ansible.cfg before I even wrote my first playbook.
Then came the Python version hell. One moment it’s working, the next it’s yelling about bcrypt being outdated — and just like that, Ansible left the chat. Eventually, I gave up and started running Ansible inside Docker.

Along came the YAML mess and its indentation problems. Oh, and the autocomplete feature on VS Code? That’s just decoration.
Error messages? Either very Python-based, vague, or just you messing up Jinja. Not even GitHub Copilot wanted to help out.

Worst of all, for someone who just joined a new company and is configuring servers? No undo button.

Oh, and don’t get me started on the amount of time you have to wait for your Ansible plays to execute. You might as well build the CI/CD pipeline that will cost you a lot to run those Ansible plays — because at least they would discount your convenience.

The Building of Settle

After two months of after-hours, weekends, missing family events, and saying no to going out, I’ve built Settle to a point where I can demo it and open source it — so we can build it up into the config-as-code tool of the future.

The future of config is not large YAML files that claim to be easy to follow but require a course to even understand how they are structured.
The future of config is a declarative approach — one that keeps track of the state of your configs, one where the autocomplete tool actually works and helps you get a lot done.

The Settle Philosophy

I am building settle on 3 core beliefs:

1. Configuration should feel like programming, not punishment
   Configuring servers should be clear, expressive, and easy to plug in and play.
   Settle is built in Go and takes inspiration from Terraform for its simplicity and readability — but it is purpose-built for system-level configs.

2. State matters
   Every resource in Settle knows what it should look like and compares that to the real system. It doesn’t assume anything — it checks, diffs, and only applies what’s necessary. No more re-running playbooks and hoping for the best.

3. Fast feedback > Fancy features
   We value speed and clarity over features for features’ sake.

Settle gives you:

• Fast execution (built in Go)
• Clear, structured plans
• Real dependency graphs
• Sensible logging and dry-runs

If your tool takes longer than your mental context window, it’s already failed you.

Push-based, agentless, idempotent, state-aware. Just enough abstraction to be useful. No YAML. No drama.

An example of what a settle unit that installs nginx looks like

package "nginx" {
version = "1.18"
manager = "apt"
}

Readable. Declarative. fast and easy.

Settlectl command

• settlectl ping – Checks connectivity to your target hosts over SSH.
  Useful for quick reachability checks before applying anything.

• settlectl create – Applies your configuration and brings resources into the desired state.
  Reads from your .stl files and executes the plan.

• settlectl plan -o plan – Generates a plan that shows what changes will be made to bring your systems into the desired state — without making any changes yet.

• settlectl clean – Remove resources declared in .stl files from remote systems (yes, finally — an undo button).

Why did I even bother, if ansible works then why fix it?

Truth be told, this started off as a challenge to myself — to build out what I feel is worth it to me.
Secondly, I want to add value to the tech world. I wanted to gain the confidence to start taking on experts in the system admin, DevOps, and cloud engineering world — and it starts with pissing off Ansible fans.

Settle is coming soon to GitHub. I’ll be open-sourcing it shortly — and I’d love your feedback, forks, and maybe even a few PRs.

Follow along. Or join in.
The future of config doesn’t have to be painful.

This content originally appeared on DEV Community and was authored by Sibusiso Mfana