Next.js build slow or out of memory in GitHub Actions: cache, memory, runner size

A Next.js build in GitHub Actions is slow for one reason and runs out of memory for another. It is slow when .next/cache isn't carried to the next run: Next.js reuses that cache between builds, a GitHub-hosted job starts on a new VM, and without a cache step every build is cold (the log says No Cache Detected). It runs out of memory because a private repository's ubuntu-latest has 8 GB, and a large app's webpack compile, type check and source maps can pass that. Fix the first with actions/cache on .next/cache. For the second, Next.js's memory settings come first (experimental.webpackMemoryOptimizations, no production source maps); then a machine with more memory: 16 GB or 32 GB.

Skipbox gives the build that memory at a flat price: 16 GB and 8 vCPU on runs-on: skipbox-8x16 for $79 a month, 32 GB and 16 vCPU on skipbox-16x32 for $149. On your own machine the package caches stay on the disk and what actions/cache saves is read locally, with unlimited minutes.

Slow: .next/cache starts empty

From Next.js's CI build caching guide: Next.js "saves a cache to .next/cache that is shared between builds", and a CI that doesn't persist it between builds shows a No Cache Detected error. Its GitHub Actions step:

- uses: actions/cache@v4
  with:
    path: |
      ~/.npm
      ${{ github.workspace }}/.next/cache
    key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/*.js', '**/*.jsx', '**/*.ts', '**/*.tsx') }}
    restore-keys: |
      ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-

The key changes with every source change, so each run saves a new entry, inside GitHub's 10 GB per repository. In a Turborepo, exclude .next/cache from the task's outputs ("!.next/cache/**"), as Turborepo's GitHub Actions guide does.

Out of memory: two different errors

Raising the heap past the machine's memory turns the first error into the second.

Use less memory: Next.js's own settings

From Next.js's memory usage guide:

• experimental.webpackMemoryOptimizations: true (v15.0.0 and later) lowers webpack's peak memory, at a slightly longer compile.
• The webpack build worker runs compilation in a separate Node worker, which lowers memory. It is on by default since v14.1.0 unless you have a custom webpack config; with one, set experimental.webpackBuildWorker: true.
• Source maps off: productionBrowserSourceMaps: false and experimental.serverSourceMaps: false. If the build runs out during "Generating static pages", enablePrerenderSourceMaps: false too.
• Measure: next build --experimental-debug-memory-usage (v14.2.0 and later) prints heap use through the build, and takes heap snapshots near the limit.
• Type checking: typescript.ignoreBuildErrors: true skips the type check and its memory, and lets type errors into the build. Next.js warns against it unless another step type-checks.

Use a machine with more memory

At 20,000 minutes a month, GitHub's 8-core runner is $422 and Skipbox M is $79; at 16 cores, $822 against $149 for L. GitHub's figures are after GitHub Team's included usage.

What Skipbox does for a Next.js build

Each plan comes with your account's own machine, kept between jobs:

• The memory the build needs, by label: 16 GB on M, 32 GB on L. Set the heap to match, such as --max-old-space-size=12288 on M.
• Package caches stay on the disk: ~/.npm, the pnpm store, each tool's ~/.cache, and the Node versions setup-node installed. npm ci reads them instead of the registry.
• actions/cache restores read the machine. .next/cache is an untracked folder, and the checkout's untracked files are cleaned after each job, so keep the cache step. What it saves stays next to the machine, with more room than GitHub's 10 GB per repository, and the restore is a local read.
• More cores at a flat price. The compile and the static page generation use them, and minutes are unlimited.

Moving is one line

jobs:
  build:
    runs-on: skipbox-8x16 # was ubuntu-latest
    env:
      NODE_OPTIONS: --max-old-space-size=12288
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - uses: actions/cache@v4
        with:
          path: ${{ github.workspace }}/.next/cache
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/*.js', '**/*.jsx', '**/*.ts', '**/*.tsx') }}
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-
      - run: npm ci
      - run: npx next build

skipbox-8x16 runs on an M plan; the trial runs runs-on: skipbox.

1. Sign in to Skipbox with GitHub.
2. Install the Skipbox GitHub App and pick the repositories.
3. Change runs-on and push.

Security

• The machine is your account's alone. No other company's jobs run on it.
• After every job, the runner's credentials, processes and containers are wiped, and so are the git credentials and untracked files in the kept checkout. Clean every job gives each job a fresh machine instead.
• Code from people without write access (such as pull requests from forks) runs on a fresh VM that reads your caches but can't change them.

The details are in how jobs are isolated.

Try it on the Next.js build

The trial is free for 7 days or 3,000 job-minutes, whichever comes first, with no card. It runs runs-on: skipbox, with 16 GB, 2× the memory of a private repository's ubuntu-latest: try the cache and the memory there, and move a build that needs more to plan L (skipbox-16x32, 32 GB).

Updated November 13, 2026