---
title: "Buildkite's Hybrid CI Model: Hosted Runners vs Self-Hosted Agents"
description: "Buildkite splits CI into a hosted control plane and agents you run on your own machines. This comparison weighs that self-hosted agent model against fully hosted runners so you can pick the right fleet."
---

# Buildkite's Hybrid CI Model: Hosted Runners vs Self-Hosted Agents

**Type:** [Comparison](https://yomu.fyi/visual-explainers/category/comparison.md)

![A two-column comparison diagram: a shared control-plane strip at the top sends arrows into a hosted-runners column and a self-hosted-agents column, each with three labeled cards, above a decision strip listing hardware control, burst tolerance, and ops budget.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/25ee2f1f-b681-41b3-a185-4c365a0bbd77/image-ced111c6-138a-4e58-a000-701d68e8471e.webp)

> Buildkite splits CI into a hosted control plane and agents you run on your own machines. This comparison weighs that self-hosted agent model against fully hosted runners so you can pick the right fleet.

## Explanation

Buildkite separates the part that decides what to run from the part that runs it: a hosted control plane queues and routes work, while agents on your own hardware pull jobs and execute them. The Shopify iOS setup shows the self-hosted side in practice, where agents boot disposable macOS VMs on MacStadium hardware, upload artifacts, and delete the VM afterward. The hosted alternative trades that control for speed of setup, with a vendor supplying the machines and a smaller operational burden. The comparison matters because the choice fixes who owns capacity, how quickly you can absorb a burst, and how much of your team's time goes into maintaining build infrastructure.

## FAQ

### Why would a team run Buildkite agents on its own hardware instead of hosted runners?

Because the control plane only schedules work while the agent executes it, build code, secrets, and artifacts stay on machines you control. Shopify's iOS pipeline boots disposable macOS VMs from layered images and deletes them after each job, which removes a shared-storage single point of failure and lets the fleet scale horizontally.

### What breaks first when self-hosted agent demand spikes?

Queue time. Shopify's Buildkite fleet runs roughly 350 iOS jobs an hour, but capacity is still adjusted by hand, so spiky demand shows up as longer waits rather than errors. Treat queue depth and wait time as early pressure signals and defer lower-priority work before saturation spreads.

### When is a fully hosted runner the better trade?

When you have no Mac hardware, a small team, or no appetite for maintaining build machines. Hosted macOS agents remove the need to own the hardware and pair well with golden path templates that scaffold the pipeline for developers, at the cost of less control over the underlying fleet.

**Tags:** [Anka](https://yomu.fyi/topic/anka.md), [Buildkite](https://yomu.fyi/topic/buildkite.md), [CI/CD](https://yomu.fyi/topic/ci-cd.md), [Developer Experience](https://yomu.fyi/topic/developer-experience.md), [macOS](https://yomu.fyi/topic/macos.md), [TeamCity](https://yomu.fyi/topic/teamcity.md)

## Related reading

### [Build golden path CI/CD workflows in Red Hat Developer Hub](https://yomu.fyi/post/build-golden-path-ci-cd-workflows-in-red-hat-developer-hub.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Rishabh Singh
- Published: Sep 25, 2026
- Type: Tutorial

This article continues a series on Red Hat Developer Hub, describing how platform engineers create golden path templates to standardize developer workflows. The sample template scaffolds a Go project with a Tekton pipeline, Argo CD manifests, a devfile, and catalog-info.yaml containing annotations that map to enabled plug-ins. Developers use the template from the self-service screen, completing a form to specify application metadata, image registry, OpenShift details, and Git repository. After scaffolding, automated CI/CD is triggered by a Git commit, and developers monitor Tekton PipelineRuns, Argo CD sync status, container images from Quay, and Kubernetes resources from tabs within Developer Hub. The article provides step-by-step instructions for both platform engineers and developers, including template authoring, registration, scaffolding, and subsequent observability.


### [How Intelligent Load Shedding Prevents Cascading Failures in Tier-0 Systems](https://yomu.fyi/post/how-intelligent-load-shedding-prevents-cascading-failures-in-tier-0-sy.md)
- Company: [Salesforce](https://yomu.fyi/company/salesforce.md)
- Author: Scott Nyberg
- Published: Sep 24, 2026
- Type: Problem & solution

Salesforce’s Cloud Atlas team operates a globally distributed identity data store that must maintain five nines of availability, roughly five minutes of downtime per year. The team redesigned service protection after per-instance rate limiting proved insufficient under autoscaling and increasingly bursty, unpredictable agent-driven traffic. The new approach combines intelligent load shedding, which monitors queue time as an early indicator of system pressure before error rates spike, with coordinator-free global quota management. Servers independently measure and share customer usage to throttle noisy tenants without a centralized coordinator, preventing one customer’s surge from affecting others. This design prevents cascading failures by shedding lower-priority work before overload spreads across dependent services, ensuring graceful degradation rather than widespread outage.


### [Scaling GitOps: The "pull" architecture for global fleets](https://yomu.fyi/post/scaling-gitops-the-pull-architecture-for-global-fleets.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Jann Fischer, Pradeep Surisetty, Sho Weimer, Jan Hutař, Alex Krzos, Mike Ng
- Published: Sep 24, 2026
- Type: Benchmark

Red Hat conducted a performance and scale test of the argocd-agent pull architecture for GitOps, using 42 physical machines, 500 spoke clusters, and software including OpenShift 4.21 and OpenShift GitOps 1.20. The pull model decentralizes reconciliation to lightweight agents on each managed cluster, which pull configurations from a central hub, improving security by eliminating inbound administrative ports and reducing cross-cluster network traffic by up to 80%. In the bootstrap scenario, generating and syncing 31,200 applications across 480 clusters completed in 13 minutes 3 seconds, while the sync-to-commit scenario, which includes a polling delay, took 13 minutes. The test revealed bottlenecks including Kubernetes API limits on the hub, informer processing slowdowns causing watch restarts, event writer retry issues under load, and ApplicationSet controller RAM consumption. The team also deleted all 31,200 applications in 4 minutes 53 seconds using cascading deletion, and the insights are informing future OpenShift GitOps releases.


### [Designing the Kotlin Multiplatform and TeamCity Integration](https://yomu.fyi/post/designing-the-kotlin-multiplatform-and-teamcity-integration.md)
- Company: [Jetbrains](https://yomu.fyi/company/jetbrains.md)
- Author: Bozidar Rakicevic
- Published: Sep 24, 2026
- Type: Problem & solution

The post describes the design of a new TeamCity integration for Kotlin Multiplatform (KMP) developers building iOS apps. The integration addresses common pain points: iOS builds require macOS infrastructure, Apple signing is complex, and there is no guided path from IDE to CI/CD. The solution provides a progressive onboarding flow within the IDE, starting with a tooltip after the first Git push. The flow generates four configuration files (teamcity.yaml, Fastfile, Appfile, Gemfile) and runs a build and tests on a hosted macOS agent, then guides the developer through a single form for Apple signing and TestFlight publishing, and finally automates the pipeline on GitHub pushes. TeamCity Cloud provides hosted macOS agents and a free starting tier, so no Mac is required. The design was validated through usability sessions and focuses on meeting the developer at the right moment with minimal configuration.


### [Scaling iOS CI with Anka](https://yomu.fyi/post/scaling-ios-ci-with-anka.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: Sander Lijbrink
- Published: Jul 11, 2018
- Type: Problem & solution

Shopify needed a unified CI/CD system that could give iOS developers the same reliable, disposable build environments already used for Linux and Android projects. An earlier VMware ESXi setup used a shared storage area network, but its maintenance burden and write throughput limit created stability and scalability problems. The replacement uses Anka, a Docker-like macOS virtualization layer built on Apple’s Hypervisor.framework: one Core i7 Mac Mini runs one VM with local storage, while layered images are pushed to registries and pulled across two MacStadium data centers. Buildkite agents clone temporary snapshots, boot suspended VMs in under a second, run steps, upload artifacts, and delete the VMs afterward. Shopify reports about 350 iOS build jobs per hour for roughly 60 iOS developers, with easier Xcode and macOS upgrades, no shared-storage single point of failure, and horizontal scaling, although capacity remains manually adjusted and spiky demand can increase queue times.