Vercel Daemons Admit Serverless Was Never Enough

Vercel just shipped a feature that quietly admits the thing it spent a decade arguing against: sometimes you need a process that never stops.

At Ship this month, Vercel announced Daemons in public beta. You deploy a container, pick how many instances run in each region, and Vercel keeps them alive. If one crashes, it restarts. That's it. That's the whole pitch, and it's a bigger shift than it sounds.

I deploy on Vercel. Everything on this site ships through it. So this one lands close to home.

What Vercel Daemons Actually Are

A daemon here is a long-running worker that pulls work instead of receiving it. It reads from a queue, a database, or a third-party system, does the job, and goes back for more.

It cannot serve HTTP traffic in the first release. That's deliberate. This is not "run a server on Vercel." It's "run the thing that sits behind the server."

Vercel's docs list the obvious fits: Celery, BullMQ, RabbitMQ and Kafka consumers, Temporal and Cadence workers, CI runners. Persistent filesystem storage isn't there yet, but it's promised.

Alongside it, Drives went generally available. That's persistent storage for AI agents, so code, data and memory survive past a single sandbox and an agent can pick up where it stopped.

Python support also went GA in the same breath. Put those three together and the direction is obvious. Vercel wants your whole backend, not just the frontend and a few API routes.

Serverless Hit a Wall Agents Walked Into

Serverless functions are great at one shape of work: a request comes in, a response goes out, within seconds. Agents don't have that shape.

An agent loop can run for minutes or hours. It waits on tools, retries, holds state, and wakes up when something external changes. Squeezing that into a function with a timeout means you chop it into pieces and glue the pieces together with queues and cron jobs.

I've done that glue. In my n8n setup, the long-running stuff lives on a box I own, because that's the only place it behaves. Vercel handles the web layer and the box handles everything that takes a while.

Daemons is Vercel saying that split is a tax, and they'd like to collect it instead.

The Uncomfortable Take

The uncomfortable part is that this is a retreat dressed up as a launch.

Vercel's whole identity was that you shouldn't think about servers. Functions scale to zero, you pay for what you use, nobody pages you at 3am. Daemons are the opposite: you pay for instances that run whether or not there's work.

And that's fine. It's the honest answer. But it means the "serverless for everything" story, the one a lot of us bought into, only ever covered the request-response half of an application.

The other half was always a worker somewhere. Now it's a worker on the same bill as the frontend. Convenient, yes. Cheaper, not obviously. Always-on compute billed per region per instance adds up in a way a function that runs 200 milliseconds never did, and Vercel hasn't made that math easy to do upfront.

I'd also be careful about the lock-in angle. A container is portable. A container wired into Vercel's queues, Drives and deployment flow is portable the way a rental car is.

Where I'd Use It, and Where I Wouldn't

Here's how I'm thinking about it as a one-person shop.

• Queue consumers that currently live on a separate VPS: worth trying, because one deploy pipeline beats two.
• Agent workers that need to keep state between runs: worth trying once the filesystem story lands.
• Anything that needs to accept inbound webhooks: not yet, since there's no HTTP.
• Anything cost-sensitive that idles most of the day: stay on functions or a cheap box.

The test is simple. If the work arrives in bursts and sleeps in between, a function is still cheaper. If the work is a continuous trickle, a daemon is probably right.

I wrote about the same pressure on the Cloudflare side in Cloudflare's agent runtime post. Both platforms are converging on the same answer from opposite directions: agents need a place to live, not just a place to be invoked.

What Builders Should Do This Week

Don't migrate anything. It's a beta, and the missing filesystem means you'll hit a wall fast.

Do list your workers. Write down every process in your stack that exists only because a function couldn't run long enough. Put a monthly cost next to each one, including the box it runs on and the time you spend keeping it alive.

That list is your migration case. If the number is small, ignore Daemons and keep your VPS. If it's big, you now have a real option on the same platform as your frontend.

The interesting part isn't Vercel. It's that every platform serious about agents is now selling you a long-running process. The era of "everything is a function" is quietly ending.

Count your workers. Price them. Then decide.