Skip to content
Vercel logo

Vercel

Deploy and scale Next.js apps with zero configuration

What Vercel actually do? #vercel #software #tech

3.9(0 reviews)freemiumFounded 2015United States
free tiermanaged optionddos protectionipv6eu datacenterus datacenterapac datacenterapi accessterraform provider

Integrates with

Vercel is a serverless platform optimized for JavaScript frameworks, particularly Next.js. It handles deployment, CI/CD, and edge functions with automatic scaling and global CDN distribution.

What Vercel actually is

Vercel is the frontend cloud that grew out of Next.js — literally. Guillermo Rauch founded the company as ZEIT in 2015, it was renamed Vercel in April 2020, and it still creates and maintains the framework most of its customers deploy. Push a Git repo, and Vercel builds it, ships it to a global CDN, wires up HTTPS and preview URLs per pull request, and runs your dynamic code as functions close to users. The company is San Francisco-based, around 550 employees as of 2025, and raised a $300M Series F in September 2025 at a $9.3B valuation.

The part this review file covers is Vercel Functions: the serverless compute layer behind the marketing pages. Functions run per request in isolated instances, in one of the platform's regions (the status page names SFO1, DUB1, LHR1, ARN1, SIN1, SYD1, YUL1 among them), with a routing middleware tier and edge runtime options. Since 2025 the pricing and runtime model is "Fluid compute": instead of billing per millisecond of wall time, Vercel bills active CPU time plus provisioned memory, and instances can serve many invocations — which narrows the gap between serverless and a small always-on server for steady traffic.

The ecosystem argument is real. Next.js features (ISR, middleware, image optimization, streaming SSR) are first-party here and often arrive on Vercel before they work well anywhere else; there is a Terraform provider and a documented API for managing projects and deployments; and the surrounding product surface has grown to include Blob storage, Edge Config, Postgres/Redis partnerships, Queues, Workflows, Sandboxes, and a container registry. The homepage claim is 100+ edge locations and 99.99% uptime, and the customer logos (Washington Post, Porsche, Nintendo) are not fictional.

Pricing: what you really pay

Three tiers, and the pricing page is far more granular than it used to be. Hobby is $0/month — personal projects only, non-commercial, with hard caps (exceed your included usage and the project is paused, not billed). Pro is $20/month per seat with $20 of included usage credit, 1TB of Fast Data Transfer, and metered overages. Enterprise is custom, with platform SLAs and 24/7 support.

For functions specifically, Hobby includes 4 hours of Fluid Active CPU, 360 GB-hours of provisioned memory, and 1M invocations per month. Pro bills overages at $0.128 per active-CPU hour, $0.0106 per GB-hour of provisioned memory, and $0.60 per 1M invocations. Around that: Fast Data Transfer (100GB Hobby, 1TB Pro then $0.15/GB), Delivery Network requests (1M Hobby, 10M Pro then $2 per 1M), cron triggers (1,000/month included, then $0.95 per 1,000), ISR reads/writes, image optimization, builds (6,000 minutes Hobby, 24,000 Pro), and a growing list of newer services each with their own included quota.

The honest verdict on this structure: the included allowances are generous enough that small and mid-sized apps pay the seat price and little else, and Pro's $20 usage credit makes the first real overage month forgiving. The failure mode is traffic-shaped. Bandwidth overage is the classic bill-shock vector (third-party analyses peg Pro overage at roughly $40 per 100GB), function-heavy architectures multiply invocation and memory line items, and the platform's spend-management tools — limits, alerts, hard stops — are the admission that this happens. Our advice: set a spend limit on day one, and read the pricing page's per-service tables before you commit an architecture to it.

Performance & infrastructure

Vercel runs its own network: 100+ edge locations for caching and edge middleware, plus named function regions on three continents (US, EU — Dublin, London, Stockholm — and APAC — Singapore, Sydney — plus Montréal). Region selection for functions is per-project; the CDN layer is automatic. IPv6 is served at the edge in current deployments, though we found no single vendor page enumerating address-family support per feature, so we keep our spec field conservative.

On reliability, the public record is good and inspectable. The status page shows 90-day component uptime at 99.99% for Functions and Builds in our last look, with individual regions occasionally diverging (a June 2026 incident raised function error rates in DUB1, with multi-region failover rerouting traffic to healthy regions — the failover working as designed is the encouraging part of that story). Enterprise contracts carry platform SLAs; Hobby and Pro get the status page and best-effort support.

Cold starts are the engineering trade-off of this whole category. Vercel's answer is Fluid compute's instance reuse plus a Pro feature they call cold start prevention; streaming responses, regional pinning, and provisioned concurrency-style controls handle the rest. For most request/response web workloads this is a solved problem; for latency-critical or long-lived connections, benchmark your own workload before assuming — see /benchmarks for our measured infrastructure numbers.

We have not run Vercel through our benchmark rig; the platform's performance is function- and region-dependent anyway. What we can say editorially: for Next.js workloads, Vercel's build and cache behavior is tuned more closely than any competitor's, and that shows up as fewer weird edge-case regressions.

Where it falls short

Cost at scale is the standing criticism and it is earned. The same traffic that costs a few dollars on a $5 VPS-sized box plus Cloudflare can cost hundreds on Vercel once bandwidth, invocations, ISR writes, image transforms, and build minutes stack. Teams doing serious volume either negotiate Enterprise rates or move compute elsewhere and keep Vercel for static delivery — a pattern we see often enough to call common.

Lock-in is subtler than the internet claims and still real. Next.js itself is portable (self-host it on any Node runtime), but Vercel-specific features — ISR against Vercel's cache, Edge Config, Fluid networking, preview deployments — accumulate in a codebase and make the exit ramp narrower than the entry one. Vercel is a public company-sized private with strong incentives to keep the platform sticky; plan an exit path before you need one.

Control is limited by design: no root access, no custom kernel choices, no guarantee about which CPU you land on, function timeouts (10 seconds on Fluid Hobby, 300 seconds on Pro per current limits) and payload caps bound what can run. Background workers, WebSockets at scale, and long jobs belong on other infrastructure — Vercel's own expanding Sandbox, Queues, and Daemons lineup is an acknowledgment of those boundaries.

Finally, Hobby's non-commercial restriction is enforced, and the free tier pauses on overage rather than billing — fine for prototypes, wrong for anything with users you'd be embarrassed to lose.

Who should pick this

We'd pick Vercel Functions when the product is a Next.js (or adjacent frontend) app and the team values shipping speed over infrastructure control: marketing sites, SaaS frontends, e-commerce storefronts with spiky traffic, and internal tools where a preview deploy per pull request is worth paying for. The Git-to-URL loop is the best in the market, and for teams under ~1M requests/month the economics are unimpeachable.

We'd route around it for compute-heavy backends, high-volume API serving, regulated workloads needing region pinning guarantees, or any team with the ops appetite to run containers — those belong on /category/serverless-platforms alternatives or plain containers with a CDN in front, and Vercel can still front them.

The hybrid we recommend most: keep the frontend and its server-rendered routes on Vercel, put the expensive compute behind an API elsewhere, and set spend alerts before launch traffic finds you.

Spend controls deserve their own paragraph because they are the difference between a good month and a billing surprise. Set a hard spend limit per project on day one, alert at half the budget, and revisit the usage dashboard after every launch or press spike. Bandwidth is the line item that moves; function invocations rarely are the problem on their own.

Key takeaways

  • Git-connected frontend cloud with the deepest Next.js integration anywhere; functions run in named regions behind a 100+ location edge network.
  • Hobby $0 (personal, hard-capped), Pro $20/seat with $20 usage credit, Enterprise custom with platform SLAs.
  • Fluid compute bills active CPU ($0.128/hr) and provisioned memory ($0.0106/GB-hr), not wall time — 4 CPU-hours and 1M invocations included monthly on Hobby.
  • Bandwidth overages (~$0.15/GB past 1TB on Pro) are the main bill-shock vector; spend limits are your friend.
  • Reliable and fast for frontend workloads (status page shows 99.99% Functions uptime), but capped timeouts, limited control, and gradual platform lock-in are real constraints.
  • Our view: best-in-the-market developer experience with an honest free tier — pay for speed of shipping, and keep heavy compute off it.

Sources

Pros

  • Best Git-to-URL developer workflow on the market, with per-PR preview deployments
  • Deepest Next.js integration anywhere — framework features land here first
  • Real free Hobby tier with hard caps (pause, not bill) and clear per-service pricing tables
  • Fluid compute narrows the serverless tax: active-CPU billing plus instance reuse
  • Reliable global delivery: 100+ edge locations, multi-region function failover, 99.99% targets

Cons

  • Cost scales aggressively: bandwidth, invocations, ISR, and builds stack into bill shock
  • Function timeouts, payload caps, and no root access limit what can run
  • Platform-specific features (ISR cache, Edge Config, Fluid) accumulate into lock-in
  • Hobby is non-commercial and pauses on overage; support below Enterprise is thin
  • Heavy compute economics are poor compared to containers or VMs

Best For

Teams shipping Next.js and modern frontend apps who want production deploys with zero infrastructure work and can keep heavy compute elsewhere

Pricing

Free

Free
  • Core features included

Reviews (0)

No reviews yet. Be the first to share your experience!

Sign in to leave a review.

Sign In →

Articles about Vercel

Alternatives to Vercel

C

Cloudflare Workers

Deploy serverless code globally on Cloudflare's edge network

Serverless PlatformsFree tier
4.3 ()
View Tool →
C

Cloudflare

Global CDN and DDoS protection with object storage

CDN ProvidersFrom $20/mo
4.3 ()
View Tool →
P

Pipedream

Low-code integration platform for developers

Serverless PlatformsFree tier
4.1 ()
View Tool →
A

AWS Lambda

The original serverless functions service

Serverless PlatformsFree tier
4.1 ()
View Tool →
S

Supabase

Open-source Firebase alternative with PostgreSQL

Database as a ServiceFree tier
4.0 ()
View Tool →
A

Azure Functions

Microsoft serverless functions for .NET teams

Serverless PlatformsFree tier
4.0 ()
View Tool →

Stay in the loop

Get weekly updates on the best new hosting and infrastructure providers, deals, and comparisons.

No spam. Unsubscribe anytime.