If you are running a Proxmox home lab and reaching for a full virtual machine every time you want to host a lightweight service, you are likely over-engineering it. Linux Containers (LXC) offer a faster, leaner alternative that is particularly well-suited to running the kinds of self-hosted services that UK home lab enthusiasts love — Pi-hole for DNS-level ad blocking, Uptime Kuma for monitoring business services, and password managers like Vaultwarden. This guide walks you through everything you need to know to get an LXC container up and running on Proxmox, from downloading a template to connecting via SSH.
LXC Containers vs Full Virtual Machines
A full virtual machine (VM) runs its own kernel and emulates hardware. It is completely isolated from the host, which makes it excellent for running Windows, testing untrusted software, or running a different Linux kernel version. That isolation comes at a cost — VMs typically require 512 MB to 1 GB of RAM just to idle, take 30–60 seconds to boot, and consume more storage for the OS layer.
LXC containers share the host kernel. There is no hardware emulation layer. A container running Pi-hole can idle at under 50 MB of RAM and boot in two to three seconds. The trade-off is that all containers on a Proxmox node must be Linux-based and run against the same kernel version as the host.
Use a VM when you need Windows, a different kernel, full hardware isolation, or are running software you do not fully trust. Use an LXC container for lightweight Linux services: web servers, DNS resolvers, monitoring tools, reverse proxies, and small self-hosted applications.
Privileged vs Unprivileged Containers
Proxmox offers two container modes. A privileged container runs as root on the host kernel — it is easier to set up but carries higher security risk if the container is compromised. An unprivileged container maps the container’s root user to an unprivileged user on the host using kernel namespaces. This is the recommended default for almost every use case. When in doubt, leave the “Unprivileged container” checkbox ticked during creation.
Downloading a Container Template
Before you can create a container, Proxmox needs a template to build from. In the Proxmox web UI, navigate to your storage node (typically local), select CT Templates from the left panel, then click the Templates button. A searchable list of official templates from the Proxmox repository will appear. Common choices include Debian 12, Ubuntu 22.04, and Alpine Linux. Select your preferred template and click Download. The download runs in the background and takes 30–60 seconds depending on your connection.
Creating the Container
Click Create CT in the top-right corner of the Proxmox UI. Work through each tab:
- General: Set a CT ID (e.g. 100), a hostname (e.g.
pihole), and either a root password or an SSH public key. The SSH key option is recommended — paste in your public key and you can connect immediately without password prompts. - Template: Select the template you downloaded.
- Disks: Set the disk size. 4–8 GB is sufficient for most lightweight services.
- CPU: One core is enough for Pi-hole, Uptime Kuma, or Nginx Proxy Manager. Increase for more demanding workloads.
- Memory: Set RAM and swap. 256–512 MB RAM is typical for lightweight containers. Swap can match RAM.
- Network: Assign a bridge (usually
vmbr0), set a static IP or leave on DHCP. A static IP is recommended if you are running DNS or a reverse proxy. - DNS: Optionally set a custom DNS server — useful when Pi-hole is not yet running.
Click Finish. The container is created within seconds.
Starting the Container and Connecting
Select your new container in the Proxmox sidebar and click Start. Once running, you have two ways to access it. The Console tab in the Proxmox UI provides direct terminal access — useful for initial setup. For ongoing use, SSH is more convenient:
ssh [email protected]If you configured an SSH key during creation, you will connect immediately. From here you can run apt update && apt upgrade -y and install your service as you would on any Debian or Ubuntu system.
Bind Mounts — Sharing Host Storage Into Containers
A bind mount lets you expose a directory from your Proxmox host into a container. This is useful for sharing media files, config directories, or NAS-mounted volumes without duplicating data. In the Proxmox UI, go to your container’s Resources tab, click Add → Mount Point, and specify the host path and the container mount path. Alternatively, edit /etc/pve/lxc/100.conf directly:
mp0: /mnt/nas/media,mp=/media,shared=1Note that bind mounts in unprivileged containers require the host directory to be owned by the mapped UID (typically UID 100000 + container UID). Adjust permissions on the host with chown 100000:100000 /mnt/nas/media if the container cannot write to the path.
Common Use Cases in UK Home Labs
UK home lab users have broadly adopted LXC containers for services that would waste a full VM’s resources. Pi-hole is the most common — a Debian container with 256 MB RAM handles DNS-level ad blocking for an entire household. Uptime Kuma runs comfortably in a 512 MB container and lets you monitor uptime on business services, client-facing sites, and internal tools. Nginx Proxy Manager sits in its own container as a reverse proxy with Let’s Encrypt SSL management. Vaultwarden (a lightweight Bitwarden-compatible server) runs well in a small Ubuntu container and provides self-hosted password management without a SaaS subscription.
Converting a Docker Compose Setup to LXC Containers
If you are currently running services via Docker Compose on a VM, migrating to LXC is straightforward. Each service in your docker-compose.yml becomes its own LXC container. For example, a Pi-hole Compose file with a single service maps to one container. Instead of Docker managing the networking, you assign static IPs directly in Proxmox. Instead of volume mounts in Compose, you use Proxmox bind mounts.
The workflow is: create the container from the appropriate template, install the service natively (e.g. apt install pihole or run the official installer script), configure bind mounts for persistent data, and set the container to start automatically on boot via Options → Start at boot. You eliminate the Docker daemon overhead entirely — for stateless services, this often halves memory consumption.
For services that genuinely require Docker (multi-container apps with complex networking), a single LXC container running Docker is also a valid approach — create a privileged container, install Docker inside it, and run your Compose stack there. This gives you the container startup speed and lower memory overhead of LXC whilst retaining Docker’s ecosystem.
