How to Migrate Your Homelab to Proxmox VE 9.1 in 2026: A Complete Guide

Pick the right hardware

Used Dell OptiPlex 7050 or 7060 Micro is the sweet spot — i5, 32 GB DDR4, and a 500 GB NVMe — for $150–$200 on the secondary market. It handles 5–10 VMs or 20+ containers comfortably and idles around 8–12 W.

If you're going bigger or expect to host AI workloads, build mini-ITX: a 16-core AMD or Intel CPU, 64+ GB ECC RAM, and two NVMe drives for a ZFS mirror. ECC is strongly recommended on anything you care about. The is self-hosting still worth it in 2026 breakdown covers the cost-benefit if you want the full numbers.

Two NVMe drives is the minimum for a real ZFS mirror — single-drive ZFS pools survive bit-rot but not drive failure.

Inventory your current services

Sit down with the old host and list everything:

• Every Docker Compose stack (path, services, image versions)
• Every named volume and host bind mount
• Every published port and reverse-proxy hostname
• Which services need GPU passthrough, raw block devices, or USB devices
• Which services are stateful (databases, vaultwarden, immich) vs stateless (proxies, exporters, dashboards)

This list drives migration order in step 6. The order matters more than people think.

Install Proxmox VE 9.1

Download the Proxmox VE 9.1-1 ISO (1.83 GB, released 19 November 2025) and write it to a USB stick (dd if=proxmox-ve_9.1-1.iso of=/dev/sdX bs=4M status=progress). Boot the target hardware.

In the installer:

• Pick ZFS RAID1 across both NVMe drives. Compression on, ashift 12.
• Set a strong root password and a real email for cluster alerts.
• Configure a static management IP — Proxmox is unhappy with DHCP changes after install.
• Finish, reboot, log in via the web UI on port 8006.

After first login, switch to the no-subscription repository (you don't need a paid sub for homelab use). The repo URL changed with the move to Debian Trixie:

echo "deb http://download.proxmox.com/debian/pve trixie pve-no-subscription" \
  > /etc/apt/sources.list.d/pve-install-repo.list
sed -i 's/^/#/' /etc/apt/sources.list.d/pve-enterprise.list
apt update && apt full-upgrade -y

Note: VE 9.1 is based on Debian 13 (Trixie) and ships Linux kernel 6.17.2 as the new stable default — alongside QEMU 10.1.2, ZFS 2.3.4, and LXC 6.0.5. The 8.4 LTS branch on Bookworm with kernel 6.8/6.14 is still supported, but new homelabs should start on 9.1 unless you have a specific compatibility reason not to.

Wire networking and storage

The default install gives you a Linux bridge vmbr0 on your physical NIC. Confirm your VMs and CTs will be on vmbr0 and that your router is happy seeing MAC addresses on that bridge.

If you have a managed switch, put Proxmox's management interface on a dedicated VLAN. Guest VMs go on a separate VLAN; the bridge can be tagged or you can create one bridge per VLAN.

For storage: the ZFS RAID1 the installer made is your rpool. Add datasets for VMs and CTs:

zfs create rpool/vmdata
zfs create rpool/ctdata

Add them as Proxmox storages in Datacenter → Storage. This separates Proxmox system files from guest data and makes future migrations cleaner.

Stand up a Docker host VM first

Don't try to convert every Compose stack to LXC on day one. Stand up a single Ubuntu 24.04 LTS VM on Proxmox to act as your Docker host:

• 4 vCPU, 8 GB RAM minimum, 100 GB disk on rpool/vmdata
• Bridge vmbr0
• If you need GPU passthrough for transcoding, configure VFIO and pass the GPU now — it's harder to add later

Install Docker on the VM, then rsync your Compose project directories and host volumes from the old box:

rsync -av --progress old-host:/srv/docker/ /srv/docker/
rsync -av --progress old-host:/var/lib/docker/volumes/ /var/lib/docker/volumes/

This gives you the shortest path to parity. Nothing else needs to change yet — your services are now running in a Docker host VM instead of on bare metal.

Migrate stateful services one at a time

Now decompose. For each stateful service:

1. Stop the service on the old host (docker compose down)
2. rsync its data directory to the Docker host VM on Proxmox
3. Bring it up there (docker compose up -d)
4. Verify functionality (login, recent data, integrations)
5. Update DNS / reverse proxy to point at the new VM
6. Leave the old host's copy stopped but in place for a week as your safety net

Order matters. Migrate in this sequence:

• Databases first (Postgres, MariaDB, Redis, MongoDB) — everything else depends on them
• App containers second (Vaultwarden, Immich, Nextcloud, Paperless)
• Auth services next (Authelia, Authentik) — break these and you can't log into anything
• Reverse proxy and ingress last (Traefik, Caddy, Nginx Proxy Manager)

Test your backups before you decommission the old host. Untested backups are a wish, not a recovery plan.

Use the new OCI-image LXC path for stateless services

VE 9.1 introduced the ability to create LXC containers directly from OCI images — the same image format Docker uses. For stateless services that don't need full Docker isolation, this lets you skip the Docker layer entirely and run them as native LXC:

• Pi-hole — DNS is too important to depend on a Docker host VM rebooting
• Unifi Network Controller — straight LXC is more stable than Docker
• Samba / NFS — kernel-level file sharing belongs closer to the host
• Tailscale — can be a single LXC that proxies for the whole subnet
• Reverse proxies, exporters, simple dashboards — pull the OCI image, deploy as LXC

Use the well-maintained Proxmox community helper scripts for one-line LXC provisioning. They handle the unprivileged-container setup and AppArmor profiles correctly.

Keep Docker for anything Docker does well: stateful apps with active development, anything published only as a container image with complex Compose orchestration, anything you want to upgrade with docker compose pull.

Set up automated backups

This is the step homelabs skip and regret.

Easiest path: install Proxmox Backup Server (PBS) on a second machine — even a Raspberry Pi 5 with an external USB SSD works for a homelab. PBS does deduplicated, encrypted, incremental backups of every VM and CT.

If you don't have a second machine, configure vzdump to NFS or S3 from the Datacenter → Backup tab. Schedule nightly snapshots of every VM and CT, and a weekly full to off-site (Backblaze B2, AWS S3 Deep Glacier).

Then — and this is the load-bearing part — restore one VM to a test target before you trust the schedule. Backups you haven't tested are not backups. Once a restore works, you can decommission the old homelab host with confidence.