Vercel is a workflow

Vercel has the best developer experience in this series, and it isn't really a place to put software. It's a workflow you adopt, and the workflow is very good. It also starts from a repository and a framework it recognises, and an agent holding a folder of fresh code has neither. Then there's the bill.

Third post in a series where we count what it costs to get agent-built software running on the platforms that exist today. The first was Google Cloud Run, a machine built for organisations, and the second was Cloudflare Workers, a kit of parts built for engineers. Both of them promised this one: the platforms built around a Git push.

Vercel is the best of those, and our complaint about it is a different shape from the other two. With Cloud Run the cost is everything you have to know before anything will start. With Cloudflare it's what you have to build afterwards. Vercel already knows what you're making. It's usually right about that, and the whole product rests on the guess holding.

A disclosure: this site doesn't run on Vercel, it runs on Cloudflare. But we've shipped on Vercel for years, and the preview deployment is the one feature in this series we most wish we'd invented.

What Vercel actually is

Vercel is a build pipeline and a CDN with functions attached, wrapped in a Git workflow. You connect a repository to a project, and after that every push builds and every branch gets a URL of its own. Production is whatever you last promoted. Rollback is promoting the old deployment again, which takes seconds, because it was never torn down in the first place.

A URL per pull request changed how teams review frontend work, and everyone else in this series has copied it since. We haven't seen anyone do it better.

The runtime has become more capable than its reputation suggests. Functions run on Fluid Compute, which reuses instances across concurrent requests instead of giving each request its own sandbox, so cold starts are rarer and the bill follows active CPU instead of wall-clock time. The default is Node now, not the old edge runtime, which means real Node APIs, longer executions, and streaming without ceremony. Package sizes and request bodies are measured in gigabytes and hundreds of megabytes, not the tight limits people remember. Configuration sits in a file beside the code, and the newer vercel.ts is typed, which for an agent beats guessing at JSON.

Then there's the build step. Vercel detects your framework and knows what its output means: which files are static, which are functions, which routes revalidate and when. Deploying a Next.js app here takes no configuration at all, while deploying the same app anywhere else takes an adapter. That detection is most of what you are buying.

The cost to start it

Here's the documented path, counted from nothing.

1. Create an account (handoff)
2. Install the CLI
3. Run vercel login, which opens a browser (handoff)
4. Link or create the project (handoff)
5. Confirm the framework preset (handoff)
6. Deploy

Six steps, four handoffs. As with Cloud Run, that's the documented path rather than the one a competent engineer walks. vercel --yes takes every default, links the project, infers the framework and deploys, and a VERCEL_TOKEN replaces the browser login entirely for anything automated.

The honest count is two: make an account, authenticate once. That ties Vercel with us and we'll say so. Of everything in this series it's the shortest honest path from an empty directory to a URL, and it asks you to know almost nothing beforehand. You don't enable any APIs, you don't assemble a registry address out of four variables, and you don't have to learn a runtime before it will accept your code.

The cost to keep it running

The cost lives in the assumption underneath the workflow: the unit of deployment is a project bound to a Git repository. That's the model, and it's the right one for a team shipping a product, where the repo already exists, the branches mean something, and the preview URL is aimed at a person who will look at it. An agent that finished a data-repair script four seconds ago has a directory and nothing else. There's no repo to connect and nobody waiting to review anything. vercel deploy from a bare directory does work, and works well, but you're going against the grain of the product: the previews have nothing to compare against and the promotion step means little, because the workflow that makes Vercel worth choosing is the part you skipped.

The shape question is harder. Vercel is superb at one shape, a web application, ideally in a framework it recognises. Off that path the guess that made everything effortless stops helping. Your Python script becomes a function with a handler signature, sitting behind an HTTP route, inside a project that thinks it's a website.

Other shapes do worse. A background worker isn't really a thing here, and Queues are new. A cron is an HTTP route that Vercel calls on a schedule, so your nightly job has to be a web endpoint that finishes inside a function timeout, and you have to think about who else can reach it. The one-off job, which this series keeps coming back to, has no home at all. Running an import once against production data turns into: write a route, protect it, deploy it, curl it, hope it finishes before the timeout, find the logs somewhere else, then remember to delete the route. People do get that working. It's still a poor way to touch a production database.

Vercel can see the agent problem coming, and Sandbox is the evidence: a primitive for running untrusted, often model-generated code, with a real filesystem and a real process. It's good, and it makes the same offer as Cloudflare's Containers: a primitive your application can use to build a runner, not a runner you can hand a script to. Vercel will help you build the thing this series keeps describing, which is a different offer from being it.

And then the bill

The other cost of keeping it running is money, and this is the part of Vercel that people complain about loudest.

Start with the licensing, which stings more than it sounds like it should. Cloudflare's free plan will carry a real business's traffic. Vercel's won't, and the reason is the license rather than a technical limit, so the moment your small software belongs to a company you are on a paid seat.

From there the bill is metered, and metered in several directions at once. One deployed application produces numbers on half a dozen meters (bytes leaving the edge, bytes travelling from your function to the edge, requests, image optimization, function time, ISR reads and writes), each with its own included allowance and its own overage rate; Vercel's pricing page has the full list. The model has also been reworked more than once in recent years, most recently onto active CPU billing, so a team that did the forecasting once has had to do it again.

The comparison that hurts is the one this series already made. Cloudflare charges nothing for egress. That line is what dominates a Vercel bill at volume, and the two are otherwise serving the same bytes.

The failure mode matters more than the rates, because traffic pricing has no idea whether the traffic was wanted. The clearest case on record is Cara, the artists' social network that went from roughly 40,000 to 650,000 users in a week in June 2024 after Meta changed its AI policy. TechCrunch reported the invoice at $96,280 for seven days, on a free product with no revenue. Vercel's VP of product replied publicly that his team had tried to reach the founder before it got that far and she had been too swamped by the growth to read the emails. Her own write-up a month later is the part worth reading: hosting had been running about $2,000 a month before the surge, and a year at the new size penciled out around $660,000. Nobody in that story behaved badly. It's what happens when success and cost are wired straight together with no fuse in between.

Vercel responded, and quickly. Spend Management brought alerts at 50, 75 and 100 percent of a number you choose, SMS at the top of that range, and project pausing when you reach it. Three weeks after the Cara invoice went round, that pausing became the default. It's a real fix and a blunt one, because the remedy for an unexpected bill is an outage. You get to pick which of the two you would rather explain.

To be fair to them, none of this bites the software this series cares about. A script that runs twice, a dashboard three people open, an internal tool with forty users: that traffic is free or close to it on every plan Vercel sells. The bill only becomes interesting when something works. But that is exactly the moment you least want a pricing surprise, and it's a strange shape for a platform aimed at the small end of the market: cheapest in the world to start, and metered on the one axis you cannot predict or control.

Our own count, honestly

Two handoffs against two. On the number this series started with, Vercel and Shed are tied, and it's the best showing anyone has made. It's also, as the first post argued, only the part of the cost you can see, so the tie settles less than it looks.

What differs is what each platform is waiting for. Vercel wants a repository, a framework it recognises, and people who review each other's work. When it gets all of that it's the best tool in this comparison by some distance. Shed expects a directory. One file says what to build and how to run it, and one command sends it. The job and the cron this series keeps coming back to are the same unit as the service, with the exit code and the logs kept for you, not a web endpoint with a disguise and a timeout.

The other difference is which way the bill points. We think software that sits idle should cost roughly nothing and that the number should be legible enough to guess before you deploy. That is a promise about storage and compute, not about how popular your thing got overnight.

The workflow was right, for the last decade

None of this is a design failure. Vercel optimised, correctly and early, for how software actually got made in the twenty-tens: teams working out of repositories, mostly on frontends, reviewing each other as they went. They built the best version of that loop anyone has, and a large part of the web is better for it.

Agents don't arrive with that context. They arrive with a folder and about twenty minutes, and what they wrote is often not a website. A workflow that opens with "connect your repository" is asking for something that doesn't exist yet, and framework detection has nothing to detect when the answer is a Python file that talks to the production database once and then never again.

That isn't really Vercel's problem to solve, because their user turns up with a repo. It's the one we picked.

Next in the series: Railway is a canvas, the first of the platforms that hand you a container and a dashboard.