Buildkite pricing per user, 2026
./pricing --per-user --unlimited-builds
Buildkite is one of the few major CI/CD platforms that does not charge by build minute. The price is per seat, the builds are unlimited, and the agents that actually run your jobs are yours to host. That sentence is the entire Buildkite pricing model, and it is also the source of every misunderstanding that turns into a surprise cloud bill. This page works through what unlimited really means, what a typical team pays at three sizes, and where the BYO-compute model wins or loses against per-minute alternatives.
Pricing claims here come from the public Buildkite pricing page, re-verified June 2026 (Pro moved to $30 per user; the old Developer plan is now the single-user Personal plan). Comparison numbers reference the equivalent vendor pricing pages for GitHub, GitLab and CircleCI.
The three Buildkite plans in 2026
| Plan | Price (annual) | Users | Agents | Build minutes |
|---|---|---|---|---|
| Personal | $0 | 1 user | 3 concurrent jobs | Unlimited |
| Pro | $30 / user / mo | Unlimited | Unlimited | Unlimited |
| Enterprise | Sales-led (30-user min) | Unlimited | Unlimited | Unlimited |
# Optional Buildkite-hosted agents bill per minute on top of seats: Linux $0.013-$0.052/min, Mac M4 $0.18-$0.36/min. Enterprise adds SAML SSO, SCIM, audit logs, advanced RBAC and uptime SLAs.
What does "unlimited builds" actually mean?
On a per-minute CI platform like GitHub Actions, every build burns a metered resource. You pay for the minutes your jobs spend running on hosted runners. Free allowances soften the early bill, but the relationship is direct: more builds equals more cost, and the cost is the build itself.
On Buildkite, the platform charges you per seat. Buildkite is the orchestrator: it stores your pipeline definitions, queues jobs, distributes them to agents, collects logs, and presents the UI. None of that work happens on Buildkite's compute when your pipeline runs. The actual build steps execute on agents, which are processes you run on your own infrastructure. A Buildkite agent is a small Go binary that polls the Buildkite API for work, downloads the assigned job, runs it locally and reports back. The agent can live on a t3.medium EC2 instance, a Mac mini, a Raspberry Pi, a Kubernetes pod or a colocated bare-metal server. Buildkite never sees the build, only the metadata.
Because Buildkite is not paying for the compute, it has no incentive to meter it. Every plan includes unlimited builds, unlimited build minutes, unlimited concurrency at the platform level, and unlimited agents. You can run a thousand builds an hour for the same seat fee as one build a week. The constraint on throughput is your agent fleet, not Buildkite's API limits.
That is the BYO-compute model. It is the same architectural choice Jenkins made twenty years ago, dressed up with a clean control plane. The trade-off is honest: you pay seat fees instead of minute fees, and in exchange you take on the operator role for the actual compute. If your team is comfortable with cloud VMs, autoscaling groups, or Kubernetes, BYO-compute is cheaper at scale. If your team prefers a single bill from a single vendor, per-minute is administratively simpler even if the dollar amount is higher.
The real total: seats plus compute, three team sizes
Headline seat pricing is misleading on its own. The real Buildkite total combines seats and cloud compute. The numbers below assume Linux 2-core agents on AWS t3.medium on-demand pricing (around $30 per agent per month if always on, or about $14 per month using Spot). Real costs vary with region, instance family, and how aggressively you scale agents down at night.
Pro at 5 users plus two always-on Linux agents handles 30-40 builds per day at 6-minute average without queueing.
Pro at 25 users plus six always-on Linux agents handles 200 builds per day at 8 minutes. Add a Mac agent if you ship iOS, that adds about $250 more.
Pro at 100 users plus 20 agents (mix of always-on and Spot) handles a thousand builds per day. At this seat count an Enterprise contract with volume discounts almost always beats list price.
# Cloud-compute estimates use AWS t3.medium on-demand rates from the AWS EC2 pricing page. Spot pricing cuts these in half if your jobs tolerate restarts.
Where the per-user model wins
The Buildkite economics are unusual enough that it is worth being precise about the conditions under which per-user-plus-BYO beats per-minute. Three patterns show up repeatedly.
First, high build volume relative to headcount. A small platform team running CI for hundreds of services builds dozens of times per developer per day. On a per-minute platform that compounds linearly. On Buildkite the seat fee is fixed and the compute is yours, so you pay for capacity rather than usage. The crossover point for a Linux-only workload is roughly 100,000 monthly build minutes at GitHub Actions' post-January-2026 rate of $0.006 per minute, a level that platform teams running CI for hundreds of services do reach.
Second, long-running parallel jobs. A test suite that takes 90 minutes split into 12 parallel agents is barely affordable on per-minute platforms (you bill for 90 minutes times 12 streams). On Buildkite the same 12-way parallelism uses 12 agents running concurrently for a few minutes each. If those agents are running anyway because you sized your fleet for peak throughput, the parallelism is free.
Third, mixed-architecture builds. Teams shipping iOS apps need macOS runners, which are priced at a 10x multiple on per-minute platforms. Self-hosted Mac mini agents on Buildkite cost the same as Linux agents at the seat level, plus the one-time Mac mini purchase ($600-$1,200 depending on spec) and a small monthly electricity bill. For teams running serious mobile pipelines, this single difference can dwarf the rest of the cost analysis.
Where per-user loses to per-minute
Buildkite is not always cheaper. Three patterns make per-minute platforms the better deal.
Low build volume, large team. A 50-developer org that ships once a week and runs only smoke tests on PRs is paying $1,500 in Buildkite seat fees regardless of usage. The same team on GitHub Actions Team plan would pay $200 in seats and stay inside the free Linux-minute allowance, total bill around $200. Per-minute wins until build volume catches up to the seat cost premium.
Bursty workloads that idle. If your CI demand is concentrated in two-hour spikes once a week (overnight integration tests, for example), per-minute is more efficient than always-on agents. Spot instances narrow the gap but do not close it. You can autoscale Buildkite agents down with the official scaler, which helps, but the operator complexity is real.
Single-pipeline orgs without ops budget. Buildkite assumes you have someone who can size, operate and patch the agent fleet. A two-engineer shop running their first CI pipeline often finds the operator load higher than the dollars saved. We have seen teams pay 30 percent more on GitHub Actions specifically to avoid the agent-management role.
Annual versus monthly billing math
Buildkite's public pricing page lists a single Pro rate of $30 per active user per month and does not publish a separate annual discount. The lever for reducing the per-seat price is the Enterprise tier: it requires at least 30 users, is contracted annually or multi-year, and includes negotiated volume discounts. Teams approaching 30 seats should price both options before renewing at list.
Billing is per active user, so seats are not licences you buy in advance: a contributor who triggers builds in a month is an active user that month. Teams with many occasional committers should factor that into the comparison, because per-minute platforms do not charge for inactive contributors either.
Related comparisons and deep dives
Frequently Asked Questions
# click any question to expand