Container Memory Limit Exceeded in CI
A job running inside a container was killed because it crossed the container --memory limit. The cgroup OOM killer fires at the limit regardless of how much RAM the host has free.
What this error means
The container exits 137 / OOMKilled even though the host has free memory. Raising or removing the container --memory limit, or using a larger runner, clears it.
docker
$ docker inspect --format '{{.State.OOMKilled}}' job
true
##[error] The container exited with code 137 (OOMKilled).Common causes
The container limit is below the job needs
A --memory/-m cap (or cgroup limit) smaller than peak usage triggers the cgroup OOM killer.
Multiple service containers sharing the limit
Service containers plus the job container together exceed the allotment.
How to fix it
Raise or remove the memory limit
Give the container enough headroom for peak usage.
docker
docker run -m 4g my-job
# in compose
services:
job:
mem_limit: 4gReduce usage or use a bigger runner
- Lower in-container parallelism and heap sizes.
- Split service containers across the available RAM.
- Move to a runner with more memory.
How to prevent it
- Set container limits with real headroom over peak usage.
- Right-size runners for containerized jobs.
- Check
OOMKilledwhen a container exits 137.
Related guides
CI Step "Killed" Exit Code 137 (OOM)Why CI steps exit with code 137 and "Killed": the OOM killer sent SIGKILL after the job exceeded runner memor…
CI "JavaScript heap out of memory" (Node / V8)Fix "JavaScript heap out of memory" in CI when Node/V8 exceeds its heap limit during builds or tests. How to…
java.lang.OutOfMemoryError in CIFix java.lang.OutOfMemoryError in CI when the JVM exceeds its heap or the runner runs out of RAM. How to tune…
CI "Cannot allocate memory" on fork()Fix "fork: Cannot allocate memory" (ENOMEM) in CI when the runner cannot spawn a new process. How to free mem…