Why Ansible Still Rules for Your Dev Environment

Sep 18, 2025

Back in the day, before Red Hat acquired Ansible, I was using it to provision Cloudera clusters in massive data centers. And let me tell you, its killer feature wasn’t some complex, enterprise-grade capability. It was pure simplicity.

You just needed SSH, and you were ready to go. The feedback loop was in seconds—a refreshing change from the slow, manual processes we were used to. It was a DevOps dream.

Then came Docker. For many use cases, containers were the new king. They offered a more lightweight, portable solution for shipping applications. And for a while, it seemed like Ansible might get relegated to the history books.

But not so fast. While Docker took over for application deployment, Ansible found its true calling: provisioning the remote development environment.

The New Remote Frontier

Remote development has gone mainstream. Whether you’re using a GUI or a terminal, working on a remote machine makes you more productive. It’s not just a trend; it’s a fundamental shift.

Think about it:

No more “it works on my computer!” Everyone’s environment is the same. No more chasing down dependency hell.
No more wasted time. Your environment is always up to date. The days of git pull followed by hours of fixing a broken dev setup are gone.
More resources, less cost. Remote machines can be shared, giving you access to powerful hardware for a fraction of the price.
Easy authentication. With SSH agent forwarding, pulling and pushing changes to your code repositories is seamless.

It’s a developer’s paradise. But there’s a catch…

The Problem with Ansible’s Language

Ansible is fantastic for this, but its configuration language—YAML—has a few pain points:

It’s another language to master. You have to learn the specific syntax and structure, which can feel like a steep climb on top of everything else you already know.
It’s not flexible enough. Manually curating dozens of YAML files—like packages.yml, repos.yml, and ssh-config.yml—can be tedious and error-prone. The more complex your environment, the messier it gets.

Wouldn’t it be great if you could just write code to generate your configurations?

Introducing BigConfig: The Code-First Approach

This is where a tool like BigConfig comes in. Imagine a world where you write a simple script to generate your Ansible inventory and playbook files. No more manual YAML curation. You can leverage the power of a real programming language to create dynamic configurations.

Here’s the secret: JSON is valid YAML.

This simple fact allows us to generate JSON files with a .yml extension. BigConfig can take your code and spit out a perfect, machine-readable Ansible configuration.

The next logical step? Making the provisioning of your remote development environment an API.

You could simply send a request to a service, and it would provision a new, perfect environment for a new team member in minutes. BigConfig can handle this too, turning a manual, file-based process into a programmable, scalable service.

While some tools come and go, others adapt and find their niche. For provisioning remote development environments, Ansible remains a powerhouse. It just needs a little help from the next generation of tools to unleash its full potential.

Show me the code

This project is specific to my setup but it can be forked and adapted to your needs. I use an iMac and two minipc (soyo and firebat) to develop in the terminal using ssh and tailscale so that I can also code when I am on the road with my Macbook Pro. The ansible project provisions multiple users on both minipc. I use nix and devenv.

https://github.com/amiorin/dotfiles-v3/tree/ansible

Any BigConfig module is also a Clojure artifact and here you can see that I can use the BigConfig module with a complete different configuration.

bb.edn require the BigConfig module
Directorybb
- config.clj it provides a different configuration map to the BigConfig module

https://github.com/amiorin/dotfiles-v3/tree/babashka

Go faster

Imagine that you have to provision hundreds of user per machine. It will take too long but if every host becomes the combination of the user + the host then Ansible will provision these users in parallel because they look like different hosts.

A starry night sky.

Conclusion

Even in an age dominated by containers and cloud-native solutions, Ansible remains a crucial tool, not for what it once was, but for what it has become. Its core strength—its simplicity—makes it the ideal choice for a new, pervasive use case: provisioning remote development environments.

While Docker excels at application deployment, Ansible found its niche in ensuring developers have consistent, powerful, and reproducible workspaces. This solves the persistent problem of “it works on my machine” and significantly reduces time spent on setup and maintenance. It’s a fundamental shift in how we approach development, making it more efficient and collaborative.

However, Ansible’s YAML configuration language can be cumbersome. The need to manually manage multiple files becomes a bottleneck as environments grow in complexity. This is where a code-first approach, like the one offered by BigConfig, provides a powerful solution. By leveraging the fact that JSON is valid YAML, you can use a real programming language to dynamically generate configurations. This not only makes the process more flexible and less error-prone but also opens the door to treating environment provisioning as an API—a scalable, programmable service that can instantly onboard new team members.

In short, Ansible’s journey is a testament to its adaptability. It has evolved from a tool for provisioning data centers to the cornerstone of modern remote development. Paired with a tool like BigConfig, its simple, powerful core is unlocked, proving that some of the best tools aren’t those that are replaced, but those that find a new purpose.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.