Build minutes: what a deploy costs on GitHub Actions and vendor builders at 10 to 500 deploys a month

A push-to-deploy pipeline bills for its builds somewhere: per minute on a CI runner, per CPU minute on a platform, or per deploy. We took current prices from the vendors' own pages and worked out what 10, 50, 100 and 500 deploys a month cost at build lengths of 3 and 10 minutes.

Short version: for most small teams the build bill is tiny. 100 deploys of a 3-minute build come to $1.80 on GitHub's 2-core Linux runner, $4.20 on Vercel's Standard machine and nothing beyond the included minutes on Render's Pro plan. Machine size matters far more than deploy count: the same build on Vercel Turbo costs $31.50 if it takes as many minutes. Our own measured builds also showed that rounding up to the minute decides what a very short build costs.

The rates we used

A 3-minute build

List price per month. GitHub's included usage and Vercel's credit aren't taken off, because both are shared with other work. Render's included minutes are taken off, because they only cover pipeline minutes.

A 10-minute build

Comparing rows assumes the build takes the same minutes everywhere, and a 30-CPU machine won't take as long as a 2-core one if your build can use the extra cores. A bigger machine saves money only when it's faster by more than its price ratio: GitHub's 8-core costs 3.7 times the 2-core, so the build has to run 3.7 times as fast to cost the same. Many builds spend a good part of their time on network and single-threaded steps and won't get there, though you may still pay for the shorter wait.

Netlify's flat price flips the usual logic. It costs more than GitHub's 2-core per deploy for builds under about 17 minutes, and more than Vercel Standard for builds under about 7 minutes, and it's cheaper past those points. It also counts production deploys only, so frequent previews cost nothing on that line.

What our measured builds would be billed

We already had real timings from our buildpack and Dockerfile test, run on two small apps with 2 CPUs. This is what those build times become once a vendor rounds up to the minute. The last two columns add the first pull of the images, for a runner that starts empty each time and has no build cache, as many hosted CI runners do unless you set up caching.

With a working cache, every one of our rebuilds rounds to one minute, so the 7 s a buildpack adds costs nothing here. An empty runner is different: 100 deploys on GitHub's 2-core would cost $0.60 for the Python Dockerfile against $4.20 for the Python buildpack, and $1.80 against $5.40 on Java. That's a small sum, but it's also about six extra minutes of waiting on every deploy.

Treat that table as a guide to the shape of the bill. These times come from our Mac mini on our link, not from a vendor's machine, and a real CI job also spends time on checkout, setup, tests and pushing the image, which we didn't time. Those steps usually matter more than the build itself, and they're billed at the same rate.

Where a self-hosted runner pays off

Self-hosted runners are still free in GitHub Actions, since the planned $0.002 a minute charge was postponed. So the question is how many hosted minutes one server replaces. Here's a $20 a month server, which is our assumption, against GitHub's rates:

Against a 2-core runner you need around 333 ten-minute builds a month to cover the server, and that's before your own time patching it. The included $12 on a Free account pushes that further out. Most small teams never get there on price alone. The case gets better if you already pay for larger runners, need caches that stay on disk, or are building something with heavy dependencies where the warm disk saves real minutes.

Keep the risk in mind too: GitHub warns against self-hosted runners on public repositories, since a pull request can run code on your machine. And the postponed charge could still come back. At $0.002, 5,000 minutes a month would add $10.

What to do with this

If you pay under $5 a month for builds, leave them alone and spend the time elsewhere. If the bill has started to matter, look first at which machine type you're on, because that moves the price by as much as 15 times on Vercel. Then look at the minutes you're paying for: caching dependencies and skipping builds for changes that don't touch the app usually save more than moving vendors.

What this doesn't cover

These are list prices read on 4 November 2026, excluding tax, on the plans named. We didn't run a build on any of these vendors, so we can't say how fast each machine is. Render's pages don't say how it rounds a pipeline minute, so we used plain minutes. Plan fees, storage for images and artifacts, bandwidth and concurrency add-ons aren't in the tables. We left out Railway because we couldn't establish from its pages whether build CPU counts as usage. Build times from the earlier test are small apps on arm64 with other work running on the machine.

Related: Deploy platform price changes in 2026 dates the changes behind these rates, and Rebuild time when only your code changes shows how Dockerfile layers change rebuild time.