Vercel Gives Agents a Home: Drives Keep the Files, Daemons Keep the Work Running

The short version

At its Ship conference on 15 October 2026, Vercel launched two things at once: Drives became generally available, and Daemons entered public beta. In one sentence: Drives answer "where did the agent's files go," and Daemons answer "who keeps doing the agent's background work." The first is a persistent workspace for agents; the second is a resident worker for background jobs. Neither is revolutionary alone, but together they show where Vercel is heading — from frontend hosting toward being the place where agent backends live.

What Drives are

Start with a problem everyone who has used Vercel Sandbox has hit: sandboxes are disposable. You clone a repository in a sandbox, generate a dataset, let an agent work all afternoon, and when the sandbox stops, the files are gone. The next sandbox starts from scratch. Drives break that cycle by separating an agent's files from its execution environment: files live on a persistent drive, sandboxes mount it temporarily, read and write it, and when the sandbox stops, the files remain.

The official usage is straightforward. From the CLI, create a drive with get-or-create, then mount it when creating a sandbox — for example, mounting a drive named agent-workspace at /workspace. The SDK works the same way: obtain a Drive object, then pass it as the mount for /workspace when creating a Sandbox. The one rule that matters: everything under the mount point persists; everything outside it still belongs to the sandbox and disappears with it. The next sandbox that mounts the same drive finds the repository and everything else the previous run left behind, with no re-cloning or regeneration.

That simple rule changes the default assumption of agent workflows. Previously, every agent run was stateless, and state had to be maintained through external databases, object storage, or manual file transfers. Now files themselves can be state. An agent can switch environments, runtimes, and compute configurations between phases — data preparation in one environment, analysis in another, verification in a third — without shuffling files around.

Three ways to use a drive: exclusive, shared, forked

Drives support three collaboration patterns. First, exclusive resume: the same agent mounts the same drive at different times and continues where it left off — the basic meaning of a "persistent workspace." Second, read-only sharing: one agent builds a dataset on a drive, and other agents mount read-only copies to analyse it or generate reports, saving their own results elsewhere without polluting the original data. The read-only constraint is both a limit and a protection.

Third, forking: fork a drive into an independent writable copy. Each fork starts from the drive's contents but evolves independently. The official docs are explicit: forks do not merge back into the original drive. That limit must shape workflow design — forks suit "try several approaches in parallel, then pick one by hand," not "edit the same data together, then merge automatically." If you need merge semantics, you need version control or database transactions, not Drives.

On capacity: the defaults are 1 TiB, or 1 GiB on Hobby, with up to 16 TiB available. For personal projects, the Hobby allowance is easy to burn through with one moderately large repository plus generated files, so the discipline matters: only write genuinely persistent work products to the mount point, not build caches, temporary files, or model weights.

What Daemons are

If Drives are "where files live," Daemons are "who does the work when nobody is watching." Vercel Functions are request-driven: they wake on a request and sleep without one. But many background jobs have no request to answer — consuming queue messages, running batch jobs, watching database changes, or polling as a self-hosted CI runner. Previously those jobs had no proper home on Vercel: developers ran their own always-on server or simulated persistence with repeated function calls. Daemons are Vercel's formal answer: a long-running process that pulls work from queues, databases, or third-party systems without needing an HTTP server.

The official use cases are specific. Queue consumers in Vercel Queues poll mode, Celery, BullMQ, RabbitMQ, or Kafka. Long-polling workers for Temporal or Cadence. Self-hosted CI runners for GitHub Actions, GitLab, or CircleCI that poll for jobs without inbound connections — the last one matters for corporate networks where runners cannot and should not expose ports.

Implementation-wise, Daemons run as containers on Fluid compute and deploy alongside your app in the same project. Vercel builds the image and maintains the instance count you configure per region, restarting instances that exit or crash. Configuration is a daemons entry in the project-root config file, specifying the working directory, entrypoint, command, and per-region instance count; connection details go in production environment variables; after deploying to production, instances start and their output appears in the project's Logs. CPU and memory metrics require Observability Plus — a cost detail worth knowing in advance: basic logs are included, fine-grained resource metrics are a paid-tier feature.

What they mean together, and what they are not

Together, Drives and Daemons complete a picture of an agent backend: a user starts a long task, Daemons pick it up and keep executing in the background, produced files land on Drives, environments can change or crash mid-task without losing files, parallel agents can share data read-only or fork off to explore, and a human picks the best result. Drives are the state layer, Daemons the execution layer, sandboxes the temporary compute layer.

Two boundaries prevent confusion. First, Drives are not the open-source durable-harness project reported earlier: that package handles crash recovery and resume for agent harnesses ("resume from the breakpoint without re-burning tokens"), while Drives are platform storage infrastructure. They can complement each other but are not substitutes. Second, Drives are not a database: they store files, not transactional, indexed, queryable structured data. If you need "find all orders over 100 in pending state," use a database query; if you need "get this file back exactly as it was," use a drive.

A third boundary: Daemons do not replace Queues or Workflows. Queues handle task queuing, Workflows handle multi-step orchestration, Daemons handle long-running executors. A common combination is Queues receiving tasks, Daemons consuming them, and Drives storing their products. If your background work already decomposes cleanly into queues plus functions, you do not need Daemons — their home ground is work that cannot be decomposed into finite steps and must keep running.

Beta caveats, unsuitable cases, and costs

Daemons are in public beta, which carries three caveats. Function details, pricing, and limits may change, so keep a fallback path (for example, a self-hosted runner you can switch back to) for production-critical chains. Third-party reports say the current beta is limited to production deploys, so preview-environment behaviour may differ from production — test against production deploys. And fine-grained CPU and memory metrics need Observability Plus, so budget for that subscription if your background tasks have resource budgets.

Drives, though generally available, need two disciplines. Mount-point hygiene: only persistent work products belong on the drive; caches, build artefacts, and weights do not, or even the 1 TiB default will be eaten by intermediates. Fork discipline: decide before forking who picks the winning result and what happens to the other forks, because forks never auto-merge and unmanaged forks become manual cleanup work.

Three unsuitable cases round out the picture. Drives are wrong for data that needs strong transactions and queries — that is database work. They are wrong for multi-person real-time merging — that is version control or transactional storage. Daemons are wrong for work that decomposes cleanly into request plus queue — queues and functions already cover that, and adding a resident process only adds operational surface: instance counts, restart policy, log collection, resource metrics. The value of a tool is not how new it is but whether it sits exactly on a gap in your workflow — and these two tools each sit on a real gap, just not a gap every project has.

Verdict and launch checklist

Seen alongside the rest of Ship 2026 — Python generally available, an extended container runtime, AI Gateway budgets and Token Pass, enterprise Bring Your Own Cloud — Drives and Daemons are the most agent-developer-facing part of a single direction: Vercel moving from frontend hosting to full application backends. They answer the two most practical questions for agent apps: where do files live, and who runs background work.

The pragmatic path is two steps. First, use Drives for a pain you already feel — for example, stopping repeated repository clones and dataset regeneration across runs — and bank that win. Second, evaluate Daemons only if you genuinely have background work that must keep running and cannot be split into requests; otherwise, do not adopt a new feature for its own sake. To try Drives: create a test drive, verify that files survive sandbox shutdown, try one read-only share and one fork, and confirm the no-merge semantics match your expectations — then check the mount point for caches that should not persist. To try Daemons: start with a non-critical queue consumer or CI runner, deploy to production, verify instance maintenance and restart behaviour, confirm logs meet your debugging needs, assess whether Observability Plus is required, and keep the fallback ready. Only after those checks will you have an answer based on your own project rather than on a conference talk.