Creating Your First Proxmox LXC Container: Step-by-Step

Create your first Proxmox LXC container from scratch — download a template, run the wizard the right way, choose privileged vs unprivileged, and do the first-boot setup. The homelab workhorse, explained.

Almost every service on my homelab lives in an LXC container. They boot in under a second, a typical one idles at 40–80 MB of RAM, and a single Proxmox VE node can happily run dozens. If a full VM is a whole computer pretending to be hardware, a container is just a fenced-off slice of the host you already have.

This is the complete walkthrough for creating your first LXC container: downloading a template, running the create wizard with the settings that actually matter, choosing privileged versus unprivileged correctly, and doing the first-boot setup. If you’ve already created a VM, you’ll find containers faster and lighter for anything Linux.


Container vs VM — the 20-second version

Both are “guests” in Proxmox, but they work very differently:

Reach for an LXC container when Reach for a VM when
The workload is pure Linux You need Windows, BSD, or another OS
You want minimal RAM/disk overhead You need a different or custom kernel
You want near-instant start/stop You need PCIe/GPU passthrough
You’ll run many small services You need hard tenant isolation

Containers share the host kernel, which is exactly why they’re so cheap — and exactly why they can only run Linux. For the full decision with benchmarks, see Proxmox VM vs LXC. Everything below assumes you’ve picked a container.

Proxmox VE host — one shared Linux kernelpvelab01 · 16 GB RAM · dozens of containers fit hereLXC · wikiWiki.jsno own kernel~60 MB RAMLXC · vaultVaultwardenno own kernel~60 MB RAMLXC · dnsPi-holeno own kernel~60 MB RAM

Task 1: Download a container template

A template is a compressed root filesystem for a distribution — Debian, Ubuntu, Alpine, and so on. You download it once per node and reuse it for every container.

1Refresh the template list1 min

In the web UI: click your node → local storage → CT TemplatesTemplates, and you’ll get a searchable list. Or do it from the shell:

Update the appliance/template index

pveam update
pveam available | grep -E "debian-12|ubuntu-24"

pveam is the Proxmox VE Appliance Manager. available lists everything you can pull; the grep just narrows it to the two most common starting points.

2Download a base template2 min

Debian 12 is the leanest, most predictable choice for a homelab service. Download it to local storage:

Download Debian 12 standard template

pveam download local debian-12-standard_12.7-1_amd64.tar.zst

The exact version string changes over time — copy the current one from the pveam available output rather than pasting this verbatim.

Template storage

Templates need a storage with the vztmpl content type enabled. local has it by default. If you don’t see CT Templates on a storage, add the content type under Datacenter → Storage → Edit.


Task 2: Create the container in the wizard

1Open Create CT1 min

Click Create CT (top-right of the Proxmox UI). Work through the tabs:

  • General — pick the node, accept or set the CT ID (e.g. 101), give it a Hostname, and set a root password (or better, paste an SSH public key). Leave Unprivileged container ticked. Leave Nesting ticked unless you have a reason not to.
  • Template — choose the storage and the template you just downloaded.
  • Disk — 4–8 GB is plenty for most services. This is thin-provisioned on local-lvm by default.
  • CPU — 1–2 cores. Containers share the host scheduler, so this is a ceiling, not a reservation.
  • Memory — 512 MB is a fine starting point for one service; bump it later if needed.
  • Network — bridge vmbr0, and either DHCP or a static IP. See the LXC networking guide for static IPs and VLANs.
  • DNS — leave “use host settings” unless you run your own DNS.
  • Confirm — tick Start after created and click Finish.
Unprivileged is the right default

Keep Unprivileged container ticked. In an unprivileged container the container’s root (UID 0) is mapped to a harmless high UID on the host, so even a full breakout doesn’t hand an attacker root on your node. Only untick it for a specific, understood need — see the Proxmox LXC docs on the security model.

2Or create it from the command line1 min

Prefer the shell? One command does the same thing:

Create an unprivileged Debian container

pct create 101 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
--hostname web01 \
--cores 2 --memory 512 --swap 512 \
--rootfs local-lvm:8 \
--unprivileged 1 --features nesting=1 \
--net0 name=eth0,bridge=vmbr0,ip=dhcp \
--password \
--start 1

--password prompts interactively so it never lands in your shell history. Swap ip=dhcp for ip=10.0.0.101/24,gw=10.0.0.1 to assign a static address.


Task 3: First-boot setup

1Enter the container1 min

From the host, drop straight into a root shell inside the container — no SSH needed:

Open a shell inside CT 101

pct enter 101

pct is the Proxmox container toolkit; pct list, pct start 101, pct stop 101, and pct reboot 101 do exactly what they say.

2Update and add a user3 min

The template ships minimal. Update it, then create a non-root user for day-to-day access:

Patch and create a login user

apt update && apt full-upgrade -y
apt install -y sudo openssh-server
adduser youradmin
usermod -aG sudo youradmin

Now harden access the same way you would any Linux box — SSH keys, no password login. The steps in Proxmox security hardening apply directly inside the container.

Running Docker inside this container?

It works, but the container needs Nesting enabled (Options → Features → Nesting), and unprivileged + nesting is the most reliable combination. If you plan to run more than a couple of Docker apps, many homelabbers put Docker in a small VM instead for cleaner isolation. For one native app, a dedicated LXC is usually simpler.


What’s next

You now have a container that boots in a second and sips RAM. Spin up a few more and you’ve got the backbone of a homelab: a wiki, a password manager, and remote access to reach them all from anywhere. Before you have a dozen of them, set up automated backups so a bad apt upgrade is a five-minute restore, not a rebuild.


Related posts: