Vercel Ship 2026: 3 Takeaways, and What Vercel's BYOC Still Keeps Outside Your Cloud

Key Points:

• Vercel is moving into the backend. At Ship 2026 in San Francisco on 15 October, Vercel made Python generally available, extended its container runtime, and launched Vercel Daemons in public beta for queue workers and CI runners. Combined with Vercel Services from June, it now pitches itself as a place to run full applications.
• Agents are now the main deployer, and governance is the enterprise pitch. Vercel says agents went from fewer than 3% to more than half of its deployments in six months. Vercel Connect, Vercel Passport, AI Gateway budgets and Vercel Agent are all answers to the same question: who controls what an agent can touch?
• Bring Your Own Cloud on AWS is GA, with a narrow scope. According to Vercel's own BYOC docs, only Node.js and Python functions move into your AWS account, as Lambda. TLS still terminates at the Vercel CDN, requests and responses pass through Vercel, containers and Services are excluded, it is AWS only, and it does not satisfy FedRAMP.
• The demand behind BYOC is real, and Vercel just confirmed it. Enterprises want execution, data and traffic inside an account they control, on the cloud they already pay for. That is the full scope Qovery has been built around: applications, containers, workers, databases and agents deployed into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster.

Vercel held its Ship 2026 keynote in San Francisco on 15 October, part of a five-city tour with stops in London, Berlin, New York and Sydney. My co-founder Morgan Perry and I were there in person, and I followed the announcements closely, because Bring Your Own Cloud reaching GA puts Vercel on the topic we work on every day at Qovery: running software inside the customer's own cloud account.

Vercel builds excellent developer experience, and several of these launches are genuinely useful. The headline enterprise feature, Bring Your Own Cloud, covers much less than the name suggests. If you are a CTO or platform lead deciding where your backend and your agents should run in 2027, the details matter. So here are the three takeaways I would bring back to a platform team, and what "your own cloud" should actually mean.

What did Vercel announce at Ship 2026?

Ship 2026 was split across two main launch moments: London on 17 June and San Francisco on 15 October. Taken together, the announcements fall into three groups.

Backend and compute

• Python on Vercel is GA. FastAPI, Flask and Django with standard CPython, PyPI dependencies, uv and pyproject.toml. Vercel says 150,000 teams already deploy Python backends.
• Container runtime. Applications in any language, built from a Dockerfile, run as Vercel Functions on Fluid compute, with a Vercel Container Registry.
• Vercel Daemons (public beta). Long-running workers that pull from Vercel Queues, databases or third-party systems without an HTTP server: Celery, BullMQ, Kafka consumers, Temporal workers, self-hosted CI runners (changelog).
• Vercel Services (June). Frontend and backend services in one project, with private service-to-service traffic.

AI and agents

• The Agent Stack. AI SDK, AI Gateway, Workflow SDK, Vercel Sandbox and Chat SDK, joined by Vercel Connect for scoped credentials to third-party tools.
• eve, an open-source TypeScript agent framework Vercel describes as "Next.js for agents", now with persistent memory.
• Vercel Agent, which investigates production issues and can take approved actions.
• Vercel Drives, persistent workspaces for agents running in Sandbox, now GA.
• AI Gateway budgets per key, project, person and team, plus US-only inference and Zero Data Retention. A new Token Pass gives Pro teams $80 of model credit for $30 a month.

Enterprise

• Bring Your Own Cloud on AWS, now GA for Enterprise customers (changelog).
• Vercel Passport, internal apps gated by your identity provider (Okta, Auth0, SAML, OIDC).
• Enterprise-Managed Authorization for Connect, in public beta.

That is a lot of surface area. Three takeaways matter more than the rest.

Takeaway 1: Vercel wants to run your backend now

For years the mental model was simple. Vercel for the frontend, something else for the backend. Ship 2026 is Vercel's attempt to break that model. Python GA, any-language containers, Daemons for workers and Services for multi-service projects add up to a "deploy anything" platform.

For a team with a Next.js app and a couple of API routes, this is convenient. One vendor, one dashboard, one bill.

For a platform team, it raises the questions you would ask of any backend platform:

• Where does it run? On Vercel's infrastructure, in Vercel's AWS accounts, unless you use BYOC (more on that below).
• What are the runtime limits? Vercel Functions keep a standard maximum duration of 800 seconds on Pro and Enterprise. Daemons are the answer for long-running work, and they are in public beta.
• What about state? Databases, caches and queues on Vercel come from the Marketplace or from Vercel's own primitives. They do not land in your VPC next to your existing data.
• What does it cost at scale? You pay Vercel's usage pricing on top of the compute, and you cannot apply the Savings Plans or committed-use discounts you negotiated with your cloud provider.

Vercel stays a strong choice for the frontend. I would still think twice before moving a backend that already runs fine in your own AWS or GCP account onto a platform designed around functions.

Takeaway 2: Agents now deploy most of the software, so control is the product

The most striking number of the event: Vercel says agent-triggered deployments went from under 3% to more than half in roughly six months. Token volume through AI Gateway grew from about 2 trillion to about 20 trillion per month over the same period. These are Vercel's own figures, but the direction matches what we see with our customers.

Once agents deploy more than humans do, the enterprise question shifts to control:

• Which agent can deploy to production, and which can only touch a preview environment?
• Which credentials does the agent hold, and for how long?
• Where does the agent's code actually execute, and what network can it reach?
• Who approved the change, and where is the audit trail?

Most of what Vercel shipped for enterprises answers these questions. Connect replaces long-lived credentials with scoped tokens and audit logs. Passport puts internal apps behind your identity provider. AI Gateway budgets cap spend per key and per team. Vercel Agent works through approved actions.

I agree with the diagnosis. This is exactly why we describe Qovery as an Agentic DevOps platform. Where I disagree is on where those controls should live. If your agents operate infrastructure that holds customer data, the guardrails, the execution and the audit trail should sit inside the cloud account where that data lives, under your IAM and your network boundaries. Scoped tokens issued by a vendor still let agents run on that vendor's runtime.

Takeaway 3: Vercel BYOC validates the demand, but covers only functions

This is the announcement I found most interesting, because it confirms what our customers have told us for years. Regulated companies, and increasingly any company selling to enterprises, want their workloads inside a cloud account they own. Vercel now offers a Bring Your Own Cloud option. Let's look at what it actually does.

What does Vercel BYOC run in your AWS account?

From Vercel's BYOC documentation: BYOC "lets you run the Vercel Functions behind your project as AWS Lambda functions in your own AWS account. Vercel still routes requests, serves static assets, and manages the deployment."

So your function code and its execution move into your AWS account as Lambda. Everything else stays on Vercel. The docs are candid about the boundaries:

Two lines in the docs deserve attention. Under "When not to use BYOC", Vercel lists: "All traffic must stay in your account: TLS terminates at the Vercel CDN, and requests and responses pass through Vercel." And: "Vercel can't raise your AWS quotas, recreate deleted functions, or fix IAM or network changes made in your account."

In other words, you take on the operational burden of running Lambda in your account, while Vercel remains in the data path for every request. For many security reviews, the second point is the one that decides.

What about Vercel Secure Compute?

Secure Compute is the other enterprise networking option, and it is often confused with BYOC. It gives your functions a dedicated, single-tenant network with static IPs and VPC peering. The docs describe it as "a dedicated network that Vercel runs on your behalf", so it lives in Vercel's AWS environment, not yours. Each project environment links to a single active network in a single region, and traffic leaving the private network over the public internet is billed at $0.15/GB. It helps your functions reach private backends, and the compute stays on Vercel.

What should "bring your own cloud" mean in the agentic era?

If I sit on the buyer's side of the table, here is the checklist I would use for any platform that claims to run in your own cloud. It applies to Vercel, to Qovery and to everyone else.

1. Scope of execution. Does everything run in your account, or only one function type? That means web services, containers, background workers, cron jobs, databases, Helm charts, Terraform modules, and the agents themselves.
2. Data path. Does user traffic terminate inside your account, or does it transit through the vendor's edge first?
3. Cloud choice. Is it AWS only, or can you use GCP, Azure, a European sovereign provider, or the Kubernetes cluster you already run?
4. Operating burden. When you bring your own cloud, who handles provisioning, upgrades, scaling and cleanup? If the answer is "your team", budget for the people who will do it.
5. Agent guardrails. Can you scope each agent to specific environments and actions, give it its own token, and see every action it took in the same audit log as your engineers?
6. Jurisdiction. Which legal entity operates the control plane, and what does it see? For European companies, this question is no longer theoretical.
7. Exit. If you leave, do your workloads keep running as standard Kubernetes resources, or do you rebuild?

How Qovery approaches the same problem

Qovery was built for the full version of that checklist. It is an Agentic DevOps platform that deploys and operates your workloads inside your own cloud account, with Kubernetes under the hood and without a dedicated DevOps team to run it.

• The whole stack runs in your account. Applications, containers, background workers, cron jobs, databases, Helm charts and Terraform modules all deploy into your own AWS, GCP, Azure or Scaleway account, or onto an existing Kubernetes cluster. Managed services such as RDS, ElastiCache or S3 are provisioned in that same account.
• Traffic stays with you. Ingress runs in your cluster, so requests terminate in your account and never transit through Qovery. The Qovery control plane only processes deployment metadata (configuration state, resource metrics, deploy events) and talks to your clusters over mutually authenticated TLS. It never reads your application data, database contents or secrets. Details are on our sovereignty page.
• Agents work inside your rules. Connect Claude Code, Cursor, Codex or any MCP client through the Qovery MCP server, or install the Qovery skill. Each agent gets its own token, scoped to the environments and actions you define, and every action is logged and attributed alongside your team's. Agent tasks execute on your infrastructure, inside the network boundaries you set. Qopilot reads logs, events and configuration to explain what broke and suggest the fix.
• You keep your cloud economics. Your cloud bill is your cloud bill. Savings Plans, committed-use discounts and credits apply directly, because the compute is yours.
• European, and auditable. Qovery is a French company subject to EU law, SOC 2 Type II certified, with RBAC scoped by environment, project and role, for humans and agents alike.
• No lock-in. Your workloads are standard Kubernetes resources, and the whole setup can be managed as code with the Qovery Terraform provider.

The honest trade-off: Qovery does not try to be a global edge network. If your product is a content-heavy Next.js site that lives on the CDN, Vercel is very good at that.

Should you choose Vercel BYOC or run the whole stack in your own cloud?

Here is how I would decide, workload by workload.

Many teams will end up with both, and that is a sound architecture. Keep the frontend on Vercel, run the backend, the data and the agents in your own cloud with Qovery, and connect them over authenticated HTTPS. I covered that pattern in detail in Vercel vs Qovery for AI infrastructure, and the wider options in Vercel alternatives for backend services and databases in your own cloud.

A year ago, "run it in my own cloud account" was a niche enterprise request. This week the most visible frontend platform in the market shipped a feature for it. The decision left to you is how much of your stack, and how much of your agents' work, should run inside that account.