Proxmox VMs and Containers

Proxmox gives you two guest types, and picking the right one per workload matters more than picking a side once and sticking with it.

QEMU/KVM VMs vs LXC containers

VMs (QEMU/KVM) - full hardware emulation, own kernel, own bootloader. Use when you need a different OS than the host (Windows, a BSD, a different Linux kernel version), when the workload needs strong isolation, or when it's a workload you might eventually migrate to different hardware/hypervisor and want maximum portability.
LXC containers - share the Proxmox host's kernel, start almost instantly, use noticeably less RAM/disk overhead than an equivalent VM. Use for most Linux-only services - this is where the majority of your Proxmox guests will live.

A common, sensible pattern: run Docker inside one or two LXC containers (or a VM, if you want stronger isolation from the host kernel) rather than running dozens of individual LXC containers, one per service. This mirrors your Beginner-tier setup but gives it a dedicated, isolated home instead of sharing the bare-metal host.

⚠️ Risk: Docker inside LXC needs the container configured as "unprivileged: no" (privileged) or specific nesting features enabled, because Docker itself wants to create its own namespaces and cgroups. Privileged LXC containers have a materially weaker isolation boundary against the host than unprivileged ones or a VM. If strong isolation matters for what you're running, put Docker in a VM instead.

Resource allocation: don't over-provision

This is the single most common homelab mistake once Proxmox is involved: assigning every guest 4 cores and 8GB "to be safe." Proxmox doesn't reserve physical cores per VM the way it might feel like it does - CPU is time-shared, but RAM assigned to a VM is generally unavailable to other guests while that VM is running (LXC containers are more flexible here since they share the host kernel).

Guidelines that hold up in practice:

Start small, scale up. 1-2 vCPUs and 1-2GB RAM is enough for most lightweight services (a reverse proxy, Pi-hole/AdGuard, a dashboard). You can increase later without reinstalling.
Check actual usage before assuming you need more. The Proxmox summary view shows real CPU/RAM usage per guest over time - use it, don't guess.
Leave headroom on the host. Don't allocate 100% of physical RAM across your guests; Proxmox itself, ZFS (if used - see Storage and ZFS), and buffer/cache need room too.
Cores: fewer than you think. Most single-service workloads barely use one core under normal load. Over-allocating cores doesn't make a guest faster if it isn't CPU-bound - it just reduces the scheduler's flexibility across all your guests.

Templates and cloning

Once you've built a VM or LXC container the way you like it (base OS, updates applied, your usual admin user, SSH configured), convert it to a template (right-click the guest > Convert to template) and clone from it for future guests instead of reinstalling from an ISO every time.

Full clone - an independent copy, uses its own disk space, fully decoupled from the template.
Linked clone - shares the template's base disk, only stores the differences. Faster to create and lighter on disk, but the template can't be deleted while linked clones depend on it.

For LXC, Proxmox's own container templates (downloadable via local storage > CT Templates > Templates, prebuilt minimal images of common distros from the Proxmox team) are a faster starting point than building your own from scratch, though building your own template once you have a standard setup saves more time long-term.

A sensible starting layout

A reasonable first split for a single Proxmox host:

One LXC container running Docker for your general services (the Beginner-tier stack, moved over)
One VM or LXC container dedicated to a reverse proxy (see Reverse Proxy and TLS)
Storage handled either by the host directly or a dedicated VM (see Storage and ZFS, next)

You don't need to design the perfect topology up front - guests are cheap to create, resize, and destroy. Get something working, then split further as specific reasons to isolate something come up.

Next: Storage and ZFS.