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 |
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.--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.