Introduction
You spin up an LXC container for a small app — maybe Nextcloud, maybe a build server — give it 1 core and 512 MB of RAM because that felt like plenty at the time, and three weeks later it's crawling. Or worse, it's getting OOM-killed mid-upload. The good news is that giving a container more room in Proxmox VE doesn't mean rebuilding it. You change a couple of numbers and, in most cases, the container just picks them up.
This is one of those tasks that trips people up not because it's hard, but because it's almost identical to resizing a virtual machine — and the small differences are exactly where beginners get stuck. LXC containers share the host's kernel, so memory and CPU limits work through Linux cgroups rather than emulated hardware. That changes what "instant" actually means in practice.
By the end of this guide you'll know exactly how to bump cores and RAM for a container, what happens live versus what needs a restart, and how to avoid the one mistake that quietly kills processes inside the container without any obvious error on the Proxmox side.
What You Will Learn
- What CPU cores, cpulimit, cpuunits, memory, and swap actually control for an LXC container
- How to change them from the Proxmox web interface and from the command line with
pct set - Which changes apply immediately and which need a container restart to take effect
- How to check what a container is currently using before you touch its limits
- The most common errors people hit and how to fix them
What Is This Feature?
An LXC container in Proxmox VE isn't a full virtual machine. It doesn't boot its own kernel or emulate a BIOS. Instead, it's an isolated slice of the Proxmox host itself — its own filesystem, its own process tree, its own network stack — but running on top of the one kernel the host is already running. That's why containers start in under a second and use a fraction of the RAM a comparable VM would need.
Because there's no virtual hardware to configure, "resources" for a container mean something different than they do for a VM. Proxmox enforces CPU and memory limits using a Linux kernel feature called cgroups (control groups). Think of a cgroup as a fenced-off portion of the host's real CPU time and real RAM, handed to one container. When you edit a container's resources in Proxmox, you're really just adjusting the size of that fence.
Four settings matter here:
- cores — how many of the host's CPU threads the container is allowed to see and use
- cpulimit — a hard ceiling on total CPU time, expressed in core-equivalents (0.5 means half a core's worth, even across multiple cores)
- cpuunits — a relative priority number used only when the host is under contention; it doesn't cap anything by itself
- memory / swap — the RAM ceiling and how much host swap space the container can borrow on top of it
Why Would You Use It?
Most people undersize a container on day one because Proxmox's create wizard defaults to something conservative, and it's easy to click through without thinking about it. The moment you actually install something — a database, a media server, a CI runner — that default starts to show its limits.
The usual symptoms are a container that feels sluggish under load, a service that gets killed unexpectedly (check dmesg on the host and you'll often find the kernel's OOM killer logged right there), or a build job that takes four times longer than it should because it's fighting over a single CPU thread. Bumping cores and memory is the fix, and it's genuinely low-risk compared to, say, resizing a disk — there's no partition table to worry about, no data to lose. You're just widening the fence.
It's also worth doing this instead of just recreating the container with bigger numbers from scratch. You keep your installed packages, your configuration, your data — nothing about the container's identity changes, only how much of the host it's allowed to use.
Prerequisites
- A Proxmox VE host with at least one existing LXC container (this guide assumes Proxmox VE 8.x or 9.x, though the commands haven't changed in years)
- Root or an account with the VM.Config.CPU and VM.Config.Memory permissions on the container
- SSH access to the host, or the Shell console in the web UI, if you want to use the command line
- Enough free CPU threads and RAM on the host itself — Proxmox won't invent hardware for you, it just controls how existing hardware is divided up
- The container's ID number (visible in the left-hand tree in the web UI, or via
pct list)
Step-by-Step Tutorial
Step 1: Check what the container is actually using right now
Before you change anything, it helps to know what you're starting from. Log into the Proxmox web UI, click the container in the left panel, and open the Summary tab. You'll see live CPU and memory graphs. If memory usage is consistently pinned near 100% of its current limit, that's your evidence the container needs more.
From the command line, you can get the same picture from inside the container:
pct exec 105 -- free -hSwap 105 for your own container's ID. This runs free -h inside the container without you needing to open a shell session first — handy for a quick check.
Step 2: Open Resources in the web interface
Click your container, then go to the Resources tab. You'll see rows for Memory, Swap, and CPU. Double-click any of them to edit. For CPU, you can set the number of cores directly. For Memory, you'll see two separate fields — Memory and Swap — and they're not the same thing, which trips a lot of people up.
Memory is real RAM. Swap is disk space the container can fall back on when it runs out of real RAM, borrowed from the host's own swap. Giving a container a large swap value doesn't make it faster; it just gives it somewhere to land instead of crashing outright when it hits its memory ceiling. For most home lab containers, a small swap value (256–512 MB) is plenty as a safety net — it's not something you want to rely on for actual performance.
Step 3: Change resources from the command line with pct set
If you'd rather script this or you're comfortable in the shell, pct set does the same job the GUI does, just faster:
pct set 105 -cores 4 -memory 4096 -swap 512This gives container 105 four CPU cores, 4096 MB (4 GB) of RAM, and 512 MB of swap. You can set just one value at a time too — you don't have to touch all three together.
Want to add a hard CPU time ceiling on top of the core count? Use cpulimit:
pct set 105 -cpulimit 2That caps the container at the equivalent of two full cores of CPU time, even if you've given it four cores worth of visibility. It's a belt-and-suspenders setting most people never touch — cores alone is usually enough.
Step 4: Know what applies live and what doesn't
This is the part that actually matters. Memory and swap changes on a running container apply immediately — the cgroup limit updates in the kernel and the container simply has more (or less) room right away. No restart needed.
CPU core changes also apply live in the sense that Proxmox updates the container's allowed CPU set instantly. But here's the catch: plenty of applications only check how many CPUs are available once, at startup. nginx's worker_processes auto setting is a classic example — it picks a worker count when nginx starts, not continuously. If you double a container's cores while nginx is already running inside it, nginx won't notice until you restart the nginx service (or the container).
So: the container itself doesn't need a reboot for either change. Whether the application inside it benefits right away depends on that application. When in doubt, restart the service inside the container after a core change, just to be safe.
Step 5: Verify the change actually took
Check the running configuration:
pct config 105This prints the container's current settings, including the cores, memory, and swap lines you just changed. Compare it against what you intended. Then confirm from inside the container:
pct exec 105 -- nproc
pct exec 105 -- free -hnproc tells you how many CPUs the container itself sees, and free -h confirms it now reports the new memory ceiling rather than the old one.
Commands Explained
| Command | What it does |
|---|---|
pct list | Lists every container on the host with its ID, status, and name — useful when you've forgotten a container's ID |
pct config <CTID> | Prints the container's current configuration, including cores, memory, and swap |
pct set <CTID> -cores N | Sets the number of CPU cores the container can see and use |
pct set <CTID> -memory N | Sets the memory ceiling in megabytes |
pct set <CTID> -swap N | Sets how much host swap the container can borrow, in megabytes |
pct set <CTID> -cpulimit N | Caps total CPU time to N core-equivalents, regardless of core count |
pct exec <CTID> -- <cmd> | Runs a single command inside the container without opening a full shell session first |
pct cpusets | Shows which physical CPU threads each running container is currently pinned to |
pct reboot <CTID> | Restarts the container cleanly — useful after a change you want every running process to pick up |
Common Errors
The error messages here are usually blunt and honest, which helps once you know what they mean.
"pct set: unable to parse value of 'memory'" — you passed something that isn't a plain integer. Memory and swap values are in megabytes and take a bare number, not "4G" or "4096MB". Use -memory 4096, not -memory 4G.
Container starts, then services inside crash with "Cannot allocate memory" — you likely lowered the memory limit below what's already running inside. Check current usage with pct exec <CTID> -- free -h before shrinking a limit, not after.
dmesg on the host shows "Memory cgroup out of memory: Killed process" — this is the kernel's OOM killer acting inside that container's cgroup. It means the memory ceiling is too low for what's actually running. Raise the memory limit, don't just add swap and hope — swap is slow and services that get OOM-killed once tend to get killed again under the same load.
Core count change seems to do nothing — almost always this is the application-level caching issue from Step 4. Restart the service inside the container, or the container itself, and check again with nproc.
Troubleshooting
If a container refuses to start after a resource change, the first place to look is the Task Log in the web UI (top right corner, or the Tasks panel at the bottom of the Datacenter view). It'll show the exact command Proxmox ran and where it failed.
If memory usage inside the container still looks capped at the old value after you've confirmed pct config shows the new number, double-check you're looking at the right container ID. It's an easy mix-up on a host running a dozen containers, and pct list takes two seconds to confirm you're editing the one you think you are.
If the host itself starts feeling sluggish after you've handed out more cores or memory to a container, that's not really a Proxmox problem — it's a sign you've over-committed the physical hardware. Proxmox will happily let you assign more cores across containers than the host physically has, because most containers don't use their full allocation simultaneously. But if several of them do at once, everything slows down together. Check total assigned cores against physical threads with lscpu on the host if this happens.
Best Practices
Don't max out a container's limits just because you can. Assign what the workload actually needs, watch the Summary graphs for a few days, and adjust from there. It's a five-second change either way, so there's no real cost to being conservative and revisiting it.
Leave cpuunits at its default (100 on a modern cgroup v2 host) unless you're specifically trying to make one container win a CPU-contention fight against another during heavy load. It's a relative priority, not a hard cap, and most home lab setups never need it touched.
Keep swap small and treat it as a safety net, not a performance feature. A container that's constantly dipping into swap needs more real memory, not more swap.
Honestly, if you find yourself resizing the same container every other week, that's usually a sign the workload has outgrown a container and belongs in its own VM instead — especially if it needs kernel modules or resources a container can't provide.
Frequently Asked Questions
Do I need to stop the container before changing its resources?
No. Both pct set and the GUI accept memory, swap, and core changes on a running container, and the new limits apply immediately at the cgroup level.
Will lowering the memory limit corrupt data inside the container?
No, but it can crash whatever process gets OOM-killed as a result. Check current usage first, and lower limits gradually rather than in one big cut.
What's the difference between cores and cpulimit?
Cores controls how many CPU threads the container can see at all. Cpulimit caps total CPU time regardless of core count — a container with 4 cores and a cpulimit of 1 can only ever use one core's worth of processing time total, spread however it likes across those 4 cores.
Can I assign more total cores to my containers than the host physically has?
Yes, Proxmox allows it, and it's normal practice since containers rarely peak at the same time. Just watch host-level CPU usage if you've got several busy containers running together.
Does this work the same way for privileged and unprivileged containers?
Yes. Resource limits are enforced by the host kernel's cgroups regardless of whether the container is privileged or unprivileged — that distinction affects permissions and isolation, not CPU or memory accounting.
Conclusion
Resizing an LXC container comes down to two commands and a bit of judgment about what's live versus what needs a nudge. Check current usage, adjust memory and cores with pct set or the Resources tab, and restart the service inside if it's the kind of app that only checks CPU count once at boot. It's one of the lowest-risk changes you can make in Proxmox — no partitions, no data loss, just a wider fence around resources that were already there. Once you've done it once, it stops feeling like a separate skill and just becomes part of how you run containers day to day.