On 15 October 2026, at its Ship event, Vercel published "Backends on Vercel: Python, containers, and Daemons". Three things in one post: "Python on Vercel is now generally available"; the container runtime, which "lets you deploy applications written in any language, packaged with the OS libraries and executables they need"; and the new one — "Vercel Daemons lets you deploy containers as continuously running background workers on Fluid compute." Daemons is introduced as a Public Beta.
This matters to us for a specific reason. Our own DeployBase vs Vercel comparison, written in June when Vercel shipped Dockerfile support, conceded the Docker point and rested the difference on three things: always-on processes, persistent state, and background processing outside the request cycle. One of those three has just been answered. The honest thing to do is say so, and then be precise about what is actually still different — which is less than it was, and not nothing.
What changed on 15 October
The comparison said a Vercel container "takes a request, returns a response, and keeps nothing in between" and that there were "no background workers outside the request cycle". Daemons changes the second half of that. In Vercel's description: "You choose the number of instances in each region, and Vercel maintains that capacity by restarting processes when they exit or crash. Daemons launches with support for pull-based workloads, where your code requests work from another system and processes it as it becomes available. That could mean consuming queue messages or fetching pending jobs from a database."
That is a real background worker: a process that stays up, pulls work, and gets restarted if it dies. Their worked example is a Python video processor packaged with ffmpeg in a Dockerfile, pulling jobs from Vercel Queues while a Next.js front end handles requests. If your reason for leaving Vercel was "I need a queue consumer that runs all the time", that reason is weaker than it was last week — with the caveat, theirs, that it is a Public Beta launching with pull-based workloads.
Python being generally available is the other half of the same story: FastAPI, Flask and Django as first-class backends, and a set of Python SDKs for Vercel's own products. The container runtime had already been in Public Beta; the post says 5,000 teams have shipped 150,000 container deployments through it.
On billing, the post is specific about the model and silent on numbers: "Containers deploy as Vercel Functions on Fluid compute, scaling with traffic and using Active CPU pricing, which doesn't charge for idle time spent waiting for API responses, database queries, or LLM inferencing." There is no price in the post, so there is none here either. What it describes is a usage-based model where idle waiting is not billed; what it does not describe is what a daemon that is awake and pulling all day costs. That is the question to ask before moving a worker there, and the answer is on their pricing page, not in the announcement.
What is actually still different
Read the comparison again with Daemons in hand and the remaining differences are these.
The unit you rent. On DeployBase you rent a fixed slice of a server — RAM, CPU, disk — for a flat monthly price, and your app process runs in it continuously whether or not anyone is talking to it. On Vercel, by their description, containers are Functions on Fluid compute that scale with traffic and bill by active CPU, and Daemons are instances you size per region. One is a box you keep; the other is capacity you consume. Neither is wrong. They suit different traffic shapes, and the comparison's advice stands: steady traffic favours a flat price, bursty traffic favours usage-based billing.
Where state lives. The comparison's point about persistent state is unchanged by this post. Daemons gives a process that keeps running; it does not, in the post, say anything about a durable local filesystem, and the worked example keeps state in Vercel Queues and Vercel Blob rather than on disk. On DeployBase the app directory is host-mounted and persists, and MySQL, PostgreSQL, Redis and MongoDB run as per-account containers on the same host — the comparison lists this, and it is still the case.
Push versus pull. Daemons launches, in Vercel's words, "with support for pull-based workloads". A worker that polls a queue fits. A process that needs to accept inbound connections on its own port — a WebSocket server, a raw TCP listener, anything that is not HTTP behind their router — is a different shape, and the post does not describe it. The comparison's "any protocol" line is about that shape, and it is still the difference.
What "always-on" means. On DeployBase it means one process, in one container, on one server in Helsinki, that we keep running and that you can reach over SSH from the Pro plan (unprivileged, not root). On Vercel it means a declared number of instances per region that the platform restarts for you. The second is closer to a managed fleet than to a server. Whether that is better depends entirely on whether you want to think about the server.
What this does not change
It does not change the comparison's recommendation, only its reasoning. If you are on Vercel with a Next.js front end and the thing you were missing was a long-running worker, you now have an option inside the platform, and you should read the Daemons beta documentation before you read a competitor's blog — including this one. If your reason for wanting a container host is a disk that persists, a database on the same box, a process that listens on its own port, or a bill that does not move with traffic, the 15 October post does not address those, and the comparison's conclusion is unchanged.
We have added a dated note to the top of the comparison pointing here, and corrected its "no background workers" line to say what it should now say: true until 15 October 2026. A comparison that quietly keeps a claim its subject has since answered is not worth your trust on the claims it still gets right.