Docker Resource Limits Converter

Values above 9007199254740991 are displayed as decimal strings in HostConfig JSON to preserve every digit; normal values remain numbers. This display JSON is not an Engine API request. Integer flags use the existing decimal subset and reject values above int64 max (9223372036854775807). Memory is calculated in exact decimal arithmetic with binary suffixes and fractional bytes truncated; unlike go-units float64 parsing, large values are not rounded. A value truncated to 0 is Docker’s unset/default sentinel, so it creates no memory limit or reservation. If automatically doubling memory would exceed int64, specify memory-swap explicitly. HostConfig displays parsed values except where daemon adjustments are described; extreme values may still be rejected at runtime. Converts the docker run resource flags into the values the daemon actually stores and enforces. --cpus=N is parsed exactly, as the Docker CLI does: HostConfig.NanoCpus is N x 1e9 and must be a whole number, so more than nine decimal places is rejected as too precise rather than rounded (only plain decimal notation is accepted here; the CLI also takes fractions such as 3/2). At the cgroup level the daemon derives cpu.max = floor(NanoCpus x 100000 / 1e9) 100000, always with its fixed 100000-microsecond period and truncating integer division, so --cpus=0.666666666 gives quota 66666, not 66667. Because of that truncation, --cpus below 0.00001 derives a quota of 0, which runc hands to cgroup v2 as CpuQuota 0 and cgroup v2 writes as cpu.max = max 100000 -- no quota at all; --cpus from 0.00001 up to (but excluding) 0.01 derives a quota of 1-999 microseconds, below the kernel's 1ms CFS minimum, so the container is rejected at start; --cpus of 0.01 or more is enforced. This tool shows the resulting cpu.max and a warning for the first two bands. --cpus cannot be combined with a positive --cpu-period or a positive --cpu-quota: the daemon rejects that as conflicting options (NanoCPUs > 0 with CPUPeriod > 0 or CPUQuota > 0), so this tool reports an error instead of merging them. Zero is Docker's unset/default sentinel for all three flags: --cpus=0 is NanoCpus 0 and sets no CPU limit (Compose likewise ignores limits.cpus of 0, so no cpus: line is rendered), and --cpu-period=0 / --cpu-quota=0 are stored in HostConfig but skipped when the daemon builds the OCI spec, so they neither conflict with --cpus nor change cpu.max. --cpu-shares=0 is an unset/no-op sentinel; --cpu-shares, --cpu-period, and --cpu-quota otherwise pass through to HostConfig unchanged; the daemon checks the conflicts first, then requires a non-zero --cpu-period between 1000 and 1000000 microseconds and a positive --cpu-quota of at least 1000 microseconds, and this tool applies the same checks in the same order. --cpu-quota=-1 means no quota and renders cpu.max as max <period>; the daemon's conflict check ignores it, so --cpus together with --cpu-quota=-1 is accepted and ends up with no CPU limit at all, which this tool flags. Other negative --cpu-quota values are not modeled. For --pids-limit, positive values are retained and shown as pids.max; 0 and -1 mean unlimited, so Moby normalizes PidsLimit to nil on create and this HostConfig projection omits the field while preserving the original docker run flag. Moby also accepts other negative PIDs values historically, but this tool supports only 0 and -1. Memory suffixes b/k/m/g are binary (1024-based): 512m is 536870912 bytes. When --memory is positive and --memory-swap is omitted or parses to 0, Docker sets MemorySwap to twice Memory, which surprises people who expect no swap by default; --memory-swap=-1 means unlimited swap, and setting it equal to --memory means no swap at all. Compose's deploy.resources.limits is honoured by docker compose up for cpus and memory, but deploy as a whole is a Swarm-oriented section, and several of its other keys (replicas, placement, update_config, restart_policy, and more) are ignored by plain docker compose up outside Swarm mode -- this tool does not claim deploy is a blanket equivalent of the docker run flags. memory.high has no direct docker run flag, so this tool never invents a value for it.