Skip to content
Deployment platform

Vercel: our default for Next.js, and when the costs stop making sense

Our default deployment platform for Next.js estates: preview deployments as the review workflow, a global edge network, and an enterprise tier that clears most procurement checklists. Here's where it's the right call, and where your own cloud is.

Need a partner to implement or migrate?

This page helps you decide where a Next.js estate should run. If you’re looking for a senior team to build or migrate the site itself, see Next.js Development.

What Vercel is

Vercel is the deployment platform built by the company behind Next.js: you connect a Git repository and every push becomes an immutable deployment served from a global edge network. It handles builds, CDN, serverless and edge compute (now unified as Fluid Compute), and Next.js-specific machinery like ISR, image optimisation, and streaming as first-party features rather than things you assemble yourself. It also plugs cleanly into the rest of a modern content stack, with maintained integrations for CMSs like Contentful and Sanity.

For a marketing or digital leader weighing a rebuild, the platform question is rarely “can it serve the site” (anything can). It’s whether the workflow, compliance posture, and cost model fit the organisation. That’s the lens we use here.

Why it’s our default for Next.js estates

  • Preview deployments as the review workflow. Every branch and pull request gets its own URL. Marketing, legal, and stakeholders review the actual page rather than a staging queue, and it’s the single biggest velocity unlock we see on large marketing teams.
  • First-party Next.js support. ISR, React Server Components, image optimisation, and edge rendering work as designed, on day one of each framework release. No adapter lag, no self-managed infrastructure to keep in step. Other frameworks, including Astro, are also well supported.
  • Edge network and Fluid Compute. Static assets and rendered pages are served close to users globally; dynamic work runs on Fluid Compute, which scales to zero and bills on actual usage rather than provisioned capacity.
  • Operational simplicity. Atomic deploys with one-click rollback, automatic HTTPS, DDoS protection, and role-based access control come as platform defaults, not projects for your team.

Where it earns the shortlist

Vercel’s enterprise tier exists to clear the items that actually stall procurement: SOC 2 Type 2, SSO/SAML, audit logs, EU deployment regions, and contractual SLAs. Role-based access control and environment-scoped secrets cover the day-to-day governance questions, and spend management tooling puts alerts and limits around usage-based billing. If your security review has blocked platform purchases before, this is one of the vendors whose paperwork tends to hold up.

The honest limit is tenancy: your workloads run on Vercel’s platform, not inside your own cloud account. For most organisations that’s fine. For those with strict data-residency or sovereignty rules, it can be the deciding factor (see below).

When teams choose it, and when they don’t

Choose Vercel whenBring your own cloud when
The estate is Next.js, and the first-party fit removes an entire category of operational workStrict data-residency or sovereignty rules require workloads inside your own tenancy
Marketing velocity is the goal: frequent releases, many contributors, campaign pages shipped weeklyExisting AWS/Azure/GCP commitments or Akamai/Fastly contracts make an extra platform hard to justify
Preview-driven collaboration matters: stakeholders sign off on real URLs, not screenshotsTraffic is high and steady enough that platform pricing loses to owned infrastructure at your scale
You want the compliance items (SOC 2, SSO/SAML, SLAs) handled by the vendor, not built in-houseYou already have a platform team that operates CDN and compute well, and wants to keep doing so

Deploying the same stack to your own cloud and CDN is a first-class option in our hosting layer, not a compromise.

Vercel pricing: what the bill actually looks like

Vercel is the platform people most often ask us to price defensively, so here is the shape of it rather than the marketing summary. Rates below were current in August 2026; check the Vercel pricing page before you build a business case on them.

The bands

Hobby is free and genuinely usable: roughly 100 GB of data transfer, 5,000 image transformations, and a million function invocations a month. It’s a personal-project plan; commercial use isn’t its purpose.

Pro is $20 per developer seat per month and includes $20 of usage credit per month. Everything past that credit is metered: data transfer beyond the first terabyte at around $0.15/GB, image optimisation from about $0.05 per thousand transformations, function invocations from about $0.60 per million, and build minutes at roughly $0.014 each on standard machines. Viewer seats (the reviewers, the marketers, the legal approvers) don’t cost a seat, which matters more than it sounds on a large organisation.

Enterprise is custom-priced and negotiated as a committed contract.

So the mental model is: a small subscription, a large meter. On a modest estate the meter is invisible. On a large one it’s the whole bill.

Where the cliffs are

Four lines produce nearly every surprise invoice we’ve been asked to explain:

  • Data transfer. The first terabyte is included on Pro; beyond it you’re paying per gigabyte. A media-heavy content estate at ten terabytes a month is paying roughly $1,350 in delivery alone, before a single seat or function. This is the single biggest driver, and it’s the one that scales with your marketing team’s success rather than with anything they control.
  • Image optimisation. Priced per transformation, not per image. One product photo across four breakpoints, two formats, and a locale-specific variant is not one transformation. Estates with large catalogues hit this line far earlier than they expect.
  • Dynamic rendering. Server-rendered pages, middleware, and personalisation run compute on every request. A site that renders statically and revalidates costs a fraction of the same site rendering per request. The architecture decides this number, not the plan.
  • Preview and branch builds. Build minutes are metered across every branch, every preview, and every environment. The workflow you’re paying Vercel for is also a line on the meter.

That arithmetic is where the well-known genre of “we left Vercel at $1,800 a month” posts comes from. The numbers in those stories are usually real and the conclusion usually isn’t. Most of them describe a delivery-heavy estate on the wrong rendering strategy, and a meaningful share of the bill would have survived the move. The honest framing is that the meter is legible and predictable: you can price your own estate from published rates before you sign, and we do this for clients as a matter of routine. Vercel’s spend-management tooling adds alerts and caps on top, so the bill being a surprise is largely an avoidable failure.

What Enterprise actually changes

Less about the meter than people expect, and more about the contract. Enterprise moves you to committed, negotiated pricing rather than list rates, and it adds the things a procurement and security review asks for: SAML SSO and SCIM directory sync, audit logs, managed WAF rulesets with a far higher custom-rule ceiling, multi-region compute with failover, and a 99.99% uptime SLA with support to match. Usage is still usage. If your bill is high because you move a lot of bytes, Enterprise negotiates the rate, but it doesn’t change the shape.

The point where your own cloud wins

Put the two models side by side and the crossover is clearer than the debate suggests. Platform pricing is variable cost with near-zero operating overhead; owned infrastructure is fixed cost plus engineer-days. Below the crossover the platform is simply cheaper once you price your team’s time honestly. Above it, the delivery line stops making sense on a meter: sustained high traffic, a media-heavy estate, an already-negotiated CDN contract, or committed cloud spend the estate could be absorbed into.

The other two reasons to cross over aren’t financial at all: data residency rules that require workloads in your own tenancy, and procurement organisations for whom adding a vendor is a longer project than building the pipeline. If any of those describe you, bring your own cloud sets out exactly what the setup looks like and what you give up by leaving.

The Bejamas take

Vercel is our default recommendation for Next.js estates in 2026, and we deploy to it constantly, but “default” doesn’t mean “always”. The honest deciding factors are data residency, existing cloud spend, and how much the preview workflow is worth to your marketing organisation. In an audit we model your traffic, compliance requirements, and team workflow against Vercel and the bring-your-own-cloud path, and recommend the one that fits, using real numbers rather than platform loyalty.