Home Lab: What Changed Since 1.0.0

Posted on in Automation

This is a quick tour of what changed in the home-lab repository since 1.0.0, with enough context to decide what to adopt and what to skip. It focuses on real outcomes rather than a changelog dump. The repository is here: https://github.com/joe-mccarthy/home-lab and the releases page shows the milestones at a glance.

From 1.0.0 to 1.1.0: photos, backups, and docs

The headline addition was a complete Immich deployment for self-hosted photos. It is packaged as a Swarm stack with templates, vault-driven configuration, and notes on storage. Immich uses the existing NFS share on the Pi 5 to avoid SD card wear and to keep large libraries off device storage. If you browse the tree you will find a deployments/immich folder and a new entry in deployments/README.md that explains the variables to set before bringing it up.

Backups also received attention. The NFS backup playbook is now imported by the standard deploy workflow so a normal rollout includes backup validation, not just services. Retention was tuned to keep daily and weekly restore points while trimming older monthlies to reduce long term space. These are small changes that tighten the loop when you are moving fast on a live cluster.

What this means in practice

  • If you want Immich, populate the vault values, confirm your NFS path, and deploy the stack as written. Start with a small album to validate performance on Pi hardware.
  • If you have not checked backups in a while, run a standard deploy and confirm the backup stack logs are healthy before touching anything else.

From 1.1.0 to 2.0.0: a Zigbee migration

Version 2.0.0 is the one to plan for. The lab moves from ZHA to Zigbee2MQTT and adds an MQTT broker alongside the Zigbee2MQTT container. The motivation was simpler integration and clearer logs across devices. This is a breaking change for Zigbee users and worth a short migration plan.

Notes before you roll it out

  • Confirm your coordinator path and baud in group vars.
  • Make sure the MQTT broker address and credentials are correct for your environment.
  • Review volumes for Zigbee2MQTT and Home Assistant so network keys and device data land on persistent storage.
  • Take a snapshot of your ZHA setup for reference; you will not be restoring it directly, but it helps to verify device lists and automations after the move.

A follow up change protects local edits by teaching Ansible not to overwrite existing Home Assistant and Zigbee2MQTT configuration directories on redeploy. That makes iterative tweaking safer on a live cluster where you might have hand-tuned YAML during testing.

What this means in practice

  • Schedule the migration during a calm window. Move a few devices first, verify events in MQTT, then proceed.
  • Expect shorter feedback loops. Device joins and logs are easier to reason about with Zigbee2MQTT, which helps when you are diagnosing range issues on a Pi-based cluster.

From 2.0.0 to 2.1.0: a tidier blog deployment

The blog stack picked up a small but helpful refinement. The image reference moved out of the compose template and into group vars or vault, and the replica count now matches reality at 1. If you host your own image or change registries, this removes a little friction. It also keeps secrets out of templates and in the same place as other service credentials.

What this means in practice

  • Set blog_image in group vars or vault, not in the compose file.
  • Redeploy to confirm the change; behaviour should be identical, but the configuration is cleaner.

Ongoing polish after 2.1.0

There are routine version bumps, for example the Immich server image pin moving to a newer stable tag in the template. Small image pins like this keep upgrades predictable on Raspberry Pi hardware without surprising the cluster on a busy day. The pattern is to update deliberately rather than auto-tracking latest across the board.

Practical upgrade path

If you want to move a running lab forward from 1.0.0 without drama:

  1. Backups first
    Run a normal deploy so the backup stack is included. Check logs for successful runs and test a small restore. This is your safety net if something misbehaves later.

  2. Bring in Immich
    Fill out the vault entries, verify NFS permissions, and deploy the stack. Import a small album to get a feel for performance before migrating more data.

  3. Plan the Zigbee shift
    Review coordinator and broker settings, then migrate a handful of devices. Confirm states in MQTT, check that Home Assistant sees what you expect, and only then move the rest. The “do not overwrite” safeguard should protect any local tweaks during redeploys.

  4. Tidy the blog
    Move the image configuration into group vars or vault and redeploy. This one is quick and reduces template churn later.

Why these changes hold up

The repository is opinionated about clarity over complexity. New stacks arrive with templates, variables, and notes. Risky shifts like the Zigbee migration come with guard rails so you do not lose local changes during a redeploy. Services that are easy to break receive conservative defaults and persistent volumes by default. None of this is flashy. It makes a Pi-based homelab predictable enough to trust day to day.

If you want to browse all details or jump to the diffs, start at the repository and the releases page:

Thanks for reading.

↤ Previous Post