Docker vs LXC on Proxmox: When to Use Each Container Type

Two Kinds of Containers

Proxmox VE natively supports LXC containers, but many users also want to run Docker. These two technologies solve different problems. LXC provides system containers that behave like lightweight virtual machines with their own init system, networking, and user space. Docker provides application containers that package a single application and its dependencies into an isolated, portable unit. Understanding this distinction is key to choosing the right approach on Proxmox.

LXC: System Containers

LXC containers on Proxmox share the host kernel but have their own root filesystem, network stack, and process tree. They boot like a minimal Linux system, run systemd or another init, and you can SSH into them. Proxmox manages their lifecycle, snapshots, backups, and resource limits natively.

# Create an LXC container from a Proxmox template
pct create 200 local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst \
    --hostname docker-host \
    --memory 2048 \
    --cores 2 \
    --net0 name=eth0,bridge=vmbr0,ip=dhcp \
    --storage local-lvm \
    --rootfs local-lvm:8

# Start and enter the container
pct start 200
pct enter 200

LXC containers are ideal for running traditional Linux services: web servers, databases, DNS, monitoring agents. They use minimal overhead (typically 10-30 MB RAM for the base system) and start in seconds.

Docker: Application Containers

Docker containers are designed to run a single process or application. They use layered images from Docker Hub or private registries, and Docker Compose allows you to define multi-container stacks declaratively. Docker is the standard for microservices and CI/CD pipelines.

Proxmox does not manage Docker containers natively. You need a host to run the Docker daemon, and that host can be either a VM or an LXC container.

Running Docker Inside an LXC Container

This is the most resource-efficient approach but requires careful configuration. Docker needs access to kernel features (cgroups, overlayfs, namespaces) that LXC containers do not expose by default.

# On the Proxmox host, configure the LXC container for Docker
# Edit /etc/pve/lxc/200.conf and add:
features: nesting=1,keyctl=1

# For unprivileged containers (recommended), nesting is usually sufficient
# For some Docker features, you may need a privileged container:
# unprivileged: 0

# Start the container and install Docker inside it
pct start 200
pct enter 200

# Inside the LXC container:
apt update && apt install -y curl
curl -fsSL https://get.docker.com | sh

# Verify Docker works
docker run hello-world

# Install Docker Compose
apt install -y docker-compose-plugin
docker compose version

Important: Running Docker in an unprivileged LXC container with nesting=1 works for most workloads. Avoid privileged containers unless absolutely necessary, as they weaken the security boundary between the container and the Proxmox host.

Running Docker Inside a VM

Running Docker inside a full VM provides the strongest isolation. The VM has its own kernel, so there are no compatibility concerns with Docker features. This is the recommended approach for production workloads or untrusted containers.

# Create a VM for Docker
qm create 300 --name docker-vm --memory 4096 --cores 4 \
    --net0 virtio,bridge=vmbr0 \
    --scsihw virtio-scsi-single \
    --scsi0 local-lvm:32 \
    --cdrom local:iso/debian-12.4.0-amd64-netinst.iso \
    --boot order=scsi0

# After OS installation, install Docker the standard way
# Performance is near-native thanks to KVM hardware virtualization

Performance Comparison

The performance differences are measurable but may or may not matter depending on your workload:

• CPU: Both LXC and Docker add negligible CPU overhead. VMs add roughly 1-3% due to virtualization, though with VT-x/VT-d this is minimal.
• Memory: LXC containers share the host kernel (saving 100-200 MB per instance vs a VM). Docker in LXC adds the Docker daemon overhead (~50 MB). Docker in a VM adds the full guest kernel.
• Disk I/O: LXC with bind mounts has near-native disk performance. Docker's overlay filesystem adds slight latency. VMs with virtio-scsi are within 5% of native.
• Startup time: LXC containers start in 1-2 seconds. Docker containers start in under a second (once the image is pulled). VMs take 10-30 seconds to boot.

Using Portainer for Docker Management

Portainer provides a web UI for managing Docker containers, images, networks, and volumes. It runs as a Docker container itself.

# Install Portainer Community Edition
docker volume create portainer_data

docker run -d -p 8000:8000 -p 9443:9443 \
    --name portainer --restart=always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v portainer_data:/data \
    portainer/portainer-ce:latest

# Access Portainer at https://your-host:9443

Docker Compose in LXC

Docker Compose works inside LXC containers just as it does on bare metal. Here is a practical example of a common homelab stack:

# docker-compose.yml for a monitoring stack
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"

volumes:
  prometheus_data:
  grafana_data:

# Deploy with:
# docker compose up -d

Which Should You Choose?

Use LXC alone when you want a lightweight Linux environment for traditional services and you prefer Proxmox-native management (snapshots, backups, live migration). Use Docker in a VM when you need full isolation, run untrusted images, or need kernel features not available in LXC. Use Docker in LXC when you want the resource efficiency of LXC with the application packaging benefits of Docker, and your workloads are trusted.

Whichever approach you take, tools like ProxmoxR let you monitor and manage your Proxmox LXC containers and VMs from a single interface, so you can keep an eye on the hosts running your Docker workloads without switching between multiple dashboards.