Cloudflare vs Vercel vs a Small VPS: Where an Agent-Built App Should Live

I ran a slightly silly experiment in August. I took one small product spec, a waitlist page with an admin view, email confirmation, a referral counter, and a CSV export, and asked the same coding agent to build it three times. Once for Cloudflare, once for Vercel, and once for a four-euro Linux VPS. Same spec, same model, fresh repository each time, and one sentence at the top of the prompt naming the target.

I was not trying to find the fastest platform or the cheapest one. I have written plenty about free tiers turning into invoices, and I already had a rough idea of what each of these would cost for a waitlist. What I wanted to know was simpler and, I think, more useful for anyone shipping code they did not type: on which platform does the agent write code that works the first time, and keeps working when I ask it to change something next month?

That question turns out to matter more than the pricing page.

The scorecard

I kept a notepad next to the keyboard and made a mark every time I had to intervene: an error I had to paste back, a config I had to fix by hand, a concept I had to explain. Here is roughly how it went.

The VPS version needed two interventions. The agent wrote a plain Node server with Express, SQLite through a well-known driver, a mail library speaking SMTP, and a systemd unit plus a Caddy file for deployment. One intervention was a file permission on the SQLite directory. The other was me telling it which SMTP relay I actually had. It ran on the first real deploy.

The Vercel version needed five. The first draft wrote the CSV export to a temporary file and then served it from a path that did not survive between requests. It used SQLite, which does not persist there. After I told it to use a managed Postgres and stream the CSV instead of writing it to disk, it was fine. The remaining interventions were environment variables and one build error from a server-only import leaking into a client component.

The Cloudflare version needed eleven, and the first four were the same underlying problem. The agent wrote Node. It imported bcrypt, which is a native module. It used a Postgres driver that expected a raw TCP connection. It reached for fs to build the CSV. It used Node’s crypto.randomBytes without the compatibility flag turned on. Once I told it explicitly to use D1 for the database, the Web Crypto API for hashing, KV for rate limiting, and to build the CSV as a streamed Response, it produced clean, idiomatic Workers code that ran well. But I had to know to say all of that.

Why the agent defaults to “a computer that stays on”

This is not a knock on Cloudflare, and it is not really a knock on the agent. Most of the server-side JavaScript that exists in the world was written for a long-running Node process on a machine with a disk. That is what tutorials assume, what Stack Overflow answers assume, and what most open-source examples assume. When an agent is not told otherwise, it writes that kind of program.

A small VPS is exactly that kind of machine. So the agent’s defaults and the platform’s reality line up, and you get fewer surprises.

Vercel sits in the middle. It runs Node, so most libraries work, but it runs Node in short-lived functions without a durable filesystem. The agent’s code usually runs; the problems show up as things that quietly do not persist, like uploads, SQLite files, in-process timers, and temp files.

Cloudflare Workers is the furthest from the default. It is a different runtime built on web standards, with its own storage primitives, and while its Node compatibility has improved a lot, native modules still do not run and some libraries still assume things the platform does not provide. The agent can write excellent Workers code. It just needs to be told, clearly and early, that this is what it is writing.

What each platform is actually good at for agent code

After the experiment, I stopped thinking of these as three competing hosts and started thinking of them as three different contracts.

Cloudflare is the right home when you are willing to write for Cloudflare. If the app is small, read-heavy, mostly stateless, and you are happy to use D1, KV, R2, and Queues as your building blocks, it is superb. The free allowance is generous, requests are fast everywhere, and there is very little to operate. The price is platform-specific code. My Workers waitlist cannot move to a VPS without rewriting its storage layer, and the agent will need a reminder about the runtime every time it touches it. I put a short RUNTIME.md in the repo that the agent reads first, and that cut the interventions on later changes to almost zero.

Vercel is the right home when the app is really a front end with some server bits. Next.js on Vercel is the path of least resistance for the agent, because so much of what it has seen is exactly that combination. Previews on every branch are genuinely valuable when an agent is committing frequently. The cost is that anything stateful has to live somewhere else, which usually means one or two additional vendors for the database and file storage, each with its own dashboard and bill.

A small VPS is the right home when the agent wrote a server. Background jobs, a local database, files on disk, WebSockets, a headless browser, a Python worker next to the Node app: all of that just works on a machine that stays on. The cost is that you are the operations team. You patch the OS, you set up backups and actually test them, you notice when the disk fills. That is an evening up front and a small, steady tax after.

The short version from my own testing is that the waitlist never came close to any limit on any of the three.

The cost nobody puts on the pricing page: moving out

This is where I changed my mind the most.

I used to think about hosting cost as the monthly bill. For agent-built apps, I now think the bigger cost is the price of leaving. Prototypes built with agents get built fast, and a surprising number of them turn into things people depend on. When that happens, you often want to move them: to a cheaper host, a client’s infrastructure, a bigger box, or a platform with features you now need.

Moving the VPS version anywhere else was trivial. It is a Node app with a SQLite file. I copied it to a different provider in fifteen minutes, including DNS.

Moving the Vercel version to a VPS took about an hour. The app itself ran fine under next start. The work was replacing the blob storage calls and pointing the database at a new host.

Moving the Cloudflare version anywhere else would be a rewrite of every data access path. D1 queries look like SQL, but the bindings, the KV rate limiter, and the way the Worker is wired to them are all Cloudflare’s shape. I asked the agent to port it to plain Node as a test. It managed, but the diff touched almost every file.

That is not a reason to avoid Cloudflare. Plenty of apps never move. But if you are deploying something an agent built in an afternoon, and you are not yet sure whether it will be a throwaway or a business, the platform whose idioms are closest to generic Node is the one that keeps your options open.

Money, since people ask

For the waitlist at a few thousand signups a month, all three were effectively free or close to it, apart from the VPS’s fixed few euros and a paid seat on Vercel for commercial use. The costs only diverge at real traffic or with specific features, such as heavy image optimisation, lots of function invocations, or bandwidth from large file downloads. At that point Cloudflare is usually the cheapest per request, a VPS is the most predictable, and Vercel is the most convenient and the one where I would watch usage most closely.

None of those differences were big enough to decide it for a small agent-built app. Maintenance with the agent in the loop was.

How I choose now

Before I deploy anything an agent generated, I answer three questions.

1. Did the agent write a server or a site? If it has background work, local files, or long connections, it wants a VPS. If it is mostly pages and short handlers, a platform will do.
2. Am I willing to keep telling the agent about the runtime? If yes, Cloudflare is a great home, and a one-page runtime note in the repo makes it painless. If I expect to hand the code to someone else, or to a different tool next year, generic Node on a VPS or Vercel ages better.
3. How expensive would moving out be? For a prototype whose future I do not know, I pick the option I could leave in an afternoon.

For the record, the waitlist ended up on the VPS, not because it won on speed or price, but because it was the version that needed the fewest explanations and could move anywhere. The Cloudflare version is still running as a comparison, costs nothing, and is honestly the most elegant of the three. I just would not want to explain D1 bindings to whoever inherits it.