Vercel Daemons and Drives are GA: do you still need Kubernetes in your own cloud for AI agents?

Key Points:

• No, but it narrows the gap. Vercel Daemons (long-running container processes) and Drives (persistent storage for Vercel Sandbox) remove the two classic serverless blockers for agents: execution timeouts and no durable filesystem. They do not change where the workload runs, who owns the data, or how the bill scales.
• Status check: Drives went GA on October 15, 2026. Daemons launched the same day in public beta.
• Your own cloud account still wins on four axes: data residency and compliance, GPU and instance-shape choice, private network reach, and cost ownership through Savings Plans and committed-use discounts.
• Most teams end up hybrid: frontend and light orchestration on Vercel, heavy and data-adjacent agents on Kubernetes in their own account, which Qovery runs with git-push deploys and preview environments on AWS, GCP, Azure, Scaleway or your existing cluster.

No - but it narrows the gap, and here is exactly where.

I run a company that deploys workloads into customers' own cloud accounts, so you know my bias. I still think Daemons and Drives are good engineering, and for many teams they make Vercel the right home for agents. They remove the runtime objection and leave the location objection where it was.

What did Vercel actually ship with Daemons and Drives?

Vercel shipped two primitives at Vercel Ship on October 15, 2026: Daemons, which run long-lived processes from container images, and Drives, which give Vercel Sandbox persistent, mountable storage. Together they fix the execution timeout and the ephemeral filesystem, the two things that made serverless awkward for agents.

Per the Daemons docs (checked October 31, 2026), a daemon runs "long-running background processes from container images, such as queue consumers, workflow workers, and job runners" on Fluid compute. Daemons roll out with your production deployment and restart on crash. The limits cap a daemon at 8 GiB and 4 vCPUs, and you set instance counts per region by hand.

During the beta, daemons run in production only. They accept no inbound HTTP or TCP traffic, have no persistent local storage, and don't autoscale. They can call services in the same project through service bindings. Pricing starts at $0.128 per Active CPU-hour and $0.0212 per GB-hour (pricing).

Drives are persistent volumes you mount into a Vercel Sandbox: 1 TiB by default, 16 TiB max, one read-write mount at a time, pinned to one region, $0.05 per GB-month in iad1. They attach to Sandbox, not to Functions or Daemons.

For agents, this is a real step. A tool loop no longer has to fit inside the 800-second Functions ceiling, a coding agent can keep its cloned repo, and a worker can sit on a queue all day.

The code still runs in Vercel's accounts and regions, though, egress still flows through Vercel's network, and Vercel still decides which instance shapes exist.

Does that remove the reason to run agent infrastructure on Kubernetes in your own cloud account?

No. It removes one class of reason, runtime limitations, and leaves four others untouched.

1. Data and compliance. Agent runs touch customer data, prompts, logs and vector stores. In your own account, all of it stays inside your VPC and your SOC 2, HIPAA or GDPR audit scope. To be fair, Vercel sells BYOC on Enterprise ("Run Vercel compute inside your own AWS account"), a valid answer for AWS shops on that contract.

2. Hardware. Self-hosted inference and embedding jobs need GPUs or high-memory nodes. Vercel's docs don't describe any GPU compute, and daemons top out at 8 GiB. On your own cluster you pick the instance type.

3. Network reach. An agent that queries your production Postgres or internal APIs is simplest in the same VPC. Vercel offers Secure Compute with VPC peering on Enterprise and AWS PrivateLink on Pro and Enterprise. Both work, and both add a network boundary to design, pay for, and audit.

4. Cost ownership. In your account, compute counts toward Savings Plans, committed-use discounts and your enterprise agreement. On a managed runtime you pay the vendor's rate.

Portability is a smaller fifth point: daemon configs and Drives are Vercel-specific, while a container and a PersistentVolumeClaim run on any cluster.

If you are a small team with no infra engineer, no regulated data, no GPU needs, bursty traffic, and you're all-in on Next.js, Vercel is enough. Running Kubernetes to save a few hundred dollars a month would be a bad trade.

What do AI agent workloads actually need from infrastructure?

Agent workloads need five things that request/response web apps don't: long-running execution, persistent state between steps, isolation for untrusted code, egress control, and access to specialised hardware.

Run length is growing fast. METR found the length of tasks frontier models complete doubling about every 7 months, and its Time Horizon 1.1 update puts the post-2023 doubling at 131 days. The AWS Lambda timeout is still 15 minutes.

Security is the other half. The OWASP Top 10 for LLM Applications 2025 ranks Prompt Injection as LLM01, Sensitive Information Disclosure as LLM02 and Excessive Agency as LLM06. An agent holding an API key with open egress gives a successful injection an exfiltration path, so default-deny network policy matters.

And agents are in production now: 57.3% of respondents in LangChain's State of Agent Engineering survey run them there, up from 51% the year before.

How do Vercel, AWS/GCP serverless containers, and Kubernetes in your own account compare for agent infrastructure in 2026?

You now have four credible places to run an agent backend, and they trade convenience for control in a predictable order: Vercel, serverless containers (AWS Fargate, Google Cloud Run, Azure Container Apps), agent sandbox providers (E2B, Modal, Daytona), and Kubernetes in your own account.

Vercel is the fastest path from a Next.js app to a working agent. Serverless containers already run in your account with no cluster, but give you a weaker workflow and no preview environments out of the box. Sandbox providers win when running untrusted code is the product. Kubernetes in your account wins on anything data-adjacent, regulated, GPU-bound or cost-sensitive at scale. Railway, Render and Northflank sit near Vercel on convenience, and Northflank also deploys into your own cloud.

Sandbox details come from the E2B, Modal and Daytona docs. None of these options are exclusive.

What does it actually cost to run agents on a managed runtime versus your own cloud account?

Managed runtimes charge a margin on compute that stays invisible until compute dominates the bill, and always-on daemons get you there fast.

A worked example with US East list prices checked on October 31, 2026: one worker, 2 vCPUs and 4 GiB, running 730 hours with CPUs fully busy.

• Vercel Daemon (4 GiB size, 2 vCPUs): 1,460 Active CPU-hours × $0.128 = $186.88, plus 2,920 GB-hours × $0.0212 = $61.90. About $249/month (vercel.com/pricing).
• AWS Fargate (Linux/x86): 1,460 vCPU-hours × $0.04048 = $59.10, plus 2,920 GB-hours × $0.004445 = $12.98. About $72/month on-demand (Fargate pricing). Compute Savings Plans cut that by "up to 66%" and also cover Fargate.

In fairness to Vercel, Active CPU pauses while code waits on I/O, and agents mostly wait on model APIs. At 20% CPU utilisation the daemon costs about $99/month, still above Fargate but much closer.

Your own account has its own costs: EKS and GKE charge $0.10 per cluster-hour (about $73/month; GKE's free tier covers one cluster), plus node overprovisioning and the engineer who runs it all. Flexera's 2026 State of the Cloud Report puts wasted cloud spend at 29%, and idle non-production environments are a classic culprit that auto-stop fixes.

My rule of thumb: for a handful of always-on workers, the PaaS margin costs less than an infra engineer. Once you run dozens, it stops being the cheaper option.

Can you get a Vercel-like developer experience on Kubernetes in your own cloud account?

Yes. Developer experience and hosting location are separate concerns, and that gap is what an internal developer platform fills.

Teams assume they must pick Vercel's workflow or their own cloud's control. A real substitute needs git-push deploys, a preview environment per pull request, managed databases, per-environment RBAC, and someone handling cluster upgrades.

That's what we built Qovery for. It deploys into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so the bill and discounts stay in your name. You get git-push deploys, preview environments cloned from production on every PR, auto-stop rules for non-production, managed cluster upgrades, per-environment RBAC, managed-service databases and GPU node pools on EKS. You run Kubernetes without managing it, and ship without a dedicated DevOps engineer.

Qovery is not a serverless function runtime, and it doesn't replace Vercel's edge and CDN frontend hosting. Plenty of teams keep the Next.js frontend on Vercel and run the agent backend on their own cluster through Qovery. That hybrid is the default I recommend.

How do I stand up agent infrastructure in my own cloud account from Claude Code or Cursor?

Install the Qovery Agent Skills once, then describe what you want in plain language. Your coding agent provisions and deploys into your own cloud account, and you approve each action.

Install globally for Claude Code, Cursor, Codex, OpenCode, Gemini CLI and more:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope the skills to a single repo:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code (OAuth login, read-only by default):

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change things (it also needs a setting in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform and more) do the deploying. The MCP Server operates what already exists.

Then ask: "deploy this agent worker to my AWS account with Qovery and give me a preview environment per PR". The agent proposes a plan and you approve each step. Details live in the AI agent quickstart and the Claude Code integration.