Automating the Homelab with Ansible

What you'll build and why

Ansible describes your infrastructure's desired state in YAML playbooks and applies it over SSH -- no agent to install on managed hosts, and running the same playbook twice changes nothing the second time if the first run already succeeded (idempotence). This replaces "I think I ran that command on all four hosts" with a file you can read, version-control, and actually trust.

Don't build this if: you're managing one or two machines you rarely touch -- the setup overhead here pays off once you're repeating the same manual steps across multiple hosts, or want a real record of what state your infrastructure is supposed to be in.

How it works

  Your control machine (runs Ansible, nothing extra
needed on managed hosts beyond SSH + Python)
│
│  SSH, using your existing key-based auth
▼
inventory.ini  --  which hosts, grouped how
│
▼
playbook.yml  --  tasks applied to those hosts,
in order, idempotently
│
├──► Host A (VM)
├──► Host B (VM)
└──► Host C (bare metal)

Agentless is the key design choice: Ansible connects over plain SSH using credentials/keys you already have, runs Python-based modules remotely, and disconnects -- no persistent service running on managed hosts, no separate port to open, no agent to keep updated everywhere.

Before you start

Decision: SSH key auth, not passwords. This guide assumes you already have SSH key-based access to every host you'll manage -- if you're still using password auth, set up keys first (ssh-copy-id); Ansible works with either, but keys avoid being prompted repeatedly across many hosts and many tasks.

Steps

Step 1: Install Ansible on your control machine

$ pip install --user ansible

Or via your distribution's package manager, if it ships a reasonably current version -- check ansible --version after either method.

Step 2: Build your inventory

inventory.ini:

[homelab_servers]
proxmox-node1 ansible_host=<10.0.20.10>
truenas ansible_host=<10.0.20.11>
[docker_hosts]
docker-host1 ansible_host=<10.0.20.20>
[homelab_servers:vars]
ansible_user=<your-ssh-user>

Groups ([homelab_servers], [docker_hosts]) let you target playbooks at a subset of hosts, not just everything at once.

Step 3: Confirm connectivity

$ ansible all -i inventory.ini -m ping

Expected output: pong from every host, confirming SSH access and Python are both working before you try anything more complex.

Step 4: Write a first real playbook

update-and-install.yml -- a genuinely useful starting task: keep every host's packages current and a common toolset installed.

---
- name: Baseline updates and common packages
hosts: all
become: true
tasks:
- name: Update apt cache and upgrade packages
apt:
update_cache: true
upgrade: dist
when: ansible_facts['os_family'] == "Debian"
- name: Install common tools
apt:
name:
- curl
- htop
- vim
state: present
when: ansible_facts['os_family'] == "Debian"

Step 5: Run it

$ ansible-playbook -i inventory.ini update-and-install.yml

Expected output: a per-task, per-host summary (ok/changed/failed counts). Run it again immediately -- a correctly idempotent playbook should show changed=0 the second time, since nothing actually needs to change.

Verify it works

• ansible all -i inventory.ini -m ping returns pong from every host in your inventory
• The playbook run completes with no failed tasks
• Idempotence check: run the same playbook a second time immediately. changed=0 across all hosts confirms it's truly idempotent -- if it reports changes on a second identical run, something in the playbook isn't actually checking state before acting, and needs fixing before you trust it on more hosts
• Failure test: deliberately break connectivity to one host (stop its SSH service, or point the inventory at a wrong IP), rerun the playbook targeting all. Confirm Ansible reports that host as unreachable and continues with the others, rather than the whole run silently failing

Secure it

• SSH key management: the keys giving Ansible access to every managed host are collectively powerful -- protect your control machine accordingly, since compromising it means compromising everything in the inventory.
• become: true (privilege escalation): playbooks that use become run as root on managed hosts -- treat playbook content with the same scrutiny you'd give any script you're about to run as root, especially anything from outside sources.
• Secrets in playbooks: never commit real passwords/API keys/tokens into a playbook or inventory file directly -- Ansible Vault (built in) encrypts sensitive variables for safe version control; see Go further.
• Least privilege: where practical, use a dedicated automation user with only the access it actually needs, rather than your own full-admin SSH key, especially as the inventory grows.

Back it up and maintain it

What matters: your inventory and playbook files -- these are the actual definition of your infrastructure's intended state, and belong in git, not just on your laptop.

Update cadence: Ansible itself updates independently of the hosts it manages; update on your own schedule. Playbooks should be revisited whenever the software they configure changes meaningfully (a new package name, a changed config format).

What to monitor: nothing runs continuously by default -- Ansible only acts when you run it. If you later add scheduled runs (Go further), monitor those for unexpected failed or changed counts, which can indicate drift or a real problem.

Troubleshooting

Logs: Ansible's own run output is the primary diagnostic (-v, -vvv for increasing verbosity on a failing task).

Undo

Ansible doesn't maintain a rollback mechanism on its own -- undoing a playbook's effects means writing a playbook (or task) that reverses the specific change, the same as any other configuration management tool. Removing Ansible itself from your control machine (pip uninstall ansible) has no effect on the hosts it already configured.

Go further

• Ansible Vault (ansible-vault encrypt) for storing secrets (API tokens, passwords) safely within version-controlled playbooks
• Organize playbooks into roles as your inventory grows beyond a handful of hosts -- keeps related tasks/templates/variables together instead of one growing flat playbook
• Schedule playbook runs (a systemd timer or cron job on your control machine) for ongoing drift correction, once you trust a playbook's idempotence
• Pair this with the Proxmox templates + OpenTofu guide elsewhere in this section -- OpenTofu provisions the VM, Ansible configures what's inside it, a common combined pattern

Resources

Official documentation:

• Ansible documentation -- inventory, playbooks, and modules, verified this session
• Ansible Vault documentation

Source and releases:

• ansible/ansible releases

Community:

• Ansible community forum

Related DaemonPress projects:

• Managing a Homelab with Docker Compose, Portainer, and Watchtower
• Proxmox VE Command-Line Reference

Last verified: 2026-09-21, checked against official Ansible documentation.