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, verified May 2026. 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 |
|---|---|---|---|---|
| Developer | $0 | Up to 5 | 3 concurrent | Unlimited |
| Pro | $15 / user / mo | Unlimited | Unlimited | Unlimited |
| Enterprise | Sales-led | Unlimited | Unlimited | Unlimited |
# Pro is $19/user month-to-month if you do not commit annually. Enterprise adds SAML SSO, 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. Enterprise contract usually kicks in here for SAML and audit logs.
# 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 50,000 monthly build minutes, which a 20-developer team can easily reach if every pull request triggers a multi-stage pipeline.
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 $750 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 Pro is $15 per user per month on annual, $19 on monthly. That is a 21 percent saving for committing to a year. For a 25-developer team the annual commitment saves about $1,200 a year. For a 100-developer team it saves about $4,800. Most teams switch to annual within their first three months because the gap is large and the platform is sticky.
The cancellation policy on annual is straightforward: service continues through the paid period, no pro-rata refund for unused months, no automatic year-to-year escalation built into the standard contract. Enterprise contracts vary and typically include annual or multi-year terms with negotiated discounts in the 10-25 percent range off list.
Related comparisons and deep dives
Frequently Asked Questions
# click any question to expand