← Back to novovictus

Home Assistant on Proxmox with Tailscale Site Access

A side quest migration from mixed Home Assistant hosts to x86_64 Proxmox nodes, with private site access, static infrastructure roles, and Zigbee coordinator continuity.

x86_64 Proxmox node
├── LXC: Tailscale site router
└── VM: Home Assistant OS
    └── USB passthrough: Zigbee coordinator

Build Context

The home deployment started as a Windows laptop running Home Assistant through Oracle VirtualBox. The shop deployment started as a Raspberry Pi. Both worked, but neither was the operating pattern I wanted to keep extending.

The migration goal was not to build an enterprise lab. The goal was to make the automation stack easier to recover, easier to reach remotely, and less dependent on fragile host-specific installs.

Hardware model details are intentionally omitted. The specific boxes are not the useful part of the work, and publishing model-level infrastructure details exposes more than it explains.

Design Goals

• Keep Home Assistant OS as the supported appliance layer.
• Move both sites to x86_64 Proxmox-backed hosts.
• Keep Tailscale routing outside Home Assistant.
• Avoid exposing Home Assistant directly to the internet.
• Use predictable addresses for infrastructure roles.
• Preserve Zigbee networks without re-pairing devices.
• Stage the cutovers with rollback points instead of improvising live.

Home Migration

The home site moved from the Windows laptop and Oracle VirtualBox arrangement to a Proxmox-backed Home Assistant OS VM. The Zigbee coordinator was moved to the new host and passed through to the VM.

Shop Migration

The shop site moved from a Raspberry Pi to a second Proxmox-backed Home Assistant OS VM. This cutover was staged more carefully because the Pi was the active production controller.

1. Build the Home Assistant OS VM.
2. Prevent the VM from auto-starting.
3. Boot the VM with the network disconnected.
4. Assign the static address from the Home Assistant console.
5. Snapshot the staged VM.
6. Temporarily bring the VM online to update and validate.
7. Take a fresh full backup from the Pi.
8. Shut down the Pi.
9. Bring the Proxmox VM online.
10. Restore the fresh backup into the VM.
11. Move the Zigbee coordinator to the Proxmox host.
12. Pass the Zigbee coordinator through to the Home Assistant VM.
13. Validate that devices begin reporting without re-pairing.

Tailscale Routing

Tailscale became the private access layer for each site, but the useful design choice was keeping it separate from Home Assistant itself.

Proxmox host:
  break-glass management path

Tailscale LXC:
  subnet routing
  optional exit-node behavior

Home Assistant VM:
  automation platform only

During setup, routing issues reinforced the importance of giving the site-router container a stable LAN identity. A subnet router that loses its local address can look like a Tailscale problem even when the root cause is local network state.

Addressing Strategy

Exact addresses are omitted, but the role pattern is preserved:

router / gateway
Proxmox host
Tailscale container
Home Assistant VM

Each infrastructure role gets a predictable address. That makes recovery, routing, and troubleshooting easier, especially when working remotely.

For the staged cutover, the new Home Assistant VM was configured before it was allowed onto the network. That avoided collision with the still-running production host.

Zigbee Coordinator Migration

Both migrations included moving a Zigbee coordinator from the old host to the new Proxmox-backed Home Assistant VM.

The important object is the coordinator and the restored Home Assistant state, not the old host. Once the coordinator was attached to the restored VM, devices began reporting without being re-paired.

USB serial identity was checked on the Proxmox host before passthrough. The VM then received the coordinator through Proxmox USB passthrough, and Home Assistant resumed control through the restored Zigbee integration.

Snapshots and Rollback

Snapshots were used as temporary rollback points during staging and cutover. They were not treated as backups.

Useful checkpoints:
- clean VM before first boot
- static addressing staged
- updated VM before final restore
- post-cutover with Zigbee reporting

After the migration is stable, old staging snapshots should be removed to reduce thin-provisioning exposure.

Lessons

Separate access from automation

Tailscale should not depend on Home Assistant when Home Assistant is the thing being migrated, restored, or debugged.

Static infrastructure roles reduce ambiguity

Predictable addresses for the Proxmox host, Tailscale container, and Home Assistant VM made staged migration and remote recovery cleaner.

VM network edits can change MAC addresses

When modifying a Proxmox VM network definition, preserving the existing MAC matters if reservations or rules depend on it.

Stopped is not the same as safe

A powered-off VM can still auto-start later. During staging, the VM needed to be stopped, have auto-start disabled, and have its virtual network link disconnected.

Zigbee continuity depends on the coordinator

Moving the coordinator and restoring the Home Assistant backup preserved the Zigbee network. Re-pairing devices was not required.

Why This Was Worth Logging

This was not a flashy build, but it had enough real engineering content to preserve: host migration, backup and restore discipline, Tailscale routing, static addressing, USB passthrough, staged cutover, and Zigbee continuity.

It is exactly the kind of side quest that seems small until it has to be done again from memory.

GitHub: github.com/novovictus
Contact: contact@ninja-neer.net