Functions & Compute
Vercel Functions, the difference between edge and regional execution, Fluid Compute, runtimes, and how cold starts are handled.
Functions are how server-side code runs on Vercel without you managing servers. API routes, server-rendered pages, and middleware all compile into Functions that scale automatically with traffic.
Two execution models
| Model | Where it runs | Strengths | Trade-offs |
|---|---|---|---|
| Edge Functions / Middleware | V8 isolates at edge PoPs, close to users | Near-instant startup, globally distributed | Constrained runtime, no full Node APIs, light compute only |
| Functions (regional) | Regional compute with configurable CPU/memory | Full Node.js / Python environment, database access, heavier work | Runs in a region, not at every edge |
Middleware and simple routing or header logic are a great fit for the edge because they don't need a database or heavy computation. Server rendering, database queries, file processing, and AI calls belong in regional Functions where you have real CPU and memory.
Fluid Compute
Fluid Compute is Vercel's evolution of traditional serverless. It's enabled by default on new projects (since April 23, 2025); older projects can opt in via project settings or vercel.json. The key ideas:
- Optimized concurrency. A single warm instance can handle multiple requests at once (available for Node.js and Python). This matters because most API routes spend their time waiting on I/O — a database, an external API, an AI model — rather than using CPU.
- Active CPU pricing. You pay for CPU only while your code is actively executing, not while it's idle waiting on a response. This is a large saving for I/O-bound and AI workloads.
- Cold-start mitigation. Several strategies work together:
- Scale to One keeps at least one warm instance alive on Pro and Enterprise, avoiding the most common cold start.
- Predictive scaling pre-warms instances ahead of anticipated traffic based on observed patterns.
Vercel reports these strategies eliminate cold starts for the large majority of requests on sustained production traffic.
Watch out for CPU-bound work. Because concurrency shares an instance, genuinely CPU-intensive functions can interfere with each other unless you tune the concurrency limit. Fluid Compute is a clear win for I/O-bound work; for heavy computation, configure it deliberately.
Enabling Fluid Compute per environment
You can turn it on project-wide in the dashboard, or scope it in vercel.json using the fluid property — useful for testing on a single environment or deployment before rolling it out. See Configuration.
Runtimes
Fluid Compute supports Node.js, Python, Edge, Bun, and Rust. Optimized (multi-request-per-instance) concurrency applies to Node.js and Python; Edge and Bun already run on lightweight V8 isolates, so the concurrency optimization matters less there.
Limits to know
- Functions have an execution timeout. On the free Hobby plan this is capped (a long third-party API call, large file processing, or slow AI request can hit the wall and return a timeout error), with higher limits on paid plans.
- Active CPU time, memory, and invocations all count toward your plan limits.
Related concepts
Vercel also offers Cron Jobs (scheduled function invocations), OG Image generation, Data Cache, and Sandbox for running untrusted code. These build on the same compute foundation.