Vercel
Worth it for the deploys, not for the compute
You are buying a release process your team never has to think about. Price that against the engineer you would otherwise pay to maintain one.
The verdict
Vercel is the right host for a Next.js product where shipping speed matters more than control of the runtime. It is the wrong host for long-running background work, which belongs on infrastructure you rent by the hour.
The value is operational rather than technical. Preview URLs on every pull request change how non-engineers review work. That one habit is worth more to a project than most infrastructure decisions.
What you give up is the runtime. Functions are bounded in ways a server is not, and a team that discovers those bounds in month four has a rewrite on its hands.
In short
5 things that decide this
- 01Every pull request gets a live URL, which turns review from screenshots into clicking the actual thing.
- 02Vercel documents a maximum request or response payload of 4.5 MB for a function, returning 413 FUNCTION_PAYLOAD_TOO_LARGE beyond it.
- 03Function duration is capped by plan: Hobby is 300 seconds default and maximum, while Pro and Enterprise document 300 seconds default with an 800 second maximum.
- 04Functions run in a single region by default, which is invisible until your database sits on another continent.
- 05It is the best home for a Next.js front end and a poor one for a queue worker.
For someone who has not deployed on it
Vercel hosts web applications, with Next.js as its first-class citizen. You connect a repository and every push builds and deploys on its own.
Two things follow from that. Static pages are served from an edge network close to the reader. Anything dynamic runs as a function that starts on demand, which is where the limits live.
What we run on it
Vercel hosts four of the products we have shipped. Shift Link is a UK workforce compliance platform. It runs Next.js on the web and React Native on mobile, over Supabase for auth, realtime, database and storage. Lexpair runs React on Supabase behind it. TrialTriage sits alongside a NestJS service with Postgres and Redis queues.
The pattern in all four is the same, and it is the recommendation. The front end lives on Vercel. Anything that has to run long, hold a queue or keep a connection open lives somewhere else, and the two talk over an API.
TrialTriage is the clearest example. Background processing runs through a queue on its own infrastructure. A job that takes minutes is the wrong shape for a request-scoped function.
- PushGit is the deploy trigger.
- BuildPreview URL per pull request.
- EdgeStatic pages, served near you.
- FunctionDynamic work, bounded and brief.
- ElsewhereQueues and long jobs.
The fourth and fifth stations are the whole architecture decision. Put the wrong work in the fourth and you find out in production.
Vercel, dimension by dimension
Scored from four production deployments, not from the marketing site.
| Dimension | Verdict | Why |
|---|---|---|
| Deploy experience | Best in class | Preview per pull request changes how teams review. |
| Next.js support | Strong | Same company, so features land first here. |
| Static delivery | Strong | Edge caching with no work from you. |
| Rollback | Strong | Previous deploys stay live and addressable. |
| Long-running work | Poor | Duration caps make queues someone else's job. |
| Large payloads | Weak | 4.5 MB request and response ceiling, documented. |
| Cost visibility | Mixed | Usage-based billing is hard to forecast early. |
| Portability | Adequate | A Next.js app moves. Platform-specific features do not. |
Where it stands
Good at
- Preview deployments per pull request, which get a client reviewing real behaviour instead of a screenshot.
- Zero-maintenance release pipeline. Nobody on the team owns build servers or deploy scripts.
- Next.js features arrive supported rather than needing configuration you have to research.
- Instant rollback, because previous deployments stay addressable.
Weak at
- Function duration is capped, and the Hobby plan documents 300 seconds as both default and maximum. Anything longer needs different infrastructure.
- The documented 4.5 MB payload ceiling on requests and responses breaks file upload flows that assumed a normal server, returning 413.
- Functions run in a single region by default, so a database on another continent adds a round trip to every call.
- Usage-based pricing is difficult to predict before launch, which makes budget conversations awkward at exactly the wrong moment.
- Convenience becomes coupling. The more platform features a build adopts, the more a future move costs.
Products deploying on it now
Common questions
01Is Vercel worth it over a plain server?
For a small team shipping a web product, usually yes, and the reason is staffing rather than technology. A server needs somebody to own patching, deploys and rollbacks, and that person costs more than the platform. A team that already runs infrastructure well gains much less.
02Can we run our whole backend on it?
Only if the backend is request-shaped. Anything that runs for minutes, holds a queue or keeps a persistent connection fights the model, and the documented duration caps decide the argument. Every build we run on Vercel keeps that work elsewhere.
03How hard is it to leave?
The application moves more easily than the habits. A Next.js app can be self-hosted, so the code is portable. What does not travel is the deploy experience, and teams underestimate how much process was built around preview URLs.
04What surprises teams after launch?
The bill and the region. Usage-based costs are hard to model before real traffic, and functions defaulting to one region adds latency for anyone whose database sits elsewhere. Both are fixable, and both are cheaper to decide before launch.
