stayz3ro.dev

Moving services off my workstation and into Proxmox

proxmox · docker · homelab · virtualization · backups repo ↗

The monitoring stack and a few other services started life on my gaming PC, in Docker. That’s fine for testing and bad for anything you want to rely on, because the machine reboots, gets shut down, and generally isn’t infrastructure.

This phase moved those services onto a Proxmox host, so they run independently of any workstation.

The layout on Proxmox

Proxmox runs on a dedicated machine. On it:

  • an LXC for the Omada Controller (the managed-network project needs it)
  • a VM running the Docker monitoring stack
  • a VM for a self-hosted RustDesk server
  • HDD-backed storage for backups

Proxmox: the docker-services VM summary, running, 2 vCPU and 4 GiB RAM, with the Omada Controller LXC and storage visible in the node tree

The monitoring stack came over as-is. Same Compose files, now on a VM that stays up.

The "DNS & Failover" Grafana dashboard, now served from the Docker VM on Proxmox rather than the workstation

Once it was confirmed working on the VM, Docker on the gaming PC was stopped for good.

Terminal on the gaming PC: docker compose ps and docker ps both returning an I/O error because the Docker service is disabled

RustDesk, kept LAN-only

The RustDesk server (its hbbs and hbbr components) went on its own VM. I kept it LAN-only on purpose. It’s useful for remote-desktop access to machines on the network, but it doesn’t need to be public to do that, and UFW enforces it.

ufw status verbose on the RustDesk server: the RustDesk ports (21115-21117) allowed only from the local subnet (redacted), everything else denied

Not every useful service needs to be reachable from the internet. Internal-only is a valid answer.

Backups

Moving to Proxmox isn’t worth much without backups, so the VMs and the LXC get scheduled vzdump backups to the HDD storage, and I confirmed they actually run and produce restorable archives.

Proxmox backups list: dated vzdump archives for the docker-services VM and the omada-controller LXC on the HDD storage

What this phase gave the lab

  • services that survive a workstation reboot
  • clear separation between infrastructure and general-purpose machines
  • a place to add the Omada Controller the managed-network work needs
  • validated backups, so a failed VM is a restore, not a rebuild

A later hardening pass tightened the VM baselines (SSH, log rotation, Prometheus retention, disk sizing) and added a Portainer agent for Docker visibility. But the core move, off the workstation and onto real infrastructure, happened here. The next project took the same build-then-validate approach to the network itself, replacing the mesh router with managed routing and switching.