Why we build it this way

This guide installs Proxmox by hand on a clean Debian base, on a bare-metal dedicated server. A few of those choices are worth saying out loud, because the alternatives are tempting and usually wrong here.

• Why a dedicated root server, not managed virtualisation? You get real bare metal — full CPU, real disks, nested virtualisation, IOMMU for passthrough — at a flat monthly price, and you own the whole stack. The tradeoff is that you are now responsible for the OS, the network, and the security. This whole lab is built on accepting that tradeoff deliberately.
• Why Debian first, then Proxmox on top? The provider hands you a Debian install (via the rescue system + installimage), and Proxmox VE is itself built on Debian. Installing the Proxmox repo onto a clean, matching Debian base gives you a node that's supportable and predictable — rather than fighting whatever was pre-imaged.
• Why fuss over the network bridge? Because a dedicated server's public networking is not a home LAN. The upstream only forwards traffic for MAC addresses it knows, so the bridge has to be set up with that in mind. (Getting VMs onto public IPs is a big enough topic that it has its own book.)
• Why harden before doing anything else? The box has a public IP and an open SSH port from its first boot. On the public internet that port is being probed within minutes. UFW + fail2ban aren't optional polish; they're day-zero.
• Why the tuning (governor, I/O scheduler, IOMMU, sysctl)? Defaults are written for "a generic Linux server." A virtualisation host wants the performance CPU governor, an I/O scheduler that suits its disks, IOMMU on for passthrough, and a few sysctl adjustments. Small settings, real difference under load.

The mindset: owning bare metal is a power-and-responsibility trade. You get everything; you also have to do everything — securely, from minute one. Build the node clean, lock it down before it's interesting to attackers, and tune it for the job it'll actually do.