Jenkins stash Too Large - Fix Slow/Oversized stash/unstash

stash transfers files through the controller and stores them on the controller’s disk for the build. Stashing large trees (node_modules, build caches, big binaries) slows the build, pressures controller disk/heap, and is the wrong tool for big data.

What this error means

A stash step is very slow or the controller disk/heap spikes during stash/unstash. Builds that stash large directories take far longer in the stash step than in the build itself, and the controller shows IO/heap pressure.

Stashed 1 file(s) (size: 1.4 GB) in 3m 12s
# controller disk/heap pressure follows; unstash equally slow

Common causes

Stashing large directories through the controller

Stash routes data via the controller and stores it there. A multi-hundred-MB or multi-GB stash (caches, node_modules, big artifacts) is slow and burdens the controller.

Using stash for data that should be artifacts/external

Stash is meant for small handoffs between stages of one build, not as general storage. Large or cross-build data belongs in artifacts or an external store.

How to fix it

Stash only small, necessary files

Narrow the includes to just what the next stage needs, and exclude regenerable directories.

stash name: 'app',
      includes: 'build/libs/*.jar',
      excludes: '**/node_modules/**,**/.gradle/**'

Move large data off the stash path

1. Use archiveArtifacts for build outputs you need beyond the run, or an external object store (S3) for large blobs.
2. Rebuild caches (node_modules, .gradle) on each agent instead of stashing them - pair with a cache plugin.
3. Keep stash for small cross-stage handoffs only.

How to prevent it

• Stash only the minimal files the next stage requires.
• Use artifacts or external storage for large or cross-build data.
• Rebuild dependency caches per agent rather than stashing them.

Related guides