The platform for frontend developers — Next.js hosting, edge functions, and AI SDK for building apps.
Last updated
Vercel is listed in this directory alongside chat assistants and coding agents, and it does not belong to that category at all. It is deployment infrastructure: a place where web applications are built, hosted and served. It is here because a large number of the applications people build with the other tools on this site end up running on it, not because it is an AI product.
Getting that straight is not pedantry. It changes what you should evaluate, what a good decision looks like, and what a bad one costs. Nobody has ever been locked into a chat assistant. A hosting platform is a different kind of commitment.
Strip away the branding and Vercel sells four things. It builds your application when you push code. It serves the result from a distributed network so that a user far from you is not waiting on a single machine. It runs your server-side code on demand, without you provisioning anything. And it gives every branch its own working URL.
Notice what is absent from that list: nothing about intelligence, models or generation. What Vercel is competing on is the elimination of operational work — the build server you did not configure, the CDN you did not set up, the autoscaling you did not think about, the certificate that renewed itself. For a team without a platform engineer, that is a substantial amount of work not being done, and it is the entire argument.
Vercel employs the people who build Next.js, which is a real advantage and a real thing to think about, and the internet tends to mangle both.
The advantage is that the framework and the platform are designed against each other. Features that require infrastructure support — rendering strategies, caching behaviour, image handling, streaming — work on Vercel on the day they ship, without you assembling the supporting pieces. That is not marketing; it is what having one team on both sides produces.
The thing to think about is the same fact from the other side. Next.js is open source and self-hostable, and a plain Next.js application runs on other platforms and on your own servers. But the closer you build to the framework's infrastructure-dependent edges, the more of Vercel's behaviour you are implicitly depending on, and the more a move elsewhere becomes an engineering project rather than a configuration change. This is not a trap and nobody is hiding it. It is simply worth knowing which of the framework's features are portable and which are effectively platform features, before you are attached to several of the latter. Our walkthrough of Next.js server actions covers one of these framework capabilities in practical terms.
Every branch getting its own live URL sounds like a convenience feature. In practice it changes who is able to participate in review.
Before: a designer, a product manager or a subject-matter expert reviews a change by reading a description of it, looking at a screenshot, or asking an engineer to demonstrate it. Each of those is a lossy channel, and each one puts an engineer in the loop for something that is not an engineering question.
After: they open a link and use the thing. The feedback arrives before the merge instead of after the release, and it is about the actual behaviour rather than an interpretation of it. The engineering benefit is secondary — running the real build in the real environment catches the class of problem that only appears in production, which is the class that used to be discovered by users.
This is the feature that most changes how a team works, and it is the one people underrate when comparing platforms, because it reads as a checkbox rather than as a change in process.
Vercel's pricing has three parts and only the first is a fixed number. There is a free tier for personal and non-commercial projects, a per-seat paid tier for teams that includes an allowance of platform resources, and a custom enterprise tier. On top of whichever you are on, the platform meters what your application consumes.
The metered dimensions are the ones any serverless-style platform has to charge for: how much data you serve, how many times your server-side functions are invoked and for how long they run, how much work the platform does transforming images, how much building you do, and how much of the various observability and edge features you use. Deliberately, no figures appear on this page: Vercel has restructured its pricing and renamed its billable units more than once, and a rate quoted in a review is a rate that will be wrong before the review is. Read the current pricing page.
The structural point survives every restructuring, though. Your bill is a function of traffic and computation, not of your team size, which means it is not something you can know in advance from a plan comparison. That is fine if you understand it and unpleasant if you do not.
The surprises cluster, and they are worth knowing before rather than after.
Success is the obvious one. A post that does well, a launch that lands, a link that circulates — traffic is the input to the bill, so the moment that feels best is the moment the meter runs fastest. This is the story that periodically appears online, and it is usually a small project without spending controls rather than a company with a finance team.
Traffic you did not want is the less obvious one. Crawlers, scrapers, automated scanners and outright abuse consume the same metered resources as real users. A site with no visitors can still generate a bill, and the people generating it are not going to convert.
Rendering choices are the one that catches engineers. Whether a page is served as a static file or computed per request is a decision made in your code, often casually, and it is the difference between a request that costs almost nothing and a request that runs a function. A single accidental data access can convert a whole section of a site from the first category into the second, and nothing will alert you.
The mitigations are not exotic: set spending controls and alerts on day one, understand which of your routes are static and which are dynamic, put caching in front of anything expensive, and check your traffic composition occasionally to see how much of it is bots.
Because they share a company and get mentioned together, these are routinely conflated. v0 is a generation tool: you describe an interface and it produces front-end code. Vercel is where code runs. You can use v0 and deploy somewhere else, and you can use Vercel having never touched v0, and most Vercel customers have. The connection is convenience rather than dependency. If you are weighing v0 against an editor-based approach, Cursor vs v0 is the relevant comparison, and it is a separate decision from where you host.
Do not use it for a purely static site with no server-side rendering and no functions. Plain object storage behind a CDN does that job for a rounding error, and you would be paying a platform premium for machinery you never start.
Do not use it as your general-purpose cloud. Long-running processes, background workers, scheduled jobs that run for a while, queues, stateful services and anything that wants a persistent connection all fit awkwardly on a platform built around request-scoped execution. Teams that try end up with an architecture bent around the hosting model.
Do not use it if your application is not a JavaScript web application. Other runtimes are supported to varying degrees, and the whole advantage is the integration with the JavaScript ecosystem. Without that, you are choosing a specialist platform for a job it does not specialise in.
Do not use it when a fixed, predictable monthly cost is a hard requirement — a fixed public-sector budget, a client contract with a set infrastructure line, a low-margin product where a traffic spike must not become an invoice. A fixed-capacity server is the correct shape for a fixed budget, even if it is worse in every other respect.
Do not use it where data residency, sovereignty or specific compliance certifications are non-negotiable, without confirming the specifics with Vercel directly rather than assuming. This is a procurement question, and it has a real answer, and the answer should come from them.
And do not use it because it is the default. It is a very good platform and a default is not a reason. If your team already runs infrastructure competently and has a deployment pipeline that works, the operational work Vercel removes is work you have already stopped doing, and you are paying for a refund you cannot collect.
The case Vercel is built for. Framework features that depend on infrastructure work on the day they ship, and nobody on your team has to learn why. If your application is Next.js and you do not have a platform engineer, this is the shortest path from repository to a fast global site.
Preview URLs per branch let designers, product managers and stakeholders use a change rather than read about it. This is the feature that most changes how a team works, because it removes an engineer from the loop on every question that was never an engineering question.
Sites with real traffic, real performance requirements and frequent content changes, where a global network and per-branch previews are worth more than the raw hosting. Watch which routes render per request rather than being served as static files, since that decision is what determines the bill.
Streaming model responses to a browser is an awkward thing to host well, and Vercel's runtimes and SDK are built around it. Note the distinction that matters: the platform is hosting your AI feature, it is not providing intelligence. You are still buying model access from somebody else.
Builds, certificates, the CDN, scaling and rollbacks all arrive configured. For a small team, the honest comparison is not against a cheaper host, it is against the salary and attention of the person who would otherwise own that work.
Agencies and companies running many small front ends get one deployment model, one access model and one place to look when something breaks, rather than a different arrangement per client inherited from whoever built it.
Vercel charges a per-seat subscription plus metered usage, with a free tier for personal and non-commercial projects, a paid team tier that includes an allowance of platform resources, and a custom enterprise tier. No rates appear here on purpose: Vercel has restructured its pricing and renamed its billable units more than once, so any figure quoted in a review will be out of date before the review is, and the structure is the durable part anyway. What you are metered on is data served, server-side function invocations and their execution time, image transformations, build activity, and the observability and edge features you enable. The consequence is that your bill tracks traffic and computation rather than headcount, so it cannot be predicted from a plan comparison alone. Three things keep it under control: set spending limits and alerts before you launch rather than after, know which of your routes are served as static files and which execute code on every request, and check occasionally how much of your traffic is crawlers and scanners, since automated traffic consumes exactly the same metered resources as customers do. Confirm current rates and included allowances on Vercel's own pricing page.
No. It is deployment and hosting infrastructure. It appears in AI tool directories because a lot of applications built with AI tools are deployed on it, and because the same company makes a separate generation product, but Vercel itself builds, hosts and serves web applications. Evaluate it against hosting platforms, not against assistants.
Because the seat price buys access and an allowance, and the platform meters what your application consumes on top of that: data served, function invocations and their duration, image processing, builds. Your bill therefore tracks traffic and computation rather than team size. The three things that most often cause a surprise are a spike in real traffic, automated crawler traffic that consumes resources and converts nobody, and routes that quietly render per request instead of being served as static files. Spending limits and alerts set before launch solve most of this.
Not in principle. Next.js is open source and a plain application runs elsewhere, including on your own servers. In practice, portability is a spectrum: the more you use framework features that depend on the platform's infrastructure, the more work a move becomes. The useful discipline is to know which capabilities you are relying on and which of those are effectively platform features, before you depend on several of them.
They are separate products from the same company. v0 generates front-end code and interfaces from a description. Vercel runs applications. You can use one without the other in either direction, and most Vercel customers have never used v0. The integration between them is convenience, not a requirement.
When the site is purely static, in which case object storage behind a CDN does the job far more cheaply. When the workload is long-running, scheduled, stateful or queue-shaped, which fits awkwardly on a platform built around request-scoped execution. When the application is not a JavaScript web application, since the ecosystem integration is the whole advantage. When a fixed monthly cost is a hard requirement rather than a preference, because a metered platform is the wrong shape for a fixed budget. And when data residency or specific certifications are non-negotiable, in which case ask Vercel directly rather than inferring the answer.
Full review coming soon.