Reducing CI Build Times from 18 to 4 Minutes with Turborepo Remote Caching

Overview

A client running a monorepo of several Node.js services was seeing CI builds take 18 minutes on average. Most of that time was spent recomputing unchanged TypeScript projects and re‑bundling assets. We introduced Turborepo’s remote caching, which allowed each CI job to pull previously computed artifacts from a shared cache.

Baseline Measurements

| Metric | Value |
|--------|-------|
| Total CI duration | 18 min |
| Cache hit rate (local) | 12 % |
| CPU utilisation (average) | 45 % |
| Disk I/O (read/write) | 1.2 GB / 0.9 GB |

The low cache hit rate indicated that each job was rebuilding from scratch.

Introducing Turborepo Remote Caching

Turborepo provides a content‑addressable cache that can be stored locally and in a remote store (e.g., Vercel’s turborepo cache, Redis, or an S3 bucket). When a task finishes, Turborepo uploads the output hash and the artifact; subsequent runs with the same hash download it instead of re‑executing the task.

Implementation Steps

1. Add Turborepo – npm i -D turbo.
2. Create turbo.json with the pipeline definition and remote cache configuration.
3. Configure CI – install the Turborepo CLI, set the TURBO_TOKEN (or S3 credentials), and replace the old npm run build command with turbo run build --cache-dir=.turbo.
4. Warm the cache – run a full build on a dedicated “cache‑warm” job after each merge to ensure the latest artifacts are available.

Code Snippet

// turbo.json { "$schema": "https://turborepo.org/schema.json", "pipeline": { "build": { "dependsOn": ["^build"], "outputs": ["dist/", "!.next/cache/"] }, "test": { "dependsOn": ["build"], "outputs": [] } }, "remoteCache": { "enabled": true, "url": "https://my-remote-cache.example.com", "token": "${TURBO_TOKEN}" } }

Results

| Metric | Before | After |
|--------|--------|-------|
| Total CI duration | 18 min | 4 min |
| Cache hit rate (remote) | 12 % | 87 % |
| CPU utilisation (average) | 45 % | 68 % |
| Disk I/O (read/write) | 1.2 GB / 0.9 GB | 0.3 GB / 0.2 GB |

The remote cache reduced redundant work dramatically. Most builds now finish in under 5 minutes, and the pipeline cost dropped proportionally.

Takeaways

• Remote caching works best when tasks are pure (no hidden side‑effects) and outputs are declared explicitly.
• Warm the cache after every merge to keep the hit rate high.
• Monitor cache size; prune old artifacts to avoid uncontrolled growth.
• The same pattern applies to other monorepo tools (Nx, Bazel) – the principle is content‑addressable caching, not the specific CLI.

By treating the cache as a first‑class artifact, we turned a sluggish CI pipeline into a fast, predictable feedback loop.