proxmox as a homelab host

when i wrote up the ollama + n8n build, i promised the layers underneath would each get their own post. this is the first one: proxmox itself, the layer everything else in my homelab stands on. it’s the primer i wish i’d read before the first install — not a manual, but the handful of decisions that matter and the ones that don’t.

what proxmox is, in one paragraph

proxmox ve is a hypervisor: an operating system whose job is to run other operating systems. it’s debian underneath, with kvm for full virtual machines, lxc for containers, and a web ui that manages both. you install it on bare metal, browse to port 8006, and from that point on you stop thinking about the physical box and start thinking about guests. it’s open source and free; the paid subscription buys you the enterprise update channel and support, not features.

the mental shift is the point. before proxmox, my services lived directly on whatever machine they were installed on, and every experiment risked the machine. after proxmox, the machine is just capacity. services live in disposable guests, and pct destroy is the undo button the bare-metal world never had.

why tiny pcs and not a rack

my cluster is three lenovo thinkcentre m920q boxes — one with 32gb of ram, two with 16gb. the “tiny/mini/micro” class of ex-corporate 1-liter pcs is, for my money, the correct homelab hardware in 2026, and the reasoning is boring and domestic:

• power. each box idles around 10 watts. a retired rack server idles at ten times that, and in denmark you feel every watt on the bill. the homelab runs 24/7; idle draw is the cost.
• noise. they sit in my office. i can hear the birds outside, not the lab.
• price. off-lease corporate machines are everywhere. an 8th-gen i5 with 16gb costs less than a single new gpu fan tray.
• enough. home assistant, a backup server, dns, n8n, even cpu-only llm inference — none of it needs a xeon. the constraint you’ll actually hit is ram, which is why the one box that runs ai workloads got 32gb.

what you give up: no ipmi/remote management (vpro is fiddly), one nvme slot plus one sata bay, no ecc ram, and no room for a real gpu. i’ve decided i can live with all of it. if your homelab plans involve serious storage, this is the wrong shape — get something with drive bays and run zfs properly.

the install decisions that matter

the installer asks you a handful of questions, and only a few have consequences you’ll live with:

• filesystem. on a single-nvme box, i take the default lvm-thin over zfs. zfs is the better filesystem, but it wants ram (rule of thumb: 1gb per tb, plus headroom) and mirrors to shine, and on a 16gb machine that ram has better things to do. lvm-thin gives you snapshots and thin provisioning, which is what a homelab actually uses.
• hostname and static ip. decide these before installing, not after. renaming a proxmox node post-install is a documented-but-annoying procedure, and dhcp on a hypervisor is a footgun — every guest’s gateway to the world moves when the lease does.
• the management interface. pick the nic you’ll actually keep the box on. the installer builds a bridge (vmbr0) on it; every guest hangs off that bridge like a switch port.

everything else — timezone, keyboard, password — is changeable later without ceremony.

first boot, two chores. one: the web ui will greet you with a subscription nag, because a fresh install points at the enterprise repo you don’t have a key for. switch to the no-subscription repo (the ui has a repositories panel that does this with two clicks now; no more editing sources by hand) and run updates. two: while you’re in the shell anyway, check the microcode package for your cpu is installed. that’s the whole hardening story for a lan-only box behind a firewall.

lxc first, vm when forced

proxmox gives you two guest types, and the primer version of the difference: an lxc container shares the host kernel and costs almost nothing; a vm brings its own kernel and costs a fixed slice of ram and cpu just to exist. on 16gb boxes, that overhead decides things for you.

my rule so far: lxc by default, vm when the workload demands its own kernel. services like dns, caddy, n8n, ollama — all lxc, all light. home assistant os is the exception in my rack: it ships as an appliance image that wants to own a whole machine’s worth of kernel, so it runs as a vm.

the honest version of this trade-off — privileged vs unprivileged containers, bind mounts, docker-inside-lxc, and the cases where the shared kernel bites — is the next post in this series. for the primer, the rule of thumb carries you a long way.

helper scripts, and the throwaway habit

the proxmox community helper scripts are the single biggest quality-of-life improvement to this whole hobby. one curl command on the host, a few prompts, and you have a working lxc running the service of your choice. i covered the details (and the default ram cap that ate my first model run) in the ollama post.

the habit they enable matters more than the convenience: one service per container, and never repair what you can rebuild. if an experiment wrecks a container, pct destroy, re-run the script, restore the config, ninety seconds. containers stopped being pets the day rebuilding one became cheaper than diagnosing it. that’s the actual product proxmox sells a homelabber — cheap disposal.

the pct commands you’ll actually use

the web ui is good, but the shell is faster for the five things you do constantly:

pct list                          # what's running where
pct config <ctid>                 # the answer to most "why is it broken"
pct set <ctid> --memory 16384     # resize a guest — the ollama lesson
pct enter <ctid>                  # shell into a container, no ssh needed
pct destroy <ctid>                # the undo button

pct config deserves the highlight. when something inside a container fails with a resource error the host can’t explain — not enough memory, too many open files — the container’s cap is almost always the answer, and this is where you see it.

backups are a second box

proxmox has built-in backup jobs, and they’re fine. what i actually run is proxmox backup server on the second m920q: incremental, deduplicated, verified backups of every guest, on a schedule, to a different physical machine. the dedup matters more than it sounds — nightly backups of a dozen guests converge to surprisingly little disk, because most of every debian container is every other debian container.

restore is the feature. i’ve restored single containers after botched experiments and it’s a two-click, two-minute affair. a backup you haven’t restored from is a hope, not a backup — pbs makes testing that cheap enough that you actually do it.

what i’d tell past me

• buy the ram with the machine. 16gb feels roomy until the second llm model or the first vm.
• set static ips (or dhcp reservations) for guests from day one. the ollama post has the war story — workflows quietly break when a container’s lease moves.
• put the cluster on its own vlan early. it’s easier before there are ten guests with addresses you’ve memorized. the unifi side of that story is post three in this series.
• don’t cluster for the sake of the word. three nodes can form a proxmox cluster with quorum and live migration; mine don’t. the boxes have different jobs, nothing needs to float between them, and an unclustered node is one less failure mode to reason about. clustering is a tool for a problem i don’t have yet.

none of this is exotic, which is the recommendation. proxmox is boring in the way infrastructure should be boring: it does the same thing every day, and it makes experiments cheap enough that the interesting parts of the homelab happen a layer up. next in the series: lxc vs vm, properly — the shared-kernel trade-offs the rule of thumb glosses over.