Skip to main content

Vercel Repriced Four Times in 20 Months — Here's What Each One Did to Your Bill

11 min readDora NodaDora Noda
Share

Vercel has repriced four times since mid-2024. Each announcement used the same headline — simpler, fairer, cheaper — and each one made next quarter's bill harder to forecast than the last.

If you run a Next.js app with ISR on Vercel's Pro tier, the same mid-traffic workload that cost a predictable $20 per seat plus a single overage knob in early 2024 now bills across six separately metered dimensions, with a $20 usage credit that obfuscates where the money actually goes. Render cut included egress from 100 GB to 5 GB on Hobby in the same window, and Fly.io added volume snapshots and app-scoped egress IPs as new line items in January 2026. The only invoice in this story that never needed a changelog is a Hetzner CX22 at €3.79 per month with 20 TB included.

This post reconstructs the timeline, recomputes the same workload under each regime, and explains why the forecasting cost — not the sticker price — is the tax that matters.

How we got here: four changes in 20 months

Vercel's pricing didn't jump once. It was redesigned, renamed, rebundled, and re-metered in sequence. Each step was individually defensible. Together, they replaced a coarse bill you could hold in your head with a granular one you need a spreadsheet to predict.

#WhenWhat changedWhat it replaced
1June 2024Improved Infrastructure Pricing — bandwidth and function execution unbundled into granular meters: Fast Data Transfer, Fast Origin Transfer, Edge Requests, Function Invocations, GB-hours, and later Active CPUTwo combined meters ("Bandwidth" + "Functions" at $40 per 100 GB overage)
2Early 2025Fluid Compute + Active CPU pricing announced at Vercel Ship 2025 — bill for CPU time actually spent executing, not wall-clock duration including I/O wait; GB-hours split into Active CPU + Provisioned MemoryWall-clock GB-hours that charged you while a function waited on a database or LLM response
3September 2025Credit-based billing — every Pro seat now includes a $20 usage credit consumed first; overage rates apply only after the credit is exhausted; Hobby limits renamed (Bandwidth → Fast Data Transfer, 100 GB-hours → 4 hours Active CPU + 360 GB-hours Provisioned Memory)Seat fee and usage billed as separate concepts
4February 2026Build pricing reset — Turbo Build Machines become the default at $0.126 per build minute, billed against the same $20 credit poolPrevious build execution included under older function/bandwidth bundling

A fifth pressure is already visible: regional Fast Data Transfer discounts in APAC and LATAM rolled out in 2026, and edge middleware, image optimization, and Blob storage each meter independently once you exceed their included allowances. The direction is consistent — more dimensions, finer granularity, more knobs to watch.

None of this is unique to Vercel. Render's April 2026 repricing cut included egress from a flat 100 GB to 5 GB on Hobby and 25 GB on Pro, with overages at $0.15 per GB. Fly.io started charging $0.08 per GB-month for volume snapshots on January 1, 2026 (first 10 GB free) and $3.60 per month per app-scoped egress IP the same day, and deprecated its legacy Hobby/Launch/Scale plans for pure pay-as-you-go. Every managed PaaS in this comparison added meters in the same 20-month window.

Same app, four bills: what a mid-traffic Next.js + ISR workload actually costs

The point of a timeline is to show that each change moves real money. To make it concrete, we price the same workload under each regime — no cherry-picked traffic spike, no AI workload that games Active CPU, just a typical production app:

The workload: Next.js 14 with ISR, 800K page views per month, 120 GB of Fast Data Transfer, 3M function invocations, 2.5 hours of Active CPU (roughly 50 ms CPU per request), 180 GB-hours of Provisioned Memory, 400 build minutes per month, one Pro seat.

This is a "successful small business" profile — not a side project, not a viral spike, not an enterprise fleet. It is the tier where forecasting matters most, because the bill is big enough to notice and variable enough to surprise you.

EraHow the same workload billsApprox. monthly total (1 seat)
Early 2024 (pre-unbundling)$20 seat + bandwidth overage bundled at $40 per 100 GB. 120 GB over 100 GB included → one overage block. Functions inside the 1,000 GB-hours Pro allowance.~$60
Mid-2024 (granular meters)$20 seat + Fast Data Transfer overage at $0.15/GB past 1 TB is $0 (still inside allowance), but 3M invocations at $0.60 per million = $1.80, plus GB-hours. Total stays near seat price if you fit allowances. Heavy users hit per-dimension overages sooner.~$22–$45 depending on ISR revalidation rate
Late 2025 (Active CPU + $20 credit)$20 seat fee is the $20 credit. Workload consumes ~$6 in invocation + CPU + memory + transfer against that credit, leaving credit unused — effective bill stays $20. But bump invocations to 10M or CPU to 8 hours and the credit exhausts, then every extra dimension meters at list price.~$20 at this traffic; ~$38–$55 if you 3x invocations or add image optimization
2026 (Turbo builds billed)Same as above, plus 400 build minutes × $0.126 = $50.40 against the $20 credit. Credit now exhausts on builds alone; every other meter bills at overage.~$50–$70

The pattern is not "each repricing raised the price." It is "each repricing changed which dimension raises the price." Early 2024 punished bandwidth. Late 2025 rewarded low-CPU, I/O-heavy workloads (AI calls that wait on a model look cheap under Active CPU) but punished high-invocation or high-build workloads. 2026 punishes teams that build often.

That is exactly why forecasting broke. In early 2024, you could answer "what if traffic doubles?" with one number: double the bandwidth overage. In 2026, the answer is "it depends which dimension doubles" — and ISR revalidations, edge middleware, and image transforms each double a different one.

The per-dimension rates that actually move the bill (May 2026 verified)

For reference, the Pro overage rates a mid-traffic app is one spike away from, per Vercel's current pricing page:

  • Fast Data Transfer: $0.15 per GB past 1 TB
  • Edge Requests: $2.00 per million past included
  • Function Invocations: $0.60 per million
  • Active CPU: $0.128 per CPU-hour
  • Provisioned Memory: $0.0106 per GB-hour
  • Build Execution (Turbo): $0.126 per minute

Any one of these looks small. The forecasting problem is that you now have six of them.

Render and Fly.io moved the same direction — just on different lines

Vercel gets the most attention because its changes were the most frequent, but the same narrowing happened everywhere:

Render — Until early 2026, the flat $19 per month Standard tier included 100 GB of egress. That single number was easy to reason about. The April 2026 repricing cut Hobby to 5 GB and Pro to 25 GB included, with $0.15 per GB overage after that. A 120 GB app that previously fit inside the included allowance now pays roughly $14–$17 in egress overage alone on Hobby. Render's own changelog frames it as aligning included usage with actual cost — which is accurate, but also means the "flat" part of the flat tier got 20x smaller.

Fly.io — Fly's pitch has always been "pay for what you use, no base fee." That is true and remains true. What changed is what "what you use" includes. Before January 2026, volume snapshots were retained without a separate charge and there was no app-scoped egress IP fee. After January 2026, snapshots bill at $0.08 per GB-month (first 10 GB free, but default retention keeps multiple snapshots so a 40 GB volume with 3 snapshots bills for 110 GB beyond the free allowance), and each egress IP adds $3.60 per month. Fly also retired its Hobby/Launch/Scale plans for pure usage-based billing — simpler in one sense, harder to forecast in another, because there is no tier cap to bound the invoice.

The common shape: every vendor narrowed what "included" means and added a meter where one didn't exist. No single change is dramatic. The cumulative effect is that a cost comparison from 2024 no longer describes the product being sold in 2026.

Why a flat invoice is a forecasting tool, not just a cheap one

The standard self-hosting pitch is "it's cheaper." That is sometimes true and sometimes not, depending on scale, staffing, and how much operational load you absorb. The stronger claim — and the one this particular 20-month window makes cleanly — is about forecastability.

A Hetzner CX22 costs €3.79 per month for 2 vCPUs, 4 GB RAM, 40 GB SSD, and 20 TB of included transfer. A CX32 with more headroom is €7.59. The invoice next month is the same number as this month unless you add or remove a machine. There is no dimension that doubles because ISR revalidated more often, no build-minute pool that exhausts a shared credit, no new meter that appears in a changelog between quarters. If traffic doubles, the machine either handles it or you add one — a discrete, plannable step.

That is not an argument that everyone should self-host. It is an argument that predictable infrastructure has value that per-unit-cheap infrastructure does not capture. When a team needs to answer "can we afford to run this feature for the next two quarters?" the useful price is not the cheapest possible bill under ideal conditions. It is the bill you can commit to without reading four changelogs.

The concrete forecasting test is simple: write down what you expect to pay next quarter, then check how many vendor announcements you'd need to re-read to keep that prediction accurate. For a flat-box fleet, the answer is zero. For a metered PaaS after four repricings in 20 months, the answer is four — and counting.

What to do with this if you pay one of these bills

You don't need to migrate off Vercel, Render, or Fly.io to take the lesson. You need to make the metered model forecastable on your side:

  1. Instrument by dimension, not by total. Your Vercel Usage dashboard already breaks down Fast Data Transfer, invocations, Active CPU, provisioned memory, and build minutes. Alert on each dimension's burn rate against its included allowance or credit pool, not just the aggregate invoice. The spike that matters is the one dimension that moves first — for most Next.js + ISR apps, that's invocations and build minutes, not bandwidth.

  2. Price the "what if traffic doubles?" scenario before it happens. For each vendor, write down which meter doubles in that scenario. On Vercel, a 2x page-view increase roughly 2x's invocations and data transfer but may not 2x Active CPU if the extra traffic is cache hits. On Render, it 2x's egress overage linearly. On Fly, it 2x's machine uptime and egress. If you can't answer which line moves, you can't forecast.

  3. Decide what predictability is worth to you. If your traffic is bursty or seasonal and you value hands-off scaling over bill stability, a metered PaaS is still the right trade — just budget with a variance range, not a point estimate. If your workload is steady and you can plan capacity a quarter ahead, a flat-rate box removes the variance entirely. Many teams run both: metered for preview and burst, flat for steady-state production.

  4. Keep the comparison current. A 2024 cost teardown that compares "Vercel vs. Hetzner" using 2024 Vercel meters understates the 2026 bill by the exact dimensions added since. Any comparison older than the most recent repricing is stale by definition. Re-run it quarterly, or treat it as expired.

For teams that want the flat-invoice property without assembling it from raw VMs, that is exactly what a self-hosted PaaS on owned hardware provides. A Cluster API fleet on Hetzner gives you the same git-push, HTTPS-by-default experience as a hosted PaaS, but the invoice is count-of-machines × flat rate — a number you can forecast the way you forecast headcount. The control plane is yours, the meters are yours to define or not define, and no upstream changelog can add a new line item between quarters.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.


Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex