Go "runtime: out of memory" During Module Operations - Fix in CI

By Daniel Zoghalchali·Latchkey

A module-graph operation ran out of memory. Resolving a very large dependency graph, listing all packages, or downloading huge modules can exhaust RAM on a small runner, ending in an out-of-memory fatal error or an OOM kill.

What this error means

A go mod download, go list ./..., or go mod graph step dies with fatal error: runtime: out of memory, or the step ends abruptly with signal: killed. It is sensitive to runner size and graph complexity, and may pass on a larger runner.

go output

go: downloading ...
fatal error: runtime: out of memory

# or, OOM-killed mid-resolve:
go list ./...: signal: killed

Common causes

A very large module graph on a small runner

Resolving or listing a deep, wide dependency graph holds a lot in memory at once. A memory-constrained runner can be pushed past its limit.

Cold cache forcing many concurrent downloads

With no cached modules, Go fetches and processes many archives at once, spiking memory on a small runner.

How to fix it

Cap the Go memory limit so it backs off

Setting a soft memory limit makes the runtime work harder to stay under it instead of growing until the OS kills it.

Terminal

export GOMEMLIMIT=1800MiB
go mod download

Warm the cache to shrink the working set

A populated module cache means fewer concurrent downloads and far less peak memory.

.github/workflows/ci.yml

- uses: actions/cache@v4
  with:
    path: ~/go/pkg/mod
    key: go-${{ hashFiles('go.sum') }}

Use a larger runner for heavy graphs

.github/workflows/ci.yml

jobs:
  build:
    runs-on: ubuntu-latest-4-cores   # or a higher-memory custom runner

How to prevent it

Cache ~/go/pkg/mod so module operations have a small working set.
Set GOMEMLIMIT on memory-constrained runners.
Size runners to your dependency graph’s resolution footprint.

Frequently asked questions

What causes ""runtime: out of memory""?