← Back to blog

Why Ansible became part of my workflow

Jan 1, 2026AutomationDevelopment

There are tools you learn because they’re useful, and there are tools that fundamentally change how you work. For me, Ansible clearly belongs to the second category.

I first came across Ansible while reading about infrastructure and automation. What immediately caught my attention was the idea that entire workflows and environments could be defined in code. No more setting up the same server over and over again, hoping you didn’t forget a step, or maintaining fragile scripts for every new setup. Just one source of truth that produces the same result every time.

That idea stuck with me.


From manual work to repeatable setups

I work a lot with VPS instances and servers. Before Ansible, spinning up a new server meant going through the same routine every single time: log in, run updates, secure the server, create users, install tools, tweak the shell, double-check everything.

Sometimes I did this manually, sometimes with small custom scripts. It worked — but every server ended up being slightly different. And the more servers you manage, the more those differences start to matter.

When I decided to properly learn Ansible, I intentionally started small. No complex playbooks, no abstractions — just empty servers. The goal was simple: could I take a fresh VPS and turn it into a fully configured server with a single command?

That moment was a real eye-opener.


What changed when I started using Ansible

With Ansible, you stop describing actions and start describing outcomes. A server should be secured, should have certain packages installed, and should be configured in a consistent way.

Things I used to do “quickly by hand” became part of a repeatable process, such as:

  • automatically running system updates and upgrades
  • configuring ssh, users, and firewall rules
  • installing standard tools and dependencies
  • setting up a consistent cli environment, including powerlevel10k

The result wasn’t just saving time — it was peace of mind. A new server no longer felt like work, but like a predictable, repeatable step.


Real-world scenarios where Ansible helps me

What really makes Ansible valuable for me is how it fits into daily work.

Spinning up a new server in minutes

Instead of manually configuring a server, I can now provision a new VPS using a single playbook. Security, users, updates, and base tooling are all handled consistently. No mental checklist, no forgotten steps.

Consistent environments across projects

I often work on multiple projects at the same time. Ansible allows me to ensure that staging, production, and test environments all share the same foundation. That consistency reduces surprises and makes debugging much easier.

Stress-free deployments

Rather than deploying code manually or relying on fragile scripts, I use Ansible to make deployments predictable. I know exactly what will happen, in what order, and with what result.

Installing and updating my own tools

I regularly build my own tools and cli utilities. With Ansible, I can install and update them automatically across servers, without manual intervention or version drift.

A foundation for SaaS projects

Even for my own SaaS services, Ansible forms the backbone. From preparing servers to configuring services, everything is defined and repeatable. That gives confidence when scaling or rebuilding environments.


What Ansible is — and why it helps developers

At its core, Ansible is an automation tool that lets you describe infrastructure, configuration, and workflows as code. You define how a system should look, and Ansible makes sure it ends up in that state — every time.

For developers, this means:

  • less manual work
  • fewer mistakes
  • faster setups
  • better insight into your own infrastructure

Ansible isn’t magic, and it doesn’t replace understanding. In fact, it forces you to understand what you’re automating. That’s exactly why it’s such a powerful learning tool for infrastructure, security, and deployments.


More than just a tool

What Ansible ultimately gave me goes beyond automation. It changed how I think about systems. I now approach servers, deployments, and infrastructure in terms of repeatability and predictability.

Problems feel less chaotic when you know they can be described, tested, and reproduced. Ansible isn’t just a “devops tool” for me — it’s an extension of how I build things: structured, repeatable, and with as little noise as possible.

And honestly, once you start working this way, it’s hard to go back.