Vercel Moved New Pro Teams to $0.0035 Elastic Build Pricing. Here's What That Costs a Side Project in 2026.
Vercel Moved New Pro Teams to $0.0035 Elastic Build Pricing. Here's What That Costs a Side Project in 2026.
Vercel's new default for Pro teams is "Elastic" build machines: instead of picking a fixed-tier box and eating whatever build time it takes, Vercel now auto-scales the machine per build and bills you $0.0035 per CPU-minute for it. It went generally available in April 2026, not some quiet summer sneak-in, and it changes a line item that most solo builders have never once looked at on their invoice. I went and pulled the actual numbers, because "per CPU-minute" means nothing until you multiply it by how you actually deploy.
What actually changed, and when
Elastic build machines shipped in beta on March 24, 2026 and hit general availability on April 14, 2026, becoming the default for all new Pro and Enterprise teams. That's straight from Vercel's own changelog, not a third-party guess. A day later, on April 15, Vercel cut Turbo machine pricing 16% and unified everything — Standard, Enhanced, Turbo, and Elastic — under one rate: $0.0035 per vCPU per minute of build time, rounded up to the nearest minute.
Here's the part that's easy to miss. Per Vercel's own pricing docs, "builds on Standard build machines are only billed when on-demand concurrency is enabled or Elastic build machines are selected." Translation: if you were on the old default (Standard, sequential builds, no on-demand concurrency), your build minutes were effectively free, folded into the base Pro subscription. Elastic changes that. Once your team defaults to Elastic, every build gets metered, always. That's the real shift — not the per-CPU-minute rate itself, but the fact that builds go from mostly-unbilled to always-billed for anyone who lets the new default stand.
The CPU-minute math, spelled out
Vercel's machine tiers: Standard is 4 vCPUs at $0.014/minute, Enhanced is 8 vCPUs at $0.028/minute, Turbo is 30 vCPUs at $0.105/minute. Elastic scales anywhere from 4 to 30 vCPUs depending on what your build actually needs, and it's billed the same way — vCPUs times minutes times $0.0035. Vercel says roughly 80% of projects that tried Elastic during the beta ended up on a smaller, cheaper machine than they'd manually picked, while the remaining 20% got auto-upgraded to something bigger and faster. Both of those are billed differently, and neither is the flat rate you were used to.
Run the numbers on a build that takes 2 minutes 34 seconds on an Enhanced machine: that rounds up to 3 minutes, times 8 vCPUs, times $0.0035, which is $0.084. Cheap. But swap that same build onto a Turbo-sized 30 vCPU assignment and you're at $0.315 for the same wall-clock time. The rate is fixed; the machine size Elastic picks for you is not, and that's the variable that actually moves your bill.
Running this against a real solo project
Take an Astro 5 site like this one — static output, a Markdoc content collection with a few hundred posts, nothing exotic. A clean build on CI lands somewhere in the 60-to-90-second range in my experience with similar-sized static sites, so let's call it 90 seconds, rounding up to 2 minutes for billing.
If Elastic assigns this a Standard-class machine (4 vCPUs, which is plausible for a static build with no heavy type-checking or bundling), that's 2 × 4 = 8 CPU-minutes per build, or $0.028. During an active development week — say 15 deploys a day between preview and production pushes, which is realistic if you're iterating fast — that's $0.42 a day, or roughly $8-9 for a 20-day active month. That's noise next to the $20/month seat fee.
Now assign that same build a Turbo-class machine instead, which can happen if Elastic decides your project benefits from more parallelism: 2 × 30 = 60 CPU-minutes, or $0.21 per build. Same 15-builds-a-day pace pushes you to roughly $63/month just in build charges — more than three times the seat fee, for a project that used to cost effectively nothing to build under the old Standard-and-unmetered default. That's the scenario worth watching, and it's the one third-party pricing calculators tend to gloss over because they assume a single fixed machine size instead of Elastic's actual variability.
Vercel Pro itself is $20/month per seat and comes with $20 of monthly usage credit plus 1 TB of Fast Data Transfer and 10 million Edge Requests included, per Vercel's current docs. That credit covers builds, functions, image optimization, and everything else usage-based, pooled together — it's not a separate build allowance. For most static or low-traffic Astro/Next side projects, build costs alone won't blow through that credit. But if you're also running Fluid Compute functions, doing image transforms, or serving meaningful traffic, builds are now competing with all of that for the same $20.
Speaking of Fluid Compute: this stacks on top of the Active CPU pricing model Vercel introduced back on June 25, 2025, which only charges for CPU time your code is actively executing — not the idle milliseconds while a function waits on a database call or an API response. Vercel's own numbers put Active CPU at $0.128/hour and Provisioned Memory at $0.0106/GB-hour, with up to 90% savings claimed for I/O-heavy workloads like AI inference calls that spend most of their time waiting, not computing. If your side project is mostly waiting on OpenAI or Anthropic API responses, that part of the bill genuinely got better. Builds are the part that got more visible, not the runtime.
Cloudflare and Netlify aren't standing still
I went looking for confirmation that Cloudflare Pages capped its free-tier bandwidth at 100GB/month in mid-2026, because that claim shows up in a few pricing round-ups. I couldn't verify it against Cloudflare's own docs. As of Cloudflare's current Workers/Pages pricing page (last updated July 7, 2026), there are explicitly no data transfer or bandwidth charges on either the Free or Paid plan, and requests to static assets are called out as "free and unlimited." If Cloudflare tightened this at some point, it's not reflected in what they publish today, so treat that 100GB figure as unconfirmed rather than current fact.
Netlify's move is real and dated: on April 14, 2026, Netlify's own changelog confirms it shifted to credit-based pricing across the board. Pro is $20/month for 3,000 credits, with a production deploy costing 15 credits — that's about 200 deploys included before you touch overage, plenty for a solo project even during a heavy sprint. Netlify has also been pushing hard on "composable architecture" positioning in its own blog and webinars, aiming at enterprise teams stitching together CMS, commerce, and auth providers rather than solo builders — worth knowing if you're picking a platform based on where the roadmap is headed, not just this month's price sheet.
What I'd actually do
If you're running a static Astro or Next.js site with a normal deploy cadence — a handful of pushes a day, nothing that trips heavy type-checking or bundling — Elastic's per-CPU-minute billing is very likely cheaper or a wash compared to what you were paying before, and Vercel's own beta numbers back that up for the majority of projects. I wouldn't panic-migrate off Vercel over this line item alone. I moved this blog's hosting off Vercel entirely, onto a flat $5/month Hetzner box, but that was about wanting boring, predictable infrastructure costs in general, not a reaction to this specific pricing change.
Where I'd actually pay attention: if your project has a build step that's CPU-heavy — a big Next.js app with lots of static generation, heavy TypeScript compilation, or a monorepo — check your build machine assignment in the dashboard under Build Diagnostics before you assume Elastic is saving you money. If Vercel bumped you to a Turbo-class machine to keep build times down, you could be paying three to four times what a Standard machine would have cost for the same job, and you won't notice unless you go look. Pin the machine type manually if you want a guaranteed number instead of a variable one.
Here's the honest counter to my own argument: I could be wrong about how this nets out in practice, because the actual mix of project sizes on Vercel Pro isn't public data, and Vercel's "80% saved money" figure is self-reported from their own beta cohort, not an independent audit. If your builds skew toward the CPU-heavy 20%, this change is a real cost increase dressed up as an efficiency win, and the fix is the same either way: look at your own build minutes and machine assignment instead of trusting the average.
Author
Lukas
@lukcombinator