25 - Migrating Raspberry Pi homelab stack¶

Today I finished a small but important cleanup: migrating my Raspberry Pi services from a messy “everything lives inside the Bitwarden-Lite folder” setup into a proper homelab infrastructure repository layout.

Originally, I had installed Bitwarden Lite on my always-on Raspberry Pi (PoE powered), and then added Pi-hole inside the same directory. It worked, but it wasn’t sustainable. Everything was mixed together: Caddy reverse proxy config, Bitwarden config, Pi-hole state, and container volumes all lived in one place. That made it hard to reason about what belonged to what, and it would have been a nightmare to version-control safely.

The goal was simple:

keep Bitwarden and Pi-hole running exactly as before
preserve all existing data (vault + Pi-hole settings/blocklists)
reorganize into a clean structure suitable for GitHub
make it scalable for future services (Homepage, Uptime Kuma, Portainer, etc.)

The new structure¶

I created a new top-level directory:

~/homelab-infra/
stacks/{bitwarden,pihole}
scripts/

Bitwarden now lives in:

~/homelab-infra/stacks/bitwarden/
docker-compose.yml
Caddyfile
settings.env

Pi-hole now lives in:

~/homelab-infra/stacks/pihole/
docker-compose.yml
etc-pihole/

This is already a massive win: each service has its own stack folder, with its own compose file and its own persistent data directory.

What actually happened during the migration¶

The safest move was to take a backup first. I copied the original bitwarden-lite/ directory into a timestamped backup folder so nothing could be lost.

Then I moved the original stack into the new homelab-infra/stacks/ structure and renamed it to bitwarden/. After that, I created a fresh pihole/ folder and migrated Pi-hole’s persistent state directory (etc-pihole/) across using rsync. Pi-hole stores basically everything in that directory (custom DNS records, adlists, gravity.db, FTL DB, config backups), so keeping it intact meant no reconfiguration required.

The migration wasn’t totally frictionless. I hit a few Docker conflicts because old containers were still running and holding ports:

Bitwarden was already using port 8080
Pi-hole was already using the container name pihole

The fix was straightforward: stop and remove the old stack containers, then start the new ones from the new directory layout. After that, the services were running cleanly again.

Result¶

At the end of the day I now have:

a clean service layout under ~/homelab-infra/
Bitwarden and Pi-hole running as separate stacks
all previous Pi-hole state preserved
a foundation that is ready to become a public “homelab infra” Git repository

Next step: initialise Git, add sane .gitignore rules (especially for secrets and database files), and start treating the Pi like a real infrastructure repo.

Oh man this is so easy to set up new docker services on the pi.

I have ssh config set up so I just type "ssh pi" to do any work on it. Then to make a new one, I just add the folder and make a docker-compose file in there and past in the block.

Go to pihole, make a DNS record for it, then add a block in the caddy file.

I should make a SOP specifically for that and add it to knowledge base.