# Infrastructure as Code: automating your home lab with Ansible A home lab with three services is a hobby; a home lab with twenty is a part-time job — unless you automate it. Infrastructure as Code turns the manual chores into a file you run, and turns disaster recovery from a weekend into a coffee break. Every home lab reaches the same tipping point. For a while, SSHing into each box to run updates and tweak configs is fine — even fun. Then you have a dozen machines and thirty services, you cannot remember which host you changed last Tuesday, and a reinstall means a lost weekend of clicking. The enterprise solved this problem years ago, and the solution scales down to your closet perfectly: **Infrastructure as Code.** ## 01 What IaC is, and why a home lab needs it **Infrastructure as Code** is the practice of managing and provisioning your infrastructure through machine-readable definition files, rather than by hand — the configuration of your systems lives in version-controlled code, and you apply that code to make reality match it.[1](#ref-1) For a home lab this changes everything: your setup stops being a fragile, undocumented state that lives only in your memory and the machines themselves, and becomes a repository you can read, review, back up, and re-run. The lab becomes *reproducible*. **Ansible** is the friendliest on-ramp to IaC. It is agentless — it manages machines over plain SSH, with nothing to install on the targets — and its instructions are written in readable YAML, so your automation doubles as documentation.[2](#ref-2) ## 02 Your first playbook: update every server at once The single most satisfying first win is updating every machine in your lab with one command. In Ansible, the units are an **inventory** (the list of your hosts) and a **playbook** (the YAML describing what should be true on them).[3](#ref-3) A playbook that patches every Debian/Ubuntu host in the lab is only a few lines: ``` --- - name: Update every server in the lab hosts: all become: true tasks: - name: Upgrade all apt packages ansible.builtin.apt: upgrade: dist update_cache: true ``` Run it with `ansible-playbook update-all.yml` and Ansible connects to every host in your inventory over SSH and applies the update — the chore that used to be a dozen manual logins becomes one command you can even put on a schedule.[3](#ref-3) ## 03 Docker Compose for services, Ansible for the host Ansible and **Docker Compose** are a natural pair, each doing the layer it is best at. Docker Compose describes a service and its dependencies declaratively in a single YAML file, so a whole application stack comes up with one `docker compose up`.[4](#ref-4) Ansible handles the layer *underneath* — preparing the host, installing Docker, laying down your Compose files, and starting the stacks — so the flow becomes: Ansible provisions the machine and delivers the Compose files; Compose runs the services. Your entire lab, from bare host to running apps, is now described in two kinds of readable YAML that live together in one Git repository. > The goal of Infrastructure as Code is that no important configuration exists only in your head or only on a disk. If it matters, it is in the repository — and if it is in the repository, losing the hardware costs you an afternoon, not a weekend. ## 04 Idempotence and the disaster-recovery payoff The property that makes this trustworthy is **idempotence**: a well-written Ansible playbook can be run over and over and only changes what is not already correct, so re-running it is always safe.[2](#ref-2) That is what turns your code into a reliable source of truth rather than a one-shot script. And it is where the real payoff lands. When a disk dies or you want to migrate to new hardware (see part four), disaster recovery stops being a frantic reconstruction from half-remembered steps: you install a fresh OS, point Ansible at the new machine, run your playbooks, restore your data from the 3-2-1 backup (part one), and the lab rebuilds itself to the exact state described in your repository. What was a lost weekend becomes a re-run. ## 05 Where OcxlyDev lands We treat our infrastructure — this site's build and verification harnesses included — as code, and we bring the same habit to the home lab because it pays off at every scale. Start tiny: put one playbook that updates all your servers into a Git repository, and feel the difference the first time you run it. Then move a service's setup into Ansible, then another, until the day a machine dies and you realise, with some relief, that you can rebuild it from a folder of YAML. That is the moment a home lab stops being a pile of pets you nurse and becomes a system you *declare* — the same lesson, learned in a closet, that runs the world's data centres. **About this piece.** This is part five of a five-part OcxlyDev field guide on building a modern home lab — the 10-layer stack, zero-trust networking, de-Googling with self-hosted apps, mini-PC hardware, and Infrastructure as Code with Ansible. Every load-bearing claim links to a primary or reputable source below; project names and hardware move quickly, so check the live page before quoting specifics. ## References 1. [Red Hat — "What is Infrastructure as Code (IaC)?": managing infrastructure through machine-readable definition files](https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac) 2. [Ansible Documentation — "Ansible concepts": agentless automation over SSH, described in YAML](https://docs.ansible.com/ansible/latest/getting_started/introduction.html) 3. [Ansible Documentation — "Intro to playbooks": inventories, playbooks, and running tasks across hosts](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html) 4. [Docker Documentation — "Docker Compose overview": defining and running multi-container applications from one YAML file](https://docs.docker.com/compose/)