We cut CI feedback time by 60% without faster runners

I started with a hardware question: should StratoFusion pay for faster CI runners?

The data pointed somewhere else. Our workflow was making independent checks wait for one another.

So we fixed the workflow before changing the hardware. Across the first eight optimized main runs, average CI feedback time fell from 14.7 minutes to 5.9 minutes, a 59.8% reduction on the same class of GitHub-hosted runner.

The bottleneck was the workflow

Tests, type checking, linting, the production build and rclone checks were running in sequence. A faster machine would have helped, but it would not have removed that queue.

We made four changes:

• ran quality checks, tests, the Next.js build and rclone checks in parallel;
• split the application tests into two deterministic shards;
• cancelled superseded branch and pull-request runs;
• kept one final required status so the release gate stayed simple.

The result was immediate:

Every optimized run finished in 5.1 to 6.7 minutes. Even the slowest beat the fastest run in the old workflow by more than three minutes.

Faster did not mean cheaper

Parallelism reduced the wait by doing more work at once. It also duplicated some setup across jobs.

Five of the eight optimized runs added security checks during the measurement window, so the before-and-after workloads are not perfectly identical. That extra coverage barely changed the critical path, but it increased total runner consumption.

The honest claim is therefore:

CI became about 60% faster for the developer. It did not become 60% cheaper to run.

That distinction matters when comparing runner providers. Wall-clock speed and billable runner time answer different questions.

Production now waits for the tested revision

The optimization also exposed a release-order problem: production could start deploying while CI was still running.

Now deployment begins only after successful push-triggered CI on main. The exact tested commit SHA follows the release through checkout, image tags and VM rollout.

Seven observed releases respected that gate. Three still stopped safely: one because active transfers did not drain, and two because the application failed its rollout health check. The latest deployments succeeded.

That is useful failure. CI proves the code and build boundary; deployment health checks prove whether that exact build is safe to run in production.

This is not a runner-platform comparison yet

We did not test faster-runner platforms such as Blacksmith, Namespace, Depot or WarpBuild. There is no affiliate relationship with any of them.

What we have proved is narrower: workflow design was the first bottleneck worth fixing. Buying faster hardware before removing unnecessary sequencing would have hidden part of the real problem.

A fair runner-platform pilot still makes sense. It should keep the optimized workflow constant, change only the runner, and compare equivalent runs for speed, runner consumption, reliability and cost.

Until then, the conclusion is simple:

Measure the critical path before buying your way around it.

Hardware may still help. It just did not deserve to be the first explanation.