Workers VPC: Bringing Virtual Private Cloud Isolation to the Edge
Cloudflare has announced a preview of Workers VPC, a feature designed to bring virtual private cloud capabilities to the Workers platform. The goal is to let developers group their Cloudflare resources into isolated environments and, through Workers VPC Private Links, connect those environments to existing VPCs in external clouds — making it possible to build cross-cloud applications without exposing traffic to the public internet.
The feature introduces two core capabilities:
- Workers VPC: A way to group Workers and Developer Platform resources (like R2, Workers KV, and D1) into isolated environments. Only resources inside the same Workers VPC can communicate with each other, preventing cross-application access.
- Workers VPC Private Link: A connection mechanism between a Workers VPC and a legacy VPC in a public or private cloud. This enables bidirectional access between Cloudflare resources and resources in external private networks, as if they were part of a single VPC.
When a Private Link is established, underlying resources become directly addressable, so developers can work at the application layer without managing network-level configuration. Cloudflare positions this as a unified VPC across clouds with built-in service discovery. The feature is expected to roll out later in 2025.
The Problem: VPCs as a Barrier to Cross-Cloud Development
As developers move more stateful, business-critical workloads to Workers, they increasingly need access to private resources hosted in external clouds. But legacy VPCs — designed to secure resources within a single cloud provider's region — create significant friction when trying to reach those resources from outside the provider's network.
Cloudflare says the pain point is common. To access private resources from a Worker today, developers typically have to either build public APIs with authentication layers or deploy and manage Cloudflare Tunnels with Zero Trust policies for each resource. Both approaches add operational overhead before any application code is written.
Cloudflare previously addressed this with Hyperdrive support for private databases, which used Cloudflare Tunnels as a point-to-point solution. While functional, that approach doesn't scale well for complex, multi-resource architectures. Workers VPC is intended to provide a more comprehensive and scalable solution.
Cloudflare is building Workers VPC on the foundation of its existing private networking products, including Magic WAN and Magic Cloud Networking, leveraging experience from those systems.
How Workers VPC Works
Workers VPC is functionally equivalent to a traditional VPC in terms of isolation and security policies. The key difference is the underlying implementation. Rather than relying on regional, IP-based networking, Workers VPC uses Cloudflare's global network to enforce resource isolation across all its data centers.
For connections to external clouds, Workers VPC Private Links support two connection methods:
- Standard IPsec tunnels
- Cloudflare Network Interconnect (CNI)
When a Private Link is established, Workers VPC automatically provisions and manages the necessary resources in the external cloud to enable bidirectional routing. For teams that prefer to manage their own infrastructure, the system can generate Terraform scripts to provision external cloud resources manually.
Once connected, Workers VPC automatically detects resources in the external VPC and exposes them as bindings with unique IDs. Requests through these bindings are routed to the external VPC, where DNS resolution is handled and the request is directed to the intended resource.
For example, a Worker calling a private API in an external VPC uses a binding to a named resource:
// Example call to a private API via Workers VPC binding
const response = await env.WORKERS_VPC_RESOURCE.fetch("/api/users/342");On the reverse side, Cloudflare resources are accessible from external clouds via a standardized URL configured in a private DNS resource within the external VPC. For instance, an API in an external VPC could retrieve objects from R2 using the expected URL.
const response = await fetch("https://<account_id>.r2.cloudflarestorage.com.cloudflare-workers-vpc.com");Cost and Performance Benefits
Because Workers VPC is built on Cloudflare's platform, it inherits some networking and routing benefits. Using Cloudflare Network Interconnect as the underlying connection method can reduce bandwidth costs by taking advantage of discounted egress pricing from external clouds.
Additionally, the global nature of Workers VPC means Workers and resources can be positioned for optimal performance. Smart Placement can automatically place Workers in regions closest to external, regional VPCs, helping maximize application performance while maintaining secure connectivity.
Workloads that cross cloud boundaries
Workers VPC is designed to connect workloads that have been siloed in external clouds to the Workers platform, without forcing private resources onto the public Internet. Several concrete application patterns illustrate what this unlocks.
Consider a real-time collaborative feature built with Durable Objects and Workers, plus Containers for FFmpeg-based video processing. Historically, persisting state changes from Workers and Durable Objects to an existing private database would require building a dedicated update API as a bridge. With Workers VPC, the Worker can route directly to that database and perform updates without that intermediary layer.
The same applies to Model Context Protocol (MCP) servers built on Workers. When an MCP server needs to expose functionality that depends on private APIs or databases rather than public endpoints, Workers VPC removes the need to publish those dependencies to the Internet. New capabilities can be added directly to the server with faster time to market.
The reverse direction is equally relevant for teams storing data on the Cloudflare Developer Platform. AI training data often lands in R2 due to its zero-egress cost structure, while application data goes into D1 for horizontal sharding and configuration into KV for global single-digit millisecond reads. When compute in an external cloud must consume that data — for training or fine-tuning LLMs from R2, or for administrative and analytical tasks touching D1 and KV — security mandates often require a private path. Workers VPC provides direct routing from an external VPC to those Cloudflare resources, with privately resolvable hostnames via automatically configured DNS.
An AI agent scenario from Developer Week 2025 shows how these pieces compose. A Worker-based agent using retrieval augmented generation (RAG) may need to query PostgreSQL and Elasticsearch running in an external private cloud, with pgvector for embeddings. Those systems are unreachable from the public Internet. Rather than provisioning a container with a Hyperdrive and Cloudflare Tunnel, the linked Workers VPC allows the database to be reached directly from the Worker or through Hyperdrive.
Event-driven updates are also supported. New documents added to external object storage can trigger a Workflows invocation via a serverless function in the external cloud. The workflow then fetches the document, chunks and embeds it with any chosen provider (Workers AI or otherwise), updates the vector store in Postgres, and refreshes application state with real-time status for end users.
The path to a global VPC
Workers VPC is being built on the same networking primitives and on-ramps Cloudflare already uses to connect customer networks at scale. An early preview is planned for later in 2025.
The initial focus is connectivity from Workers to external clouds, covering the modernization of applications that depend on private APIs and databases. Full bidirectional traffic flows and support for multiple Workers VPC networks are planned for subsequent phases. Containers are expected to integrate natively with Workers VPC as well. Teams interested in shaping the vision and migrating trapped workloads can express interest here.
