Ansible Galaxy: I Learned Server Automation for a Server I Didn't Own

The Clickly Kubernetes Spiral, Continued

It was 2023. I was still deep in the Bitly-clone rabbit hole. I called it Clickly. It had zero users. Zero.

And somehow, through a series of increasingly deranged decisions, I had decided my zero-user redirect service needed a Kubernetes cluster. (I already confessed to that one — the whole K8s post is here, go ahead and laugh.) The next logical step, according to my broken engineer brain, was configuration management. You don’t just spin up a cluster, obviously. You configure the machines. You harden SSH. You set the right package repos. You drop in the nginx config. You restart the right services. Same way, every time, on every box. Forever.

That’s when I found Ansible. And then Ansible Galaxy — galaxy.ansible.com, a whole public registry of pre-built server automation, free for the taking. I remember scrolling through it at 2 AM, genuinely thrilled. Roles for PostgreSQL. Roles for Docker. Roles for hardening SSH. Thousands of them. Someone had already done all the work. I just had to pull it in.

And then I remembered: I owned exactly one server. A $5 DigitalOcean droplet running a redirect service nobody used. I got very, very excited about a problem I did not have.

Here’s the thing I need to save you from. Galaxy is genuinely good — one of the nicer package ecosystems in DevOps. It deserves to be understood. But it solves a problem (configuring fleets of servers) that a solo founder on Vercel and Neon almost certainly doesn’t have. So here’s the honest version: what Galaxy is, how it works, and — like I did with Terraform import — a pretty strong argument for why you don’t need it. Yet.

---

Ansible in Two Minutes (So Galaxy Makes Sense)

You can’t jump straight to “Ansible Galaxy is like npm for servers” without the two-minute Ansible primer, because half the confusion is just vocabulary. Here’s the short version.

Ansible is a configuration management tool. It’s a Red Hat project — they bought it in 2015 for around $126 million, and Red Hat itself is now an IBM subsidiary ($34 billion deal, 2019). So the thing you pip install traces all the way up to Big Blue. Doesn’t change your day.

The idea is dead simple. Instead of SSH-ing into a server and typing commands you’ll forget by Tuesday, you write down the end state in YAML — “nginx installed,” “this config file present,” “this service running” — and Ansible connects over SSH and makes reality match. (This is the configuration half of infrastructure; Terraform does the provisioning half — I untangle the two in Ansible vs Terraform.) It’s idempotent. Run it once or a hundred times, result is the same. That’s the one fancy word worth knowing.

This is not Terraform. People mix them up constantly. Terraform provisions VMs, load balancers, DNS records — it builds the empty house. Ansible configures what’s already running — it furnishes the house. Both are infrastructure-as-code, but they sit at different layers. Plenty of teams use both.

Now the natural question: if everyone’s writing YAML to install nginx and harden SSH, nobody wants to write the same YAML from scratch. Correct. That’s why Galaxy exists.

---

Roles, Collections, and Why I Didn’t Need Either

Ansible Galaxy is the free, public community hub for sharing Ansible content. It’s at galaxy.ansible.com, the ansible-galaxy CLI talks to it by default, and anyone with a GitHub account can publish. Think npm for server automation. Minus the left-pad drama. Mostly.

What you pull comes in two shapes. That’s it. Two.

A role is a reusable bundle of automation for one job. Fixed folder layout — tasks/, handlers/, templates/, defaults/, vars/, meta/. Everything needed to say “set up a production PostgreSQL server.” You reference it in your playbook with a couple lines instead of copy-pasting a hundred.

The most famous roles on Galaxy are Jeff Geerling’s. His geerlingguy.docker and geerlingguy.nginx roles have been installed millions of times. If you’re learning Ansible, reading his code is unironically one of the best ways to do it — the guy comments like a human being, explains why a task exists instead of just what it does, and doesn’t do weird abstraction for abstraction’s sake. I spent a whole weekend going through his Docker role file by file, and I understood more from those couple hundred lines of YAML than from a dozen tutorials.

A collection is the bigger container. It bundles multiple roles plus modules, plugins, and documentation. All versioned, shipped as one unit — community.general, community.postgresql, that sort of thing. Collections exist because roles alone couldn’t cleanly carry custom modules and plugins. The modern pattern: ship roles inside collections. Package webserver, load_balancer, and monitoring_agent together, version them, and push.

If you’re starting fresh in 2026, you’ll mostly consume collections. Standalone roles still work, they’re just the older shape.

Role = one reusable job. Collection = a versioned package of roles and code. Everything else is detail.

---

If You Actually Need to Pull From Galaxy

Say you genuinely have servers and want community content. The CLI is the same tool you use to install Ansible collections and roles.

Install a single collection:

ansible-galaxy collection install community.postgresql

Install a standalone role (old way):

ansible-galaxy role install geerlingguy.docker

Nobody sane does either by hand for a real project. You do what you’d do with package.json or requirements.txt: pin everything in a file and install from it. That file is requirements.yml, and it holds both shapes:

roles:
  - name: geerlingguy.docker
    version: "7.4.1"

collections:
  - name: community.postgresql
    version: ">=3.0.0"
  - name: community.general

Then one command:

ansible-galaxy install -r requirements.yml

Two gotchas the tutorials skip. First: by default, roles land in ~/.ansible/roles or /usr/share/ansible/roles or /etc/ansible/roles — whichever Ansible finds first. Where they actually end up depends on your machine. Surprise. You override with roles_path in ansible.cfg or the ANSIBLE_ROLES_PATH env var.

Second: pin your versions. Galaxy is an open free-for-all. An unpinned collection can change under you and quietly break a playbook you haven’t touched in months. version: in requirements.yml is not optional if you like sleep.

I learned this the hard way, obviously. I had a small playbook for my one DigitalOcean droplet that pulled community.general unpinned. Went to run it six weeks later after ignoring the project — and nothing worked. Some module signature had changed. Took me 45 minutes of diffing changelogs to figure out what broke, all for a server with zero users. Pin your versions. You do not need the drama.

---

Galaxy vs Automation Hub: Free-for-All vs the Certified Aisle

Galaxy has a paid enterprise sibling: Ansible Automation Hub. It’s part of a Red Hat Ansible Automation Platform subscription. (I broke down that whole suite — the old “Ansible Tower” rebranded — in the AAP guide, and why a solo founder needs exactly none of it.)

The difference is trust. Galaxy is the community marketplace — huge, free, and, to paraphrase Red Hat’s own framing, an app store with no rules. Anyone publishes. No promise a collection is maintained, secure, or functional. No built-in way to know if code was tampered with. That’s the price of “free and everything’s here.”

Automation Hub is the curated grocery store. Content goes through Red Hat’s certification and testing pipeline. You get collections from Red Hat and certified partners with actual support behind them. There’s also Private Automation Hub — companies host their own vetted, on-prem registry so they control exactly what their team can pull.

For a bootstrapper: you will never touch Automation Hub. It’s a line item on an enterprise contract for teams that need audited, supported automation. Galaxy is the free thing you’d actually use — if you used any of this at all.

---

You Probably Have Zero Servers

Let me ask the honest first question instead of “how do I use Galaxy.” How many servers do you actually run?

If your stack is Vercel for the frontend, Railway or Fly.io for the backend, and Neon for Postgres — the answer is zero. None. Zip.

You don’t SSH into anything. You don’t install nginx. You don’t manage systemd units. You don’t harden an OS. Those platforms took the entire server — the exact thing Ansible exists to configure — and hid it behind a git push. There is no box to bring into a described state. You never touch a box. Ansible would be a tool solving a problem your platform already deleted for you.

Ansible earns its keep the moment you have real machines you’re responsible for. A fleet of VMs on a cloud. A dozen boxes that all need identical setup and must stay identical as they drift. A team that needs server config in pull requests instead of living in one person’s shell history. That’s a fine problem to have — it usually means real scale, real revenue. It is not a $0 MRR problem, and it’s a different universe from deploying to one of the cheap platforms I use every day.

I reached for Ansible in 2023 for the same broken reason I reached for Kubernetes and later Terraform: I’d manufactured a fleet in my head to justify learning the fleet tool. I had one small redirect service that belonged on a $5 box, and instead I went looking for the “correct” way to configure a server farm I would never own. Classic Broken Engineer move. The learning was real and I don’t regret it — I can read a role now and know exactly what it’s doing. But if I’d just shipped Clickly to Railway like a sane person, there’d have been nothing to configure.

So here’s the honest decision tree. If you manage actual servers — plural, by hand, and you’re scared of them drifting apart — learn Ansible. Pull vetted roles from Galaxy. Pin your versions. Enjoy one of the genuinely good ecosystems in DevOps.

If you’re a solo founder with a Vercel deploy and a Neon database and a dream? Bookmark this and go build. The day you’re SSH-ing into your fifth server at 1 AM, come back. Galaxy isn’t going anywhere.

---

The Tool I Didn’t Need

Ansible Galaxy is a package registry for server automation. The npm of the Ansible world. Roles are reusable bundles for one job; collections are versioned packages of roles plus modules and plugins. You pull from it with ansible-galaxy install -r requirements.yml, you pin your versions because it’s a free-for-all, and its enterprise cousin Automation Hub is a thing you’ll happily never pay for. It’s not the only game — Chef, Puppet, and Salt play in the same sandbox. But Ansible is where new projects land in 2026, so it’s the one worth knowing.

But the real lesson isn’t the command. It’s the layer. Configuration management sits below your product, on machines you own and operate. Managed platforms exist so you don’t have to live at that layer until you’ve earned the right to. The best server-config code is the code you never wrote because Vercel and Railway wrote it for you.

I spent weeks in 2023 learning Ansible, Galaxy, roles, collections, and the CLI — time I could have spent getting a single actual user for Clickly. The tools were great. The problem they solved was not mine. Ansible is what you graduate to when the magic boxes run out — not the thing you pick up to feel like a real engineer. I picked it up to feel like a real engineer. Don’t be me.

This is the Broken Engineer Guide. I over-engineer everything, fail at business, and share the scars so you can skip a few. Go build something that doesn’t have a server to configure yet.