Bazel "java.lang.OutOfMemoryError: Java heap space" / Killed in CI

By Kaveh Alemi·Latchkey

The Bazel JVM (or a memory-hungry action) ran past the runner's available RAM. The JVM throws OutOfMemoryError: Java heap space, or the OS OOM killer terminates the server with "Killed" and a lost-connection error.

What this error means

A build dies with "java.lang.OutOfMemoryError: Java heap space", or the Bazel server is "Killed" and the client reports the server terminated abruptly.

java.lang.OutOfMemoryError: Java heap space
Server terminated abruptly (error code: 14, error message: 'Socket closed', ...)

Common causes

The JVM heap exceeds the runner memory

Large analysis or many concurrent actions push the Bazel server JVM past the heap or the runner's physical RAM.

Too much parallelism for the runner

A high --jobs value runs more memory-heavy actions at once than the runner can hold, triggering the OOM killer.

How to fix it

Cap heap and limit parallelism

1. Cap the server JVM heap with a startup --host_jvm_args.
2. Lower --jobs and per-action RAM so concurrent actions fit.
3. Re-run on a runner with more memory if needed.

bazel --host_jvm_args=-Xmx4g build //... --jobs=4 --local_ram_resources=6144

Set limits in .bazelrc

Persist conservative memory and job limits so every CI run uses them.

startup --host_jvm_args=-Xmx4g
build --jobs=4
build --local_ram_resources=6144

How to prevent it

• Set explicit JVM heap and job limits in .bazelrc.
• Size runners to the build's real memory footprint.
• Use remote execution to offload heavy actions off the runner.

Frequently asked questions

Related guides

References

• GitHub Actions documentation