← Back
ENGINEERING NOTE4 min read

Bun 1.4 Migration — Visual CI Evidence

A visual companion to the Bun migration case study, using measured GitHub Actions timings and pipeline diagrams.

Bun
CI/CD
GitHub Actions
Performance
Next.js
Engineering

Results at a glance

MetricBeforeBun migrationChange
Dependency install15.26s8.99s~41% faster
Next.js compile10.3s9.8sNearly unchanged
Initial whole CI49.5s38.5s~22% faster

The clearest improvement appeared in dependency installation and tooling overhead, not in the Next.js compiler itself.

1. What changed?

The original model was Node.js + npm.

The target was a single Bun-oriented toolchain:

package-lock.json  →  bun.lock
npm ci             →  bun install
node scripts/...   →  bun scripts/...
npm-centered CI    →  Bun 1.4

Next.js and Turbopack were not replaced. Bun became the surrounding package, runtime, test, and build tooling layer.

2. The first attempt failed

The first change updated the build command:

- "build": "next build && node scripts/generate-rss.js"
+ "build": "next build && bun scripts/generate-rss.js"

The CI workflow installed Bun, but the GitHub Pages deployment workflow did not.

The failure was not a Next.js compiler failure. It was a runtime provisioning mismatch between the source and the deployment environment.

The fix was to explicitly install and verify Bun 1.4 in the Pages workflow.

3. Dependency installation improved materially

The measurements came from the same GitHub-hosted ubuntu-24.04 runner.

npm ci        15.26s
bun install    8.99s

That is about 6.27 seconds saved, or roughly 41% for dependency installation.

4. Next.js did not suddenly become much faster

The Next.js compile step stayed in roughly the same range.

This is expected. Bun did not replace the Next.js compiler. The main gain was around package and tooling overhead.

5. The whole CI job improved

The initial migration comparison was:

Before  ≈ 49.5s
After   ≈ 38.5s

That is roughly 11 seconds, or about 22%, while the Bun workflow also added Bun-native validation such as bun test and a bundle smoke test.

6. The next optimization was pipeline design

After the migration, the same production build was being performed in both PR validation and Pages deployment.

That redundancy was removed.

The responsibilities are now explicit:

PipelineQuestion answered
PR CIIs this change safe to merge?
Pages DeployCan this exact main revision be built and deployed?

7. Final toolchain model

The migration therefore was larger than a runtime swap:

Runtime
+ Package Manager
+ Lockfile
+ Automation
+ Test
+ Build tooling
+ CI responsibilities

Final evidence

Dependency install   15.26s → 8.99s   ≈ 41% faster
Initial whole CI     49.5s → 38.5s    ≈ 22% faster
Next.js compile      10.3s → 9.8s     ≈ little change

The important engineering result is not just the numbers. It is the sequence:

Failure

Diagnosis

Runtime fix

Measured migration

Pipeline simplification
Related OSS