Give every container that runs code you do not control a memory limit, a swap limit, a CPU limit and a process count limit. Without them, one container can exhaust the host and the kernel may kill unrelated processes, including Docker itself. Limits turn a host wide outage into a single container failure.
What goes wrong without limits
Docker's documentation explains that when a Linux host runs short of memory, the kernel raises an out of memory condition and starts killing processes to free it. Any process is subject to killing, including Docker and other important applications, and this can bring the whole system down. Docker adjusts the out of memory priority of its daemon so it is less likely to be killed, but it does not adjust the priority of containers. A container is therefore a likelier victim than the daemon, though not a guaranteed one.
That is the safety net, not the plan. The plan is to cap each container so it hits its own ceiling first.
The flags that matter
| Flag | What it does |
|---|---|
| memory | Maximum memory for the container, minimum allowed value 6 megabytes |
| memory-swap | Total memory plus swap the container may use, only meaningful with memory set |
| memory-reservation | A soft limit, below memory, applied when the host is under contention |
| cpus | How much CPU the container may use, for example 1.5 |
| cpuset-cpus | Which specific CPUs the container may run on |
| pids-limit | Caps the number of processes in the container |
Docker's example for swap: memory of 300m with memory-swap of 1g lets the container use 300 megabytes of memory and 700 megabytes of swap. Setting a cpus value of 1.5 is equivalent to a CPU period of 100000 and a quota of 150000.
A reservation is a soft limit and Docker states it does not guarantee that the container stays under it, so use memory for the hard cap.
Flags to leave alone
Docker warns against trying to circumvent its safeguards by setting an extreme negative OOM score adjustment, or by disabling the OOM killer on a container. If you disable the killer and set no memory limit, the kernel may need to kill the host's own processes to free memory.
A sizing routine
- Run the workload with generous limits and record peak memory and CPU use.
- Set the memory limit a safe margin above the peak, and set swap to the same value or a small amount so the container does not thrash.
- Set a process limit well above the normal count, so a runaway fork loop stops at a number you chose.
- Set the CPU limit to what the job needs, not the whole host.
- Run a stress test and confirm the container is killed or throttled while the host stays healthy.
The Docker page also advises testing the memory needs of an application before production, running only on hosts with adequate resources, and being careful with swap, which is slower than memory but a buffer against running out.
What limits do not do
Resource limits protect availability. They do not protect confidentiality or integrity. A container held to 256 megabytes can still read a mounted secret. Combine them with a throwaway container checklist and with a plan for kernel level isolation when the code is hostile.
Safeguard does not manage runtime limits. It scans the dependencies and images that go into containers, with a free scan at gold.safeguard.sh/scan.
Quick check
Does a memory limit stop a fork bomb?
Not directly. A process count limit caps how many processes the container can create, while a memory limit caps what they can consume together.
What is the smallest memory limit Docker accepts?
Docker's documentation gives 6 megabytes as the minimum allowed value.
Sources
Last reviewed: 19 October 2026.
