Self-hosting CI
gets harder every month
More code is being written than ever. CI volume is outgrowing infrastructure that used to work.
CI demand comes in bursts
A busy hour can leave jobs waiting, while a quiet one leaves machines idle.
Demand changes by the minute
Bursts fill the queue
Idle machines cost money
Why do jobs queue even with autoscaling?
You wait for machines
Jobs queue while each new machine starts and registers, which can take minutes.
“Our self-hosted runners were having autoscaling issues and they’d be in queue for 5, 10 minutes. People would report that.”
LangChain, self-hosted runners on GCPYou compete for capacity
The instance type you request can be out of stock, or you hit your vCPU quota. Either way, jobs stay queued.
Arian van Putten@ProgrammerDude
At the start of the year our self hosted CI runner cluster would get m8 instances with a 90 percent success rate. It has dropped to 15 percent
Sep 5, 2026You pay to avoid waiting
A warm pool skips the wait, but you keep paying for it when CI load drops.
“I got sick of spending the time babysitting the warm pool and just took the scaling policies out, but it means you’re provisioning for the peaks.”
Megaport, self-hosted runners on AWSYou lose spot machines mid-job
Spot instances are cheap until they’re reclaimed, and your job is cut off mid-run.
“I’m spending a whole quarter on it. If this ends up being cheaper than all of this, then I can spend my time on actually useful measures instead of tuning a GitHub runner thing.”
Amplitude, ARC + Karpenter on Kubernetes
The biggest cost is your team’s time
You pay for machines and the time your team spends maintaining them.
GitHub
- Handling API rate limits
- Updating runner versions
- Handling webhook delivery
Capacity
- Tuning autoscaling policies
- Asking AWS for quota bumps
- Isolating noisy neighbors
- Spot interruptions killing jobs mid-run
Images and caches
- Upgrading toolchains
- Patching base image CVEs
- Maintaining OS images
- Managing Docker and runtime caches
Network
- Avoiding Docker Hub limits
- Maintaining egress allowlists
Observability
- Tracking queue times
- Attributing job costs
- Measuring CPU and memory
How long do jobs wait for a machine?
Two customers moving off self-hosted ARC, anonymized.
Queue time
How long a job waits between being queued and a runner picking it up.Jobs waiting over a minute
The share of jobs each week that waited more than 60 seconds for a runner.Queue time
How long a job waits between being queued and a runner picking it up.Jobs waiting over a minute
The share of jobs each week that waited more than 60 seconds for a runner.Keep your workflows, let us manage everything else
Install the GitHub App and move the jobs you pick with a one-line change. Switching back is a simple revert.
Workflows
Your workflow files stay in your repo. You choose which jobs move to Blacksmith.
Secrets
Secrets stay in GitHub and work with Blacksmith runners just as they do with your self-hosted runners.
Permissions
Who can run what, branch protection, and required reviews all stay in GitHub.
Runners
High-performance, purpose-built compute with unlimited concurrency at no extra cost.
Caches
Dependencies, Docker layers, container images, and Git checkouts are cached with zero configuration.
Operations
We patch CVEs in base images, keep toolchain and dependency versions current, and pull unhealthy machines before your jobs land on them.
Observability
Every job’s logs, resource usage, and test failures in one place, with no agents to install.
Stop managing your own caching
Zero-config caching skips as much of every job as possible. What’s left runs on the fastest, purpose-built infrastructure.
- Git cacheCheckout: 18s without cache, 3s with cache
- Container imagesInitialize containers: 12s without cache, 9s with cache
- Machine imagesInstall dependencies: 42s without cache, 7s with cache
- Build cacheCompile and test: 48s without cache, 8s with cache
- Docker layersBuild and push: 54s without cache, 9s with cache
How did job runtimes change after moving to Blacksmith?
Application builds
- 2xlarge x86 → 32 vCPU x86
- 30% less time
Package unit tests
- 2xlarge x86 → 32 vCPU x86
- 46% less time
Measured across 28.9K selected job runs, August 17 to September 28, 2026.
Go build + security scan
- Small x86 → 2 vCPU x86
- 80% less time
API integration tests
- Large x86 → 4 vCPU x86
- 27% less time
Measured across 4.3K selected job runs, June 29 to July 12, 2026.
Blacksmith by the numbers
