Buildkite

Hybrid model: SaaS-hosted UI/orchestrator with self-hosted agents on your infrastructure. Designed for mega-monorepo CI at Airbnb, Shopify, Pinterest scale. Dynamic pipeline generation in any language, agent fleet management, build matrix support.

Overview

Buildkite: SaaS UX, self-hosted execution

Buildkite is the hybrid CI platform: a SaaS frontend with self-hosted agents. Founded in 2013 in Melbourne, it is niche but durable, the choice for mega-monorepo CI at Shopify, Airbnb, Pinterest, Etsy, Uber, PagerDuty, Cisco, Block (Square) and Canva. Its 2026 share is ~3-5% per JetBrains, concentrated in specific contexts.

Buildkite hosts the orchestrator, web UI, pipeline scheduler and build history; your agents do all the work on your infrastructure. The pitch: polished UX without giving up infrastructure control.

Where Buildkite wins

Mega-monorepo CI — 100k+ tests, 50+ services, 1000+ engineers, where static YAML breaks down and dynamic generation is essential. Shopify's monorepo CI is entirely Buildkite-driven
Full agent fleet control — Your instance types, cloud, spot/on-demand mix, custom AMIs and images, GPU, ARM and on-prem pools. Costs are infrastructure costs (spot saves 70%+), not marked-up minutes
Network access — Agents in your VPC reach internal databases, private registries and on-prem dependencies without VPN tunnels
Security and compliance — Build code never runs on someone else's infrastructure; clearer audit trail and attestation for regulated industries
Pipeline generation in any language — Bash, Python, Ruby, Go emit YAML to stdout, piped to buildkite-agent pipeline upload; no YAML-only DSL ceiling

Where Buildkite loses

Webhook-based SCM integration — PR comments and status checks work but feel less native than GHA on GitHub or GitLab CI on GitLab
Smaller ecosystem — ~200 plugins vs GHA's 25k actions; fewer answers online for non-standard problems
Operational responsibility — Autoscaling, monitoring, security updates and image management are yours: real work compared with hosted GHA
Pricing at scale — Per-build pricing scales with build count + seats; cheaper than per-minute SaaS at mega-scale, but not free

When to pick it

Mega-monorepo: 100+ services, 200+ engineers, dynamic pipelines essential — Small teams: value scales with size, and they pay coordination cost without monorepo benefits
Self-hosted execution with SaaS UX, instead of heavy Jenkins — Already on GHA / GitLab CI and it works: migration rarely justified
Heavy existing infrastructure: large EC2/GKE fleets, comfortable autoscaling agents — OSS projects: GHA is free, easier, more discoverable
Compliance needs without an on-prem requirement: isolation, audit trail, data residency

Three load-bearing concepts

Hybrid model — Buildkite hosts orchestration; you host execution. Cost model and security posture differ from fully SaaS competitors
Dynamic pipeline generation — Scripts emit pipelines at runtime: the model that makes mega-monorepos manageable
Agent fleets with queues and tags — Separate fleets per workload (x86, ARM, GPU, on-prem); jobs target them via agents: tags

Key concepts

pipeline.yml + dynamic generation: Static entry-point pipeline: wait inserts a synchronization barrier — all preceding steps must complete before any following steps start. block is a manual approval gate. agents: { queue: ... } targets a specific agent fleet. Dynamic generation pattern: Behavior: PR touches services/payments/* → generated pipeline has only payments-related steps. Other services aren't built. The same pattern scales to 200+ services.
Agent fleets and clusters: Agents are organized into clusters (logical groupings) with tags. Multiple fleets target different workloads. Setup an agent fleet on EKS via Helm: Multiple fleets for different workload types: Pipeline jobs target via agents: tags: Buildkite's scheduler matches: only agents with arch=arm64 in queue=arm-build pick up this job. Autoscaling. Buildkite ships an autoscaler component that watches queue depth and scales agent count accordingly. On EKS, integrate with Karpenter / cluster-autoscaler. Spot capacity: typical pattern uses spot instances for build agents (60-70% cost savings) and reserved for deploy agents (no interruption).
Plugins: Buildkite plugins are reusable Bash modules embedded in step definitions. Versioned via git tags. Plugins inject behavior at lifecycle hooks: pre-checkout, post-checkout, environment, pre-command, post-command, pre-artifact, post-artifact. Each hook is a Bash script. Common plugins: - docker — run command in a container - docker-compose — compose-based test environments - aws-assume-role — assume AWS role before command (OIDC support added 2023) - test-collector — upload JUnit results to Buildkite Test Analytics - artifacts — upload/download build artifacts - monorepo-diff — skip steps if no relevant files changed Authoring custom plugins: any git repo with a plugin.yml manifest plus hook scripts. Public plugins on github.com/buildkite-plugins, private plugins in your own repos. Plugin ecosystem (~200) is smaller than GHA actions (~25k) but covers most common patterns. Custom plugins are easy to author when needed.
Test Engine — timing-based test splitting: Buildkite Test Engine is a paid product that adds intelligent test splitting and analytics across CI pipelines. What Test Engine does: 1. Test runner executes; emits JUnit XML. 2. test-collector uploads results to Buildkite Test Analytics service. 3. Subsequent runs query Test Engine API: "given parallelism: 10 and these test files, what's the optimal split?" 4. Test Engine uses historical timing data to balance shards. Equivalent of CircleCI's circleci tests split --split-by=timing but cross-platform (works with any test runner that emits JUnit). Available on any CI platform via the Buildkite test-collector plugin, not just Buildkite the CI service. Knapsack Pro is a competing third-party product that provides similar timing-based splitting for any CI platform (GHA, GitLab CI, CircleCI, Jenkins). Use either if your CI doesn't have native timing-split. Test Analytics also provides: - Flaky test detection (auto-flag tests with inconsistent results). - Slowest tests dashboard. - Test pass/fail trends over time. - Build comparisons. For mega-monorepos with 100k+ tests, Test Engine is often the only practical answer for keeping CI duration manageable.
OIDC and secret management: Buildkite supports OIDC since 2023. Each job can request a JWT from Buildkite's OIDC provider, exchanged with AWS STS / GCP / Azure for short-lived credentials. The plugin requests an OIDC token from Buildkite and calls aws sts assume-role-with-web-identity. AWS IAM trust policy validates: Same security pattern as GHA, GitLab CI, CircleCI. By 2026 OIDC is the default; long-lived AWS keys in agent env vars are deprecated practice. Agent-level secrets (for things like SCM clone tokens, registry pulls) live on the agent host — environment variables in systemd unit, or mounted from K8s Secrets in pod spec. Pipeline jobs inherit these. For job-specific secrets (per-environment deploy keys), use OIDC + cloud secret manager (AWS Secrets Manager, HashiCorp Vault). Job assumes role; reads secret at runtime.

When to use it

Mega-monorepos (100+ services, 500+ engineers)
Need self-hosted execution + SaaS UX (Jenkins alternative without ops overhead)
Heavy infrastructure investment in custom CI compute (spot fleets, GPU pools, on-prem agents)
Compliance/regulatory needs requiring build code execution control
Dynamic pipeline patterns that don't fit static YAML

Interview questions

When does Buildkite win over GitHub Actions for a monorepo?
Walk through dynamic pipeline generation in detail.
Compare Buildkite to GHA + ARC (Actions Runner Controller).
Operating Buildkite agent fleets — autoscaling, spot, monitoring.
Quick-fire interview answers — Buildkite essentials.