By default a Docker container can use as much memory and CPU as it wants. On a shared server that's a problem — one greedy container can starve everything else. Here's how to control it.
Why limits matter
Running multiple services on one machine only works if each one is constrained. Without limits, a memory leak in one container can consume all available RAM and bring down every other service on the box. With limits, the container gets OOM-killed (out of memory killed) before it can affect anything else. That's the outcome you want — isolated failure rather than cascading failure.
Setting limits in Docker Compose
services:
myapp:
image: myapp:latest
deploy:
resources:
limits:
memory: 512m
cpus: '0.5'
reservations:
memory: 256m
cpus: '0.25'
limits is the hard ceiling — the container cannot exceed this. reservations is the guaranteed minimum — Docker will ensure this much is always available to the container.
0.5 means half a CPU core. 2.0 means two full cores. Memory uses standard suffixes — 512m for megabytes, 2g for gigabytes.
Checking what containers are using
docker stats
This shows live CPU and memory usage for all running containers — like top but for Docker. Useful for spotting which container is eating resources before it becomes a problem.
What happens when limits are hit
When a container hits its memory limit the kernel OOM-kills the process inside it. The container then either exits or restarts depending on your restart policy. When a container hits its CPU limit it gets throttled — it slows down rather than getting killed. CPU limits are softer than memory limits.
Pterodactyl and resource limits
This is exactly what Pterodactyl uses under the hood for game server resource management. Each server gets a memory and CPU allocation, and Docker enforces those limits at the container level. One server running a memory-intensive mod can't starve the other servers on the same node — the limit is hard and enforced by the kernel.