Proxmox

Proxmox turns one physical computer into many separate machines, each with its own operating system, memory and CPU. For a homelab, that means a web server, a database and a sandbox for risky experiments, all on the hardware you already own.

What Proxmox is

Proxmox Virtual Environment (Proxmox VE) is a free, open-source virtualisation platform. You install it straight onto a computer's disk, in place of Windows or a desktop Linux, and that computer becomes a host: a machine whose job is to run other machines.

Under the hood it is Debian Linux with two virtualisation technologies built in:

• KVM (Kernel-based Virtual Machine), with QEMU, for full virtual machines.
• LXC (Linux Containers) for lightweight system containers.

On top of those sits a web interface. After installing, you open https://<host-ip>:8006 in a browser on another device and manage everything from there: create machines, start and stop them, watch their CPU and memory, open a console, take snapshots and schedule backups. There is no separate management tool to install, and everything the web interface does can also be done from the host's shell.

Proxmox is released under the GNU AGPL v3. The software is free to use with every feature; the paid subscription buys access to the more heavily tested enterprise update repository and to support.

Why one big machine beats several small ones

A home server spends much of its time idle. A database waiting for queries, a web server handling a handful of visitors and a test box you touch once a week each use a small share of a modern CPU. Buying a separate computer for each means paying for, powering and cooling three boxes that mostly wait.

Virtualisation shares one machine's resources between all of them. Each guest gets its slice of CPU cores, RAM and disk, and the host schedules the real hardware between them. You get more machines on the same hardware, and adding another one takes minutes instead of a shopping trip.

Virtual machines: a whole computer in software

A virtual machine (VM) is a complete computer simulated in software. It has its own virtual CPU, memory, disk and network card, and it boots its own operating system with its own kernel. That operating system doesn't need to know it is virtual.

This gives a VM two big strengths:

• Any operating system: a VM can run Windows, any Linux distribution or BSD, because it brings its own kernel.
• Strong isolation: a crash, a broken update or a misconfigured firewall inside one VM stays inside it. The host and the other guests keep running.

KVM uses your CPU's hardware virtualisation features (Intel VT-x or AMD-V), so guest code runs at close to native speed. Check that they are switched on in the BIOS or UEFI before installing: without them, VMs either won't start or run very slowly.

The cost is overhead. Every VM boots a full operating system and keeps its own kernel in memory, so each one needs more RAM and disk than the app inside it does.

Containers: lighter boxes that share the kernel

A Proxmox container is an LXC system container. It looks like a small Linux machine from the inside, with its own users, processes, network address and file system, but it shares the host's Linux kernel instead of booting its own.

That makes containers:

• Light: with no second kernel, they need less memory and start in seconds.
• Linux only: sharing the host's kernel means a container can only run Linux.
• Less isolated than a VM: a problem in the shared kernel can affect every container on the host.

These are not Docker containers. Docker runs one application per container, packaged as an image; an LXC container behaves more like a whole lightweight Linux server you log into and manage. To run Docker, the usual answer is a Proxmox VM with Docker installed inside it, and the Proxmox documentation recommends that setup for app containers when you need live migration or orchestration.

Here is how the two kinds of guest sit on one host:

Which one to pick

A good default: a container for a simple Linux service such as a database, a DNS blocker or a file share, and a VM for anything that needs another operating system, a custom kernel, or stronger separation from everything else.

A worked example: one mini PC, three machines

Say you have a mini PC with 8 CPU cores, 32 GB of RAM and a 1 TB SSD, and you want the setup from the video: a server, a database and a place for experiments.

1. Install Proxmox VE from a USB stick and give the host a fixed IP address on your network, say 192.168.1.50.
2. From your laptop, open https://192.168.1.50:8006 and log in as root. Your browser will warn about the certificate: Proxmox uses a self-signed one by default.
3. Create a VM for the web server: 2 cores, 4 GB RAM, 40 GB disk, running Ubuntu Server.
4. Create a container for the database: 2 cores, 4 GB RAM, 30 GB disk, from a Debian template, then install PostgreSQL inside it.
5. Create a second VM for experiments: 2 cores, 8 GB RAM, 60 GB disk.

That uses 16 GB of RAM and leaves the rest for the host and for growth. Don't hand every gigabyte to guests: the host needs memory of its own, and storage such as ZFS uses spare RAM as a cache.

Before you try something risky in the experiments VM, take a snapshot. In the web interface that is the VM's Snapshots tab; from the host's shell it is:

qm list
qm snapshot 102 before-upgrade
# ...try the risky change...
qm rollback 102 before-upgrade

qm manages VMs, and every guest has a numeric ID (102 here). Containers have the same commands under pct, such as pct snapshot. If the experiment breaks the VM, the rollback puts it back exactly as it was, while the web server and the database keep running untouched.

Common mistakes

• Treating snapshots as backups: a snapshot lives on the same disk as the VM. If that disk dies, the snapshot dies with it. Use the built-in backup tool (vzdump, or a scheduled job in the web interface) to a different disk or machine, or run Proxmox Backup Server.
• Forgetting the host is a single point of failure: one VM breaking leaves the others running, but a failed power supply or SSD takes every guest down at once. Proxmox can cluster several hosts and move guests between them; a single host has no such fallback.
• Giving away all the RAM: leave headroom for the host. When it runs out of memory, the Linux out-of-memory killer can stop a running guest.
• Exposing port 8006 to the internet: the web interface controls every machine you own. Keep it on your home network, or reach it over a VPN.
• Leaving the enterprise repository on without a subscription: a fresh install points at the enterprise update repository, and updates fail without a key. Switch to the free pve-no-subscription repository instead.

When Proxmox fits, and when it doesn't

Proxmox earns its place when you want several separate machines on one computer: a homelab, self-hosted services, a test lab for learning Linux or networking, or a small office server. It also scales up, with clustering, shared storage and live migration for teams that run their own hardware.

It is more than you need if you only want to run a couple of apps. A single Linux install with Docker, or a self-hosting platform such as Coolify, is simpler. And it needs a machine you can dedicate to it, since it replaces the operating system rather than running alongside it. Setting it up means learning some networking and storage, and finding your way around a busy interface. A beginner can do it with patience and the official docs open.

Key takeaways

• Proxmox VE installs on bare metal and turns one computer into many virtual machines and containers.
• A VM brings its own kernel and OS, so it can run anything and isolates well, at the cost of more RAM.
• An LXC container shares the host's kernel: lighter and faster, but Linux only.
• Everything is managed from one web interface on port 8006, or from the shell with qm and pct.
• Snapshots make experiments safe to undo, but only backups on another disk protect you from hardware failure.