Safely Change Docker Container Limits with docker update

You will change the live resource or restart policy of an existing Docker container, then verify the new configuration. The examples target Docker CLI 29.8.1 from the Ubuntu Noble docker-ce-cli package. Allow about 10 minutes if you already know the container name; allow longer if you need to investigate its current limits.

Before you start

You need a Linux host with the Docker CLI and a running Docker daemon. Updating a container normally requires access to the Docker daemon, so use an account that can run Docker commands. A command prefixed with sudo needs elevated privileges. Membership of the docker group is also effectively privileged access to the host; do not add it casually.

The command is an alias for docker container update. It changes the existing container's runtime configuration. It does not edit a Dockerfile or a Compose file, and a later recreation from those definitions can discard the change.

1. Identify the exact container

First list the container names and IDs. Use an explicit name or ID in the update command rather than relying on a shell wildcard.

$ docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Image}}'
CONTAINER ID   NAMES             STATUS         IMAGE
<container-id> <container-name> Up 2 hours     <image:tag>

For a stopped container, use docker ps -a. Check the name character by character before continuing. The command accepts one or more containers, so an accidental second name can change more than intended.

2. Record the current settings

Save the values you may need to restore. This is a read-only command and does not need sudo unless your Docker access requires it.

$ docker inspect --format 'name={{.Name}} memory={{.HostConfig.Memory}} memory_reservation={{.HostConfig.MemoryReservation}} memory_swap={{.HostConfig.MemorySwap}} restart={{.HostConfig.RestartPolicy.Name}}' <container-name>

If that format is not accepted by your CLI, inspect the complete object and search its HostConfig section:

$ docker inspect <container-name>

Keep the original output until the change has been tested. The inspect values are implementation data, so use the documented command-line units when restoring a setting rather than guessing from a raw integer.

3. Apply one focused limit

Change one setting first, then verify it. The following example limits memory to 512 MiB. It changes live container configuration and may cause an application to fail if it genuinely needs more memory.

$ docker update --memory 512m <container-name>
<container-id>

Docker prints the affected container ID when the update succeeds. Check the result rather than treating a returned prompt as proof:

$ docker inspect --format 'memory={{.HostConfig.Memory}}' <container-name>
memory=536870912

Use the same pattern for a soft memory reservation or swap limit. The local command exposes --memory-reservation and --memory-swap; do not assume that changing one automatically gives the policy you want for the other.

4. Set CPU and process limits deliberately

For a CPU cap, --cpus is the clearest option for most cases. This example permits up to half a CPU:

$ docker update --cpus 0.5 <container-name>
<container-id>
$ docker inspect --format 'nano_cpus={{.HostConfig.NanoCpus}}' <container-name>
nano_cpus=500000000

For a process ceiling, set a positive --pids-limit. This is useful protection against a fork-heavy workload, but choose a value that leaves room for the service's normal workers and helper processes.

$ docker update --pids-limit 256 <container-name>
<container-id>
$ docker inspect --format 'pids_limit={{.HostConfig.PidsLimit}}' <container-name>
pids_limit=256

The CLI also exposes CPU shares, CFS period and quota, CPU sets, memory nodes and block I/O weight. Shares and weights are relative controls, not guaranteed percentages. Check the local help before using those lower-level controls:

$ docker update --help

5. Change a restart policy with care

A restart policy can take effect immediately, including on a running container. This example permits three restarts after failures:

$ docker update --restart=on-failure:3 <container-name>
<container-id>
$ docker inspect --format 'restart={{.HostConfig.RestartPolicy.Name}} maximum={{.HostConfig.RestartPolicy.MaximumRetryCount}}' <container-name>
restart=on-failure maximum=3

Do not use this as a substitute for diagnosing a crash loop. Repeated restarts can hide the original error and consume host resources. A container created with --rm cannot have its restart policy updated because automatic removal and restart are incompatible.

6. Undo or recover

If the new limit is too tight, restore the value recorded in step 2. For example, memory value 0 disables the memory limit exposed by this option, while --pids-limit -1 requests an unlimited process limit. Treat both as deliberate recovery actions, not safe general defaults.

$ docker update --memory 0 --pids-limit -1 <container-name>
<container-id>

To remove the restart policy, set it explicitly to no:

$ docker update --restart=no <container-name>
<container-id>

Verify the service after any change. Check its logs and health status, and confirm that the application still serves its expected function:

$ docker logs --tail 50 <container-name>
$ docker inspect --format 'status={{.State.Status}} health={{if .State.Health}}{{.State.Health.Status}}{{else}}not-configured{{end}}' <container-name>

If the container is repeatedly restarting, stop making limit changes and inspect the logs, exit code and host capacity. If the setting must persist across redeployments, update the Docker Compose or other deployment definition as well, then recreate the container during a planned service window.

Common traps

• The option names in the manpage show zero or empty defaults, but an omitted option is not a request to rewrite every other setting. Supply only the setting you intend to change.
• Memory values accept Docker's byte units, such as 512m. Confirm the resulting raw value with docker inspect rather than relying on mental conversion.
• docker update is not supported for Windows containers according to the current Docker documentation. The local manpage describes the Linux CLI options, so do not transfer these examples to a Windows container host.
• Changing a running container's policy is operationally significant even when the command itself returns quickly. Coordinate changes to production containers and keep the recorded pre-change values.