Hybrid gaming PCs turned home servers need a safe host and VM boundary before Docker apps go 24/7

Running a gaming PC and a 24/7 home server on the same hardware is possible, but only if you decide up front which layer owns the host, the GPU, power management, and Docker. Getting that boundary wrong means your game sessions interrupt your services — or your services prevent clean shutdowns.

The problem with all-in-one boxes

Homelab forums are full of posts from people who have one powerful machine — often a desktop with a discrete GPU — and want to get maximum use out of it. The appeal is obvious: one box, one electricity bill, one set of hardware to maintain. The challenge is that gaming workloads and server workloads have opposing requirements.

Gaming needs low-latency GPU access, responsive power states, and the freedom to reboot when a driver update or game patch demands it. A 24/7 server needs stable uptime, predictable network addresses, and services that survive host reboots without manual intervention. These two goals are not incompatible, but they do not coexist automatically. You have to architect the boundary deliberately.

Recent homelab threads show a common pattern: someone installs bare-metal Linux thinking they will game natively and run Docker on the side, then discovers that Docker container restarts, network bridge conflicts, and manual service management collide with their gaming workflow. Others try Proxmox but find GPU passthrough blocked by their hardware, leaving them with a hypervisor they cannot fully use. Some land on Unraid hoping it handles everything, then realise that streaming to Moonlight clients across the house and running a Docker stack simultaneously puts unanticipated load on the same system.

Deciding which layer owns what

Before you install anything, answer these six questions on paper:

1. Who owns the host? If you want to game on bare metal, the host OS is your daily driver and Docker runs directly on it. If you want strict isolation, a Type-1 hypervisor like Proxmox owns the host and your gaming environment lives in a VM — but this requires GPU passthrough to work, which is not guaranteed on all hardware.

2. Who owns the GPU? GPU passthrough to a VM is the cleanest isolation but requires an IOMMU group that cooperates, a second GPU for the host (or iGPU), and VFIO configuration. Without those prerequisites, bare-metal gaming with Docker on the side is your realistic option.

3. Who owns power management? If your gaming PC suspends to save power overnight, your Docker containers go down with it. You need to decide whether the machine runs 24/7 or whether your services can tolerate scheduled downtime. Hybrid approaches — wake-on-LAN, suspend inhibitors for specific containers — are possible but add complexity.

4. Who owns the network? Docker's default bridge networking works fine in isolation, but gaming streaming protocols (Moonlight/Sunshine) and Docker port mappings can conflict. Decide early whether Docker services get a dedicated VLAN, use host networking, or sit behind a reverse proxy.

5. Who owns remote access? Moonlight for game streaming, SSH for administration, and a VPN for secure remote access are three different channels with different requirements. They should not share the same entry point.

6. Who owns recovery? If the host kernel panics or the Docker daemon crashes, how do services come back? docker restart unless-stopped handles the daemon case. Host crashes require BIOS auto-power-on or a watchdog. Know your recovery path before you deploy anything you care about.

Practical architectures that actually work

Once you have answered those six questions, a small number of architectures emerge as genuinely viable.

Bare-metal Linux host with rootful Docker. The host runs a desktop environment for gaming. Docker runs directly on the host as a separate concern. Services start on boot via docker compose up -d and a systemd service or --restart unless-stopped. The downside is that host reboots for kernel/driver updates require all containers to restart — which they do automatically if configured correctly. This is the lowest-friction setup if GPU passthrough is not available.

Proxmox host with GPU passthrough to a gaming VM. The hypervisor owns bare metal. A Windows or Linux gaming VM gets the dedicated GPU passed through. A separate Linux VM or LXC container runs the Docker stack and stays up regardless of what the gaming VM does. This is the cleanest isolation but requires hardware that cooperates with IOMMU grouping. Verify passthrough feasibility before committing to this path.

Unraid with a gaming VM and Docker. Unraid combines array storage, VM management, and a Docker UI. It is approachable for people who want a GUI but it is not a free choice — the licensing cost and the Unraid-specific conventions (dockers run as root by default, array spin-up affects latency) should factor into your decision. For the Moonlight streaming use case specifically, Sunshine needs to run inside the VM with GPU access, not at the Unraid host level.

Across all three architectures, a tool like ServerCompass is useful once services are running — it lets you see all your running services at a glance across containers, VMs, and hosts without SSH-ing into each one individually.

Setting up the Docker stack for 24/7 reliability

Regardless of which host architecture you choose, Docker services running 24/7 need a few non-optional configurations.

Restart policies. Every service in your compose file should have restart: unless-stopped (or always if you want it to come back even after a manual docker stop). Without this, a host reboot leaves your services down permanently until you SSH in.

Health checks. Add a healthcheck block to containers that serve traffic. Docker will restart unhealthy containers automatically, which handles most soft failures without manual intervention.

Named volumes over bind mounts for critical data. Bind mounts to host directories are convenient but they tie container data to host filesystem paths. Named volumes are slightly more portable and survive container recreation without path confusion.

Log limits. Docker's default JSON file logging driver has no rotation configured by default. A long-running container on a machine that also runs games (which generate their own logs and crash dumps) will eventually fill the disk. Add --log-opt max-size=10m --log-opt max-file=3 or set it globally in /etc/docker/daemon.json.

Reverse proxy for HTTP services. Running Traefik or Caddy as a reverse proxy means you expose one port (443) instead of one port per service. This simplifies firewall rules, enables HTTPS, and avoids port collisions with gaming streaming ports.

Checklist

• Confirm GPU passthrough is feasible on your hardware (IOMMU groups, second display output) before choosing a hypervisor architecture
• Choose one host architecture (bare-metal + Docker, Proxmox + VMs, Unraid) and stick to its conventions rather than mixing approaches
• Set restart: unless-stopped on every Docker service that must survive reboots
• Assign static IPs or DNS aliases to Docker services — do not rely on dynamic container IPs in your gaming streaming or VPN config
• Separate streaming ports (Moonlight/Sunshine) from Docker service ports at the firewall level
• Decide your power management policy before deploying: suspend-to-RAM and 24/7 services do not coexist without explicit inhibitors or scheduled wake
• Add log rotation to Docker daemon config to prevent disk fill on a machine that also runs games
• Use a dashboard like ServerCompass to monitor all running services without logging into each host individually