Change Container Limits Live with docker container update

A container is hogging memory or restarting when it should not, and you would rather not recreate it to fix that, so use docker container update. It changes resource or restart settings on an existing container, and you then confirm the daemon accepted the new configuration. Nothing is rebuilt. Allow about ten minutes for a single change, plus time to watch an important workload afterwards.

This guide targets the Docker CE CLI installed here as version 29.8.1 from package docker-ce-cli. The local manual is dated September 2026. Settings and API support can vary with the daemon as well as the client, so treat the output from your own host as authoritative.

1. Check the client and identify the container

You need a running Docker daemon, permission to access its socket, and a container name or ID. Ordinary Docker commands are normally unprivileged for users in the Docker group. If your installation requires sudo, add it consistently to the Docker commands below.

Security warning: access to the Docker socket is effectively administrative access to the host, so do not grant it casually.

$ docker version --format '{{.Client.Version}}'
29.8.1
$ docker container ls --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'
CONTAINER ID   NAMES          STATUS
abc123def456   web-example    Up 2 hours

Use the exact name or ID from your own listing. The example ID is only a placeholder. Include -a in docker container ls -a if the target is stopped. Updating a stopped container changes its saved configuration, but it will not start the container.

Tip: record the target and its current settings before changing anything.

$ docker container inspect web-example \
    --format 'memory={{.HostConfig.Memory}} swap={{.HostConfig.MemorySwap}} cpus={{.HostConfig.NanoCpus}} pids={{.HostConfig.PidsLimit}} restart={{.HostConfig.RestartPolicy.Name}}'

The values are daemon data, not a friendly report:

Save this line if you may need to undo the change.

2. Apply one small resource change

The command accepts one or more container names or IDs. Start with a single container and one setting. For example, this sets a 512 MiB memory limit:

$ docker container update --memory 512m web-example
web-example

A successful command prints the affected container name or ID. The setting is dynamic, but it can still disrupt the workload if the process needs more memory. Watch the application and container events after a production change.

The manual lists --memory, --memory-reservation, --memory-swap, --pids-limit, CPU controls, block I/O weight and --restart. Keep relative and absolute limits apart: --cpu-shares is a relative weight, whereas --cpus expresses a CPU quantity.

Memory values use a number followed by b, k, m or g. Use an explicit suffix rather than relying on mental conversion. If you change memory, check the existing swap limit first. The manual says the memory limit should be smaller than the already configured swap limit. If the new memory limit would exceed it, update --memory-swap in the same command.

$ docker container update --memory 512m --memory-swap 1g web-example
web-example

Warning: do not copy that swap value blindly. It is an example of a 512 MiB memory limit with a 1 GiB memory-plus-swap limit, not a universal default. A swap value of -1 enables unlimited swap according to the CLI help. That can hide memory pressure and should be an explicit operational decision.

3. Change CPU or process controls deliberately

Use --cpus when the intent is an easily readable CPU ceiling. The installed client accepts decimal CPU values:

$ docker container update --cpus 1.5 web-example
web-example

This limits the container to 1.5 CPUs when the daemon and host support the setting. If you use --cpu-shares 512 instead, you are changing its relative scheduling weight. That neither reserves half a CPU nor imposes a fixed ceiling.

--pids-limit constrains the number of processes the container can create. It can protect a host from a fork-heavy failure, but an unexpectedly low value can break a legitimate worker or shell:

$ docker container update --pids-limit 256 web-example
web-example
$ docker container inspect web-example --format 'pids={{.HostConfig.PidsLimit}}'
pids=256

Tip: use --pids-limit -1 only when unlimited process creation is understood and acceptable. Resource limits are not a substitute for fixing an application that leaks processes or consumes memory without bound.

4. Update several containers after a single test

Once one container has behaved as expected, apply the same option to several targets. The command below changes both CPU shares and memory on two containers:

$ docker container update --cpu-shares 512 --memory 300m \
    web-example worker-example
web-example
worker-example

Quote names containing unusual shell characters. Keep the target list explicit, because a typo can select the wrong container and a broad script-generated list can change more workloads than intended. Verify each target afterwards:

$ docker container inspect web-example worker-example \
    --format '{{.Name}} memory={{.HostConfig.Memory}} shares={{.HostConfig.CpuShares}}'

Docker may print names with a leading slash and may report byte values rather than the units used in the command. Compare the numeric values with the intended limits rather than expecting identical formatting.

5. Change a restart policy with a separate safety check

A restart policy affects what happens when the container exits. The manual says a new policy takes effect immediately after the update. For example, this permits up to three restarts after failures:

$ docker container update --restart on-failure:3 web-example
web-example
$ docker container inspect web-example \
    --format 'policy={{.HostConfig.RestartPolicy.Name}} maximum={{.HostConfig.RestartPolicy.MaximumRetryCount}}'
policy=on-failure maximum=3

Warning: do not use a restart policy as a replacement for diagnosing a crash loop. It can repeatedly restart a broken service and obscure the original error. Check logs and the service owner before changing production behaviour.

A container created with --rm cannot have its restart policy updated. The manual identifies automatic removal and a restart policy as mutually exclusive. If the policy must be changed, recreate the container from its original run or compose configuration after preserving the required settings. That is a different, service-disrupting operation and is outside this in-place update.

6. Verify, observe and undo

Inspect the fields you changed, then observe the workload. An accepted update proves that Docker stored the configuration. It does not prove that the application still has enough capacity.

$ docker container inspect web-example \
    --format 'memory={{.HostConfig.Memory}} swap={{.HostConfig.MemorySwap}} cpus={{.HostConfig.NanoCpus}} pids={{.HostConfig.PidsLimit}} restart={{.HostConfig.RestartPolicy.Name}}'
$ docker container stats --no-stream web-example

If a limit is wrong, restore the values you recorded in step 1. For example, remove the sample CPU limit and restart policy with:

$ docker container update --cpus 0 --restart no web-example
web-example

Recovery: only use zero or another reset value when the installed help and your saved inspection confirm that it means what you intend. Restore memory, swap and process limits explicitly from the recorded values. Do not assume that a single undo command returns every field to the state created by the image or compose file. If a setting causes an outage, stop making repeated changes, check container logs, and use the service's original configuration as the recovery record.

Done means