How to Create Your First LXC Container in Proxmox VE

New Proxmox users almost always reach for a full virtual machine first, because that's the model most people already understand from VirtualBox or VMware. Then they notice their little Ubuntu VM is eating 2 GB of RAM just to run one Pi-hole instance, and they start wondering if there's a lighter way. There is, and it's been sitting in the Proxmox interface the whole time: LXC containers.

This guide walks through creating your first LXC container from scratch — downloading a template, setting it up, and getting a working shell inside it — with an explanation of what's actually happening at each step, not just a list of commands to paste.

What You Will Learn

• What an LXC container actually is, and how it's different from a virtual machine
• When a container is the right tool, and when you genuinely need a full VM instead
• How to download a container template
• How to create and configure a container through the Proxmox web interface
• How to do the same thing from the command line with pct
• What each setting and command actually does
• The errors people run into most often, and how to get past them

What Is This Feature?

An LXC container is a lightweight, isolated Linux environment that shares the host's kernel instead of running its own. A virtual machine, by contrast, emulates entire hardware and boots a completely separate operating system with its own kernel, its own memory management, its own everything.

That shared-kernel design is the whole reason containers are fast and light. There's no second kernel to boot, no virtual BIOS to POST through, no virtual disk controller to emulate. Starting a container feels more like starting a background process than powering on a computer — because in a real sense, that's closer to what's actually happening.

Proxmox uses a tool called pct (Proxmox Container Toolkit) to manage LXC containers. It's the container equivalent of the qm command you'd use for virtual machines, and once you've used one, the other feels familiar.

Under the hood, LXC itself isn't a Proxmox invention — it's a long-standing Linux technology, the same general idea that Docker later built on and popularized. Proxmox just wraps it with a friendlier management layer, a web interface, snapshots, and backup integration, so you get most of the convenience of managing a VM while keeping the low overhead of a container.

Why Would You Use It?

Containers make sense any time you want a full, isolated Linux system but don't need — or don't want to pay for — the overhead of a separate kernel and virtual hardware. Some concrete reasons people reach for LXC on Proxmox:

• Resource efficiency. A minimal Debian container can run comfortably in 128–256 MB of RAM, versus the 512 MB–1 GB you'd typically hand a VM just to boot.
• Faster boot times. Containers start in a second or two. VMs take longer because they're booting a full OS from scratch, BIOS and all.
• Simpler resource sharing. Containers can share host storage more directly, which is convenient for things like a container that just needs to read files off your NAS mount.
• Good fit for single-purpose services. Pi-hole, a small web server, a Samba share, a monitoring agent — these don't need their own kernel, they just need Linux.

That said, containers aren't a universal upgrade over VMs. Since they share the host's kernel, you can't run a Windows container, and you can't run a different Linux kernel version than the host. If you need strong isolation between untrusted workloads, or you're running something that expects its own kernel (certain VPN appliances, for instance), stick with a VM. I'd lean toward containers for anything Linux-only and low-risk, and VMs for anything else.

Prerequisites

• A working Proxmox VE installation (8.x or 9.x — the steps below are the same on both)
• At least one storage location configured that supports container templates and root filesystems, such as local-lvm or a directory-based storage
• Root or an account with appropriate permissions on the Proxmox host
• A rough idea of how much disk, RAM, and CPU your container needs — you can always adjust these later

Step-by-Step Tutorial

Step 1: Download a Container Template

Unlike a VM, which you install from an ISO, a container starts from a pre-built template — a compressed filesystem image of a minimal OS install. Proxmox ships with a library of official templates you can download directly.

In the web interface:

• Click your storage in the left tree (commonly local)
• Select the CT Templates tab
• Click Templates
• Find something like debian-12-standard or ubuntu-22.04-standard and click Download

From the command line, you can do the same thing with:

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

Step 2: Create the Container

Once the template has finished downloading, click Create CT at the top right of the Proxmox interface. This opens a wizard with a few tabs:

• General — set the CT ID (Proxmox suggests the next free one) and a hostname, plus a root password or SSH key
• Template — pick the template you just downloaded
• Disks — set the root filesystem size; 4–8 GB is plenty for a small service
• CPU — number of cores; 1 is fine to start
• Memory — 512 MB is a reasonable starting point for a lightweight service, and you can bump it up later if needed
• Network — attach to a bridge (usually vmbr0) and choose DHCP or a static IP

Click through each tab, then hit Finish. If you'd rather skip the wizard entirely, the CLI equivalent looks like this:

pct create 200 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname my-container \
  --cores 1 \
  --memory 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=dhcp

Step 3: Start the Container

From the web UI, select the container and click Start. From the command line:

pct start 200

Step 4: Get a Shell Inside It

To jump straight into the container's shell from the Proxmox host, without needing a password or SSH:

pct enter 200

You'll land directly at a root prompt inside the container. Type exit when you're done to drop back to the host shell.

Step 5: Check Everything Is Working

Confirm the container picked up an IP address and can reach the internet:

pct exec 200 -- ip a
pct exec 200 -- ping -c 3 1.1.1.1

If both of those return sensible output, your container is up and networked correctly.

Commands Explained

Command	What It Does
pveam update	Refreshes the local list of available container templates from Proxmox's template repository.
pveam download local <template>	Downloads a specific template into the storage named local, ready to use for a new container.
pct create 200 ...	Creates a new container with ID 200 using the given template, and applies all the flags that follow (hostname, cores, memory, disk, network).
pct start 200	Boots the container.
pct enter 200	Drops you straight into a root shell inside the running container, no password prompt involved.
pct exec 200 -- <command>	Runs a single command inside the container from the host, without opening an interactive shell.
pct stop 200	Forcefully powers the container off, similar to pulling the plug on a VM.
pct shutdown 200	Sends a clean shutdown signal, letting the container's init system stop services properly first.

Common Errors

• "unable to create CT 200 - CT is locked" — usually means a previous operation (backup, clone, template conversion) didn't finish cleanly. Running pct unlock 200 clears it, but check that nothing is actually still running against that container first.
• "no such logical volume" when creating the rootfs — the storage you picked doesn't have enough free space, or you referenced a storage ID that doesn't support container root disks.
• Container starts but has no network — the bridge name in the network settings doesn't match an actual bridge on the host, or the container is set to a static IP that conflicts with something else on your LAN.
• "startup for container '200' failed" — check pct config 200 for a malformed setting, and look at /var/log/pve/tasks/ on the host for the specific failure reason.

Troubleshooting

If a container refuses to start, the fastest way to see why is:

pct start 200
journalctl -u pve-container@200 -n 50

For networking problems, start by confirming the bridge exists on the host:

ip a show vmbr0

Then check the container's own network config:

pct config 200

If you're using DHCP and the container never gets an address, try switching to a static IP temporarily just to rule out a DHCP server issue on your network rather than a Proxmox problem.

If a container feels sluggish or unresponsive, check whether it's hitting its memory limit:

pct exec 200 -- free -h

Unlike a VM, a container that runs out of memory doesn't just slow down gracefully — the kernel's OOM killer can start terminating processes inside it, which looks like random crashes if you don't know to check for it.

Best Practices

• Use unprivileged containers (the Proxmox default) unless you have a specific reason not to. They run with reduced permissions on the host, which limits the damage if something inside the container is compromised.
• Don't run Docker inside an LXC container unless you've specifically configured the container for it — nested containerization needs extra settings that aren't there by default, and skipping this step is a common source of confusing failures.
• Keep container IDs organized by ranges if you're running a mix of VMs and containers — for example, VMs in the 100s and containers in the 200s. It's a small thing, but it saves confusion six months in when you've forgotten what's what.
• Set resource limits (CPU and memory) even on containers you consider "small." A misbehaving process inside an unconstrained container can still eat all the host's resources.
• Back up containers the same way you'd back up a VM, using Proxmox's built-in backup jobs. People sometimes assume containers are too lightweight to bother backing up, right up until they lose one.

Frequently Asked Questions

Can I run a Windows container in Proxmox?

No. LXC containers share the host's Linux kernel, so the guest OS has to be Linux too. For Windows, you need a full VM.

What's the difference between privileged and unprivileged containers?

Unprivileged containers map the container's root user to a regular, low-privilege user on the host, which limits what a compromised container can do. Privileged containers run as real root on the host and carry more risk. Stick with unprivileged unless something specifically requires otherwise.

Can I convert a container into a VM, or the other way around?

Not directly. They're fundamentally different technologies. You'd need to reinstall the service inside whichever type you're switching to.

Why does my container show 0% CPU usage even when a service is clearly running?

This is usually just a display quirk with how container CPU accounting is reported versus VM accounting — check load with pct exec 200 -- top inside the container itself for an accurate picture.

Is it safe to run Docker inside an LXC container?

It can be done, but it needs the container configured for nesting first, and unprivileged containers have extra caveats. If you're planning to run a lot of Docker workloads, many people find it simpler to just use a small VM instead.

How much disk space should I give a container?

For a small single-purpose service, 4–8 GB is usually enough. You can grow the root filesystem later with pct resize 200 rootfs +4G if you find you need more, so there's little reason to over-allocate up front.

Can I clone an existing container instead of building a new one each time?

Yes. Right-click a stopped container in the web UI and choose Clone, or use pct clone 200 201 from the command line. This is a fast way to reuse a container you've already configured as a starting point for the next one.

Conclusion

LXC containers won't replace every VM in your Proxmox setup, but for lightweight Linux-only services, they're hard to beat on speed and resource use. You've now created one from a template, started it, gotten a shell inside it, and seen the commands that manage its whole lifecycle.

From here, the natural next step is deciding which of your existing VMs are really just running a single Linux service — those are usually your best candidates for moving to a container.