The Problem: Releasing Next.js Slowed Down

Next.js passed 4 million npm downloads this year and now counts 2,400+ contributors. That scale puts pressure on the core team at Vercel to keep development, testing, build, and release workflows manageable. Adding Rust to Next.js core brought real performance gains for users, but it also made publishing new releases slower because compiling Rust binaries for multiple platforms takes significant CI time.

Vercel's solution was to adopt Turborepo Remote Caching, which cut publish times by 80%.

Why Incremental Caching Was Not Enough

SWC—an extensible, Rust-based platform for the Web—is bundled into the Next.js package with extra transforms for React projects. That means Next.js users don't need custom configuration for common transformation tasks. But building those binaries for Windows, Mac, and Linux inside CI was the main culprit behind slow releases.

Earlier attempts to mitigate the cost had only limited impact:

  • Committing binaries to the repo made testing easier but bloated repository size and hurt git clone times.
  • Switching to development binaries (which build faster) eliminated the need to commit production binaries but didn't speed things up enough.
  • Caching dev builds in CI produced only moderate gains because cache limits caused frequent purges, resulting in high cache miss rates.

Worst of all, platform handling differences could still cause failed canary and stable publishes.

How Turborepo Remote Caching Solved It

Turborepo addressed three key problems that previous approaches couldn't handle together.

Task Management for Per-Platform Binaries

Turborepo caches tasks based on their inputs—source code, dependencies, environment variables, and other arguments. Since builds use a --target flag to produce binaries for each supported platform, Turborepo's hashing ensures the cargo build for one platform never accidentally picks up a cache from another.

No More Cache Purges

The hashes Turborepo stores are tiny relative to the actual build artifacts. That means Vercel doesn't have to purge the cache when space runs low. Once an SWC build has been performed, it can be restored later regardless of how many other build variations have happened in between.

Eager Pre-Seeding of the Remote Cache

Cache misses still happen whenever SWC code changes, which would slow down canary publishes. To work around that, Vercel set up a GitHub Action that eagerly builds SWC binaries as soon as code changes land. Those eager builds have two side benefits: they're non-blocking, so iteration continues without waiting, and build failures are caught early instead of surfacing during the publish process.

Results and Iteration Speed

After custom scripting to handle the specifics of building for FreeBSD and to avoid cache invalidation when only package versions change, Vercel reports an 80% drop in publish times when hitting the Turborepo Remote Cache. The improvement shortens the feedback loop for both cores—the Next.js team publishes faster, and users receive new features and bug fixes sooner.