Work out container CPU/memory limits and total footprint, or size a host from your total resource needs.
Recommendation takes the larger of the CPU-bound and memory-bound counts, since a host fleet is limited by whichever resource runs out first.
Docker doesn't use the word "request" the way an orchestrator like Kubernetes does, but the same idea exists under different flag names. --memory is a hard ceiling: once a container crosses it, the kernel's OOM killer terminates a process inside the container. --memory-reservation is a soft floor that only kicks in when the host is under memory pressure, which is the closest thing Docker has to a "guaranteed minimum." CPU works similarly: --cpus caps how much CPU time a container can use, expressed as a decimal number of cores (1.5 means one and a half cores' worth of CPU time), while --cpu-shares sets a relative weight used only when multiple containers are competing for CPU — it does nothing when the host has spare capacity.
| Flag | Type | What it does |
|---|---|---|
--cpus | Hard limit | Caps CPU time to N cores; container is throttled beyond that, never killed for it |
--cpu-shares | Soft weight | Relative priority (default 1024) used only when CPU is contended |
--memory | Hard limit | Container is OOM-killed if it tries to exceed this |
--memory-reservation | Soft floor | Kernel tries to keep the container above this under memory pressure, no guarantee |
--memory-swap | Swap ceiling | Total of memory + swap the container may use; set equal to --memory to disable swap |
Docker resource management allows you to control how much CPU, memory, swap, storage, and other system resources a container can consume. By setting resource limits, you prevent one container from affecting the performance of other applications running on the same host.
Docker provides CPU quotas, memory limits, reservations, swap controls, and storage drivers to ensure containers share system resources efficiently.
| Resource | Description |
|---|---|
| CPU | Controls processor usage. |
| Memory | Maximum RAM a container can use. |
| Swap | Additional virtual memory. |
| Storage | Disk usage. |
| PIDs | Maximum number of processes. |
| IO | Disk read/write priority. |
docker run \
--cpus=2 \
--memory=2g \
--memory-swap=2g \
nginx
The above command limits the container to two CPU cores and 2 GB of RAM while disabling swap.
services:
app:
image: myapp
deploy:
resources:
limits:
cpus: '2'
memory: 2G
reservations:
cpus: '1'
memory: 1G
| Docker | Kubernetes |
|---|---|
| --memory | limits.memory |
| --cpus | limits.cpu |
| Reservation | requests |
Total CPU = CPU Limit × Number of Containers
Total Memory = Memory Limit × Number of Containers
Required Hosts = Maximum ( Total CPU ÷ CPU per Host, Total Memory ÷ Memory per Host )
Say you're deploying an API service with three instances behind a load balancer. Each container needs at least 0.25 CPU cores and 256 MB of memory to run comfortably, but you want to allow bursts up to 1 core and 512 MB before Docker steps in. Plugging cpuLim = 1, cpuRes = 0.25, memLim = 512, memRes = 256, and replicas = 3 into the Container Limits tab gives you a total ceiling of 3 cores and 1,536 MB across the three instances, with a guaranteed floor of 0.75 cores and 768 MB. That total is what you should compare against your host's usable capacity before deploying — not the per-container numbers alone, which look small in isolation but add up fast at scale.
Now switch to the Host Sizing tab and enter that same 3-core, 1.5 GB requirement alongside every other service sharing the host. If your combined workloads across all services need 18 cores and 48 GB, and each host has 8 vCPUs and 32 GB with a 10% overhead reserved for the OS and Docker daemon, the calculator returns roughly 7.2 usable cores and 28.8 GB usable per host — meaning you'd need 3 hosts on the CPU side and 2 on the memory side. Since a fleet is bottlenecked by whichever resource fills up first, the recommended count is 3 hosts, with memory to spare.
--memory-reservation or a CPU reservation is higher than the corresponding limit, Docker will refuse the configuration or behave unpredictably — the reservation is supposed to be a soft floor beneath the hard ceiling, never above it.--cpu-shares with a hard cap. Shares only matter when the CPU is actually contended; on an idle host a container with low shares can still use every core available.--memory-swap, a container can quietly spill into swap instead of being OOM-killed, which trades a clean failure for a slow, hard-to-diagnose one.--memory-swap equal to --memory for latency-sensitive services so they fail fast and visibly instead of degrading silently into swap.docker stats or a metrics stack after deployment, and revisit your limits periodically — resource needs drift as code and traffic patterns change.Proper Docker resource planning helps ensure that containers have enough CPU and memory to run reliably while preventing resource contention on the host. Whether you're deploying a single container or an entire cluster, understanding Docker container resources is essential for performance, stability, and cost optimization.
This free Docker Resource Calculator works as a Docker CPU limit calculator and Docker memory calculator, helping you estimate CPU limits, memory reservations, total resource usage, and host capacity before deployment. It simplifies Docker host sizing by calculating how many containers or hosts are required based on your workload and available hardware.
The calculator also helps you configure important Docker resource settings such as Docker CPU quota, Docker CPU shares, Docker memory reservation, Docker memory limit, and Docker swap memory. By understanding how these settings work together, you can allocate resources efficiently while maintaining application performance under varying workloads.
Whether you're planning a development environment, production deployment, or Kubernetes migration, this tool supports accurate Docker resource allocation, Docker container sizing, Docker deployment planning, and even large-scale Docker cluster sizing. Use the calculator to estimate total CPU cores, memory requirements, replica capacity, and recommended host counts before launching your containers.
--memory flag is enforced per container by the kernel's cgroup limits regardless of what's free on the host. A container hitting its own limit gets killed even if the rest of the machine is nearly idle.--cpus 1.0 caps the container at the equivalent of one full core's worth of CPU time. --cpus 0.5 caps it at half a core, and --cpus 2 allows up to two cores' worth, spread across however many cores are available.--memory to disable swap entirely, so an over-limit container is killed cleanly instead of slowing down unpredictably while swapping.--cpus, --cpu-quota, or --cpu-period.
--cpuset-cpus option restricts a container to specific CPU cores. For example, --cpuset-cpus="0,1" allows the container to run only on CPU cores 0 and 1, which can improve performance consistency for certain workloads.
--memory-reservation specifies a soft memory limit. Docker attempts to reserve this amount of memory for the container when the host is under memory pressure, while still allowing the container to use additional memory up to its configured hard limit.