Cloudflare Workers VPC: Build globally, connect privately

Network & Infrastructure

About the session

Cloudflare Workers applications often need to reach APIs and databases that cannot be exposed to the public Internet. Cloudflare Workers VPC connects Workers and Hyperdrive to private networks through existing Cloudflare One connectivity, including Cloudflare Tunnel. This session follows a request from a Worker to a private service: how Cloudflare resolves a private hostname, carries the connection, returns traffic without giving the Worker a stable network identity, and limits access through explicit bindings. It also compares a VPC Service for one approved destination with broader VPC Network access for dynamic destinations, account-wide routes, and Gateway-controlled egress.

View transcript

0:03My name is Matt Alonzo, and I'm a senior systems engineer here at Cloudflare. I've worked here for six years. I started off on the Durable Objects team and helped launch that product, then helped launch Hyperdrive. And for the past year, I've been working on our private networking products, primarily Cloudflare Workers VPC. And Workers VPC is really neat because it lets you build your applications on Cloudflare, but it lets you connect to your resources. that run outside of Cloudflare, whether it's on-premise or running in a hyperscaler VPC. Before Worker's EPC, when you used Cloud for Workers, your only option for connecting to things outside of Cloudflare was if they were on the public internet. And that meant attackers could access those resources too. And if you had something running in a hyperscaler VPC, it was up to you to set up an internet gateway to publicly expose that resource and secure it.

0:55And even if you did, set that up there's challenge of getting it right and some other problems beyond attack surface bandwidth pricing for getting data out of the hyperscaler vpcs is built by the gigabyte and it's built at an elevated rate compared to data that egresses over private connections and this can really add up if you're moving a lot of data into our developer platform and we already had a solution for private networking we have our cloud for one suite which has several different connectors traffic into and out of the Cloud4One network from the Cloud4One client that runs on your employee laptops to Cloud4Tunnel, which lets you connect to resources in a private network, Cloud4Mesh. We have Cloud4WAN for IPsec and Cloud4Network interconnect for like an actual physical cable between us and your private network. And this allowed physical devices and VMs to reach the Cloud4One network, but there wasn't a way for workers in our developer platform products to get their traffic into the Cloud4One network.

1:52And that's the problem that WorkerZPC solves. It's the missing piece that brings the developer platform into your Cloud4One network. And it acts as an on-ramp for traffic coming from both Cloud4Workers and HyperDrive and can reach private resources via our existing Cloud4One connectors from Tunnel to Mesh and WAN and CNI.

2:14The Cloud4One client and other on-ramps like Cloud4WAN work differently than WorkerZPC. With the Cloud4One client... your resources are exposed as if they were just available on your local area network. But when using Worker's DPC, we don't expose your private resources through the global fetch handler on your worker. Instead, we expose those private resources using bindings. If you haven't used Worker's before, bindings are live objects that are accessible from worker's code, and you configure them in your Wrangler configuration for your worker to define what resources on the developer platform that your worker can access at runtime. And so the Worker's VPC binding has two options. You can use it for HTTP and you'll get a fetch method on your binding or you'll get a connect method if you're using a TCP service.

3:00And in order to create a Worker's VPC binding, you need a bindable object to actually bind to when you upload your worker. And that is what a VPC service is. And so to expose a specific private resource as a bindable object, you have to create a VPC service. a name and it has a type and there's two types of VPC services there's the TCP variant which exposes a single port or the HTTP variant on for the HTTP variant you can have a plaintext service you can have encrypted only service or you can support both HTTP and HTTPS which is the default on the standard ports and the whole point of the VPC service is it kind of it describes an origin and so it stores all of the metadata that's necessary to establish a connection to that origin and so beyond the port you have to provide a host name or an ip address and then you have to provide something that we call a resolver network which is a single object that defines both the resolver to use for private host names and the network that any resolve private ips or if you specify an ip that that private ip is routable on and so if you notice here we have only a single tunnel id and in the configuration for the resolver network and that's because cloud for tunnel um now has a built-in dna proxy in it that allows our network to access your private resolver that's running in your network by proxying DNS queries from us through to your private resolver.

4:17And so you only have to provide a tunnel ID and you're able to get both resolver and a network out of that. But you still have the option of manually specifying a resolver IP if you want, depending on your use case.

4:34In order to create a VPC service and in order to bind to a VPC service, you need different permissions. And the point of this is kind of separate who is allowed to do what with this product. For network admins who might want to expose private resources to developers on the same account you need to give them the connectivity directory admin role and this lets you control who can expose resources while developers can be given the connectivity directory bind role which allows them to only bind to existing workers vpc services that have already been created. Once you have a VPC service, you're able to add it to your Wrangler configuration by specifying the service ID that was returned from creation and need to give it a binding name which is what's going to show up on the end of object when you go and write your worker And you'll get that fetch method that I mentioned earlier using an HTTP service.

5:26And something to keep in mind for the fetch and connect method on a VPC service binding is the hostname in fetch is not used for routing. You already specified what you're going to be routed to. in your VPC service configuration. And so that host name is only used in the host header for the requests that are being sent to your origin and will not be used for routing.

5:48I mentioned that we also support TCP services, and this is also useful for connecting to private databases. With Hyperdrive, it's not just for workers. And the way to do this is you can specify an app protocol in your TCP service definition. And for Hyperdrive, you can do either postgres or mysql um and just as you're able to uh set a service a vpc service in your wrangler configuration you can set a vpc service in your hyperdrive configuration under the origin field instead of providing um like the typical fields that you would have in a connection string um because you access private databases that are running on premise or maybe you're using a hosted database product in one of the hyperscalers and you can do this just by running tunnel in your vpc and you're able to access that database without having to expose it to the public internet.

6:40VPC works pretty similar to the Cloud for One client and it is also an on-ramp, but the way that we actually proxy traffic behind the scenes is pretty different. Workers, VPC is not a layer three on-ramp like the Cloud for One client and Cloud for WAN. Those on-ramps are getting traffic into Cloudflare as packets that are already coming out of an operating system. But with WorkerZPC, this is different because we run workers in a sandbox. They're not virtual machines, they're not containers, and so they don't have access to the host OS. Everything that a worker can do is defined by the bindings that it has and the implementation of those bindings in the worker's runtime. And for WorkerZPC, we don't expose the host OS There's no good way to configure the system resolver to on-demand to use a specific private resolver.

7:29and that traffic through a tunnel. And so we implement a user space DNS client. And that allows us to send the DNS queries for the private host name and your VPC service configuration when a connection is initiated by your worker by calling the fetch method on the binding through to a clopter tunnel and through to your private DNS resolver. The results come back for the private host name and you get a private IP. And we're then able to establish a connection. If you notice here, a worker's VPC is all... responsible for doing the TLS session. That is because we don't want to do any encryption inside of the shared worker sandbox. We'd like to keep that outside of the shared address space. And so the plain text byte stream that comes out of Cloudflare workers gets upgraded into the TLS session and that flows on to your private origin. And from the perspective of your private origin those packets are going to appear as if they're coming from the machine that the Cloudflare D is running on with the same source IP as that machine.

8:26And so VPC services are really great for if you want like per-resource capabilities. You want to define specific destinations that you know about ahead of time. They're also useful when you don't want to have a single global routing table. A good example of when this can happen is let's say you do an acquisition and you have multiple hyperscaler VPCs that are under your responsibility. And they're all using the same shared address space. If you had a global routing table, you'd have to decide what VPCs you're going to change. that address space to use. But with VPC services, you're defining your resources and you're giving them an ID. And so workers can identify those resources by their ID instead of using IPs which can conflict across networks. But sometimes you don't want to specify all of your private resources ahead of time.

9:12Maybe you're doing service discovery or you need to connect to a ton of resources or change that at runtime. And that's what the VPC network binding is for. And we have two variants of the VPC network binding. There's the VBC network binding to tunnels and the VBC network binding to the entire Cloudflare One network. And for VBC network bindings to tunnels, you're exposing everything that Cloudflare D can access. So if Cloudflare D is running, anything that it can access, including the public internet, is available. And this is useful for not just connecting to dynamic resources and your private APIs and data databases, but you can also connect to things on the public internet. And it's kind of like a VPN for your worker, where your sub requests can appear as if they're coming from your network. but you still can keep your compute on our platform.

9:55The coolest feature of Work of GBC, though, is arguably the Cloudflare 1 network binding, which lets you use the existing Cloudflare 1 routing table, which exposes not just Cloudflare Tunnel, but all of our other off-ramps, including the Layer 3 off-ramps like Cloudflare WAN for IPsec and Cloudflare Network Interconnect and Cloudflare Mesh. And something else that happens when you're using the CF1 network binding is your traffic. is going through Cloudflare Gateway. And this means your traffic that is coming from workers VPC using the CFO network binding is logged and processed and has policies applied to it just like traffic coming from the Cloudflare One client or from Cloudflare WAN. And so this lets you use Gateway to monitor what is happening in your workers. And this is really useful if you're running agents and workers because you can use all of the same protections that you use for your employees for agentic traffic.

10:44And so you can set up Gateway. to log all the network traffics from your agents and you can also use gateway policies to filter the sites your agent can access you can use our data loss prevention product to inspect network payloads coming to and from your agents and for sensitive data the cloud for one network like i said supports more layer three off ramps like ip sexy and i and mesh and those work differently behind the scenes than when we send traffic to cloud for tunnel for layer four tunnels we're getting a byte stream out of workers and We're just proxying that over to Cloudflare D. And it's Cloudflare D, the machine that it's running on, is responsible for turning that into Layer 3 packets. But when we're off-ramping to one of our Layer 3 products, it's Cloudflare's responsibility to take that byte stream coming out of workers and turn it into packets.

11:29And one of the difficult problems of that is that could happen on any machine in our fleet. And so we need to make sure that we have a way to get that traffic back to the same machine that initiated the Layer 4 to Layer 3 downgrade. And the way it's done is that we're going to do it. we do that is with Cloudflare source IPs, which identify the specific Cloudflare metal that is being used for the downgrade. So when they come back with the return side packets with that source IP now in the destination field, any of our metals is able to look at that packet and then route it to the original metal responsible for the downgrade. It can get turned back into a byte stream and returns to the worker. What's coming next for Worker ZPC? We're exploring more connectivity options inside of VPC services. We want to support MTLS so you can configure the client cert and private key that's going to be used when we establish the TLS session.

12:21And you can configure a list of server certs that you trust. And we want to support more connectors like Mesh so you can provide the ID of a mesh node, not just the tunnel ID when you create a VPC service. And we're also looking into deeper integrations with Gateway. We want to make it possible to tag traffic that's coming out of workers. And... one of the neat things that this might enable is tagging traffic with an identity that you can create at runtime and this might be useful for agentic workloads that are running in dynamic workers or in sandboxes you'd be able to to run those and your um your runtime around them can decide this this agent is running on behalf of this human and you can use a policy that is not just operating on an agent pretending to be a human but an agent opera using delegated authority that will be separate and um i think this is gonna enable a ton of neat use cases.

13:08And so let's recap. VPC services are best for exposing specific private resources without having to configure a routing table. VPC networks are best for when you want to connect to a whole tunnel and expose everything that that tunnel can access. Or if you want to leverage your existing investment in the Cloudflare 1 routing tables, or you want to use one of our Layer 3 off-ramps, um, CF1 network. bindings also let you send traffic through cloud for gateway for using gateway policies for filtering or data loss prevention or doing logging for traffic awesome thank you guys for coming

Browse all
Connect 2027

Connect returns in 2027

Be the first to know when registration opens and the agenda goes live.

By submitting this form, you agree to our Privacy Policy.

cloudflare-connect-2026

---
title: "Cloudflare Workers VPC: Build globally, connect privately"
url: "https://www.cloudflare.com/connect/2026/session/cloudflare-workers-vpc-build-globally-connect-privately"
year: 2026
---

# Cloudflare Workers VPC: Build globally, connect privately

[Watch session](https://www.cloudflare.com/connect/2026/session/cloudflare-workers-vpc-build-globally-connect-privately)

## Session details

- **Track:** Network & Infrastructure
- **Topics:** Cloudflare product innovations, Customer Experience, Programmable Platforms
- **Solution areas:** Core Platform, Application Security, Application Performance, Developer Platform

## About this session

Cloudflare Workers applications often need to reach APIs and databases that cannot be exposed to the public Internet. Cloudflare Workers VPC connects Workers and Hyperdrive to private networks through existing Cloudflare One connectivity, including Cloudflare Tunnel. This session follows a request from a Worker to a private service: how Cloudflare resolves a private hostname, carries the connection, returns traffic without giving the Worker a stable network identity, and limits access through explicit bindings. It also compares a VPC Service for one approved destination with broader VPC Network access for dynamic destinations, account-wide routes, and Gateway-controlled egress.

## Speakers

- [Matt Alonso](https://www.cloudflare.com/connect/speakers/2411666) — Senior Systems Engineer, Cloudflare

## Transcript

[0:03] My name is Matt Alonzo, and I'm a senior systems engineer here at Cloudflare. I've worked here for six years. I started off on the Durable Objects team and helped launch that product, then helped launch Hyperdrive. And for the past year, I've been working on our private networking products, primarily Cloudflare Workers VPC. And Workers VPC is really neat because it lets you build your applications on Cloudflare, but it lets you connect to your resources. that run outside of Cloudflare, whether it's on-premise or running in a hyperscaler VPC. Before Worker's EPC, when you used Cloud for Workers, your only option for connecting to things outside of Cloudflare was if they were on the public internet. And that meant attackers could access those resources too. And if you had something running in a hyperscaler VPC, it was up to you to set up an internet gateway to publicly expose that resource and secure it.

[0:55] And even if you did, set that up there's challenge of getting it right and some other problems beyond attack surface bandwidth pricing for getting data out of the hyperscaler vpcs is built by the gigabyte and it's built at an elevated rate compared to data that egresses over private connections and this can really add up if you're moving a lot of data into our developer platform and we already had a solution for private networking we have our cloud for one suite which has several different connectors traffic into and out of the Cloud4One network from the Cloud4One client that runs on your employee laptops to Cloud4Tunnel, which lets you connect to resources in a private network, Cloud4Mesh. We have Cloud4WAN for IPsec and Cloud4Network interconnect for like an actual physical cable between us and your private network. And this allowed physical devices and VMs to reach the Cloud4One network, but there wasn't a way for workers in our developer platform products to get their traffic into the Cloud4One network.

[1:52] And that's the problem that WorkerZPC solves. It's the missing piece that brings the developer platform into your Cloud4One network. And it acts as an on-ramp for traffic coming from both Cloud4Workers and HyperDrive and can reach private resources via our existing Cloud4One connectors from Tunnel to Mesh and WAN and CNI.

[2:14] The Cloud4One client and other on-ramps like Cloud4WAN work differently than WorkerZPC. With the Cloud4One client... your resources are exposed as if they were just available on your local area network. But when using Worker's DPC, we don't expose your private resources through the global fetch handler on your worker. Instead, we expose those private resources using bindings. If you haven't used Worker's before, bindings are live objects that are accessible from worker's code, and you configure them in your Wrangler configuration for your worker to define what resources on the developer platform that your worker can access at runtime. And so the Worker's VPC binding has two options. You can use it for HTTP and you'll get a fetch method on your binding or you'll get a connect method if you're using a TCP service.

[3:00] And in order to create a Worker's VPC binding, you need a bindable object to actually bind to when you upload your worker. And that is what a VPC service is. And so to expose a specific private resource as a bindable object, you have to create a VPC service. a name and it has a type and there's two types of VPC services there's the TCP variant which exposes a single port or the HTTP variant on for the HTTP variant you can have a plaintext service you can have encrypted only service or you can support both HTTP and HTTPS which is the default on the standard ports and the whole point of the VPC service is it kind of it describes an origin and so it stores all of the metadata that's necessary to establish a connection to that origin and so beyond the port you have to provide a host name or an ip address and then you have to provide something that we call a resolver network which is a single object that defines both the resolver to use for private host names and the network that any resolve private ips or if you specify an ip that that private ip is routable on and so if you notice here we have only a single tunnel id and in the configuration for the resolver network and that's because cloud for tunnel um now has a built-in dna proxy in it that allows our network to access your private resolver that's running in your network by proxying DNS queries from us through to your private resolver.

[4:17] And so you only have to provide a tunnel ID and you're able to get both resolver and a network out of that. But you still have the option of manually specifying a resolver IP if you want, depending on your use case.

[4:34] In order to create a VPC service and in order to bind to a VPC service, you need different permissions. And the point of this is kind of separate who is allowed to do what with this product. For network admins who might want to expose private resources to developers on the same account you need to give them the connectivity directory admin role and this lets you control who can expose resources while developers can be given the connectivity directory bind role which allows them to only bind to existing workers vpc services that have already been created. Once you have a VPC service, you're able to add it to your Wrangler configuration by specifying the service ID that was returned from creation and need to give it a binding name which is what's going to show up on the end of object when you go and write your worker And you'll get that fetch method that I mentioned earlier using an HTTP service.

[5:26] And something to keep in mind for the fetch and connect method on a VPC service binding is the hostname in fetch is not used for routing. You already specified what you're going to be routed to. in your VPC service configuration. And so that host name is only used in the host header for the requests that are being sent to your origin and will not be used for routing.

[5:48] I mentioned that we also support TCP services, and this is also useful for connecting to private databases. With Hyperdrive, it's not just for workers. And the way to do this is you can specify an app protocol in your TCP service definition. And for Hyperdrive, you can do either postgres or mysql um and just as you're able to uh set a service a vpc service in your wrangler configuration you can set a vpc service in your hyperdrive configuration under the origin field instead of providing um like the typical fields that you would have in a connection string um because you access private databases that are running on premise or maybe you're using a hosted database product in one of the hyperscalers and you can do this just by running tunnel in your vpc and you're able to access that database without having to expose it to the public internet.

[6:40] VPC works pretty similar to the Cloud for One client and it is also an on-ramp, but the way that we actually proxy traffic behind the scenes is pretty different. Workers, VPC is not a layer three on-ramp like the Cloud for One client and Cloud for WAN. Those on-ramps are getting traffic into Cloudflare as packets that are already coming out of an operating system. But with WorkerZPC, this is different because we run workers in a sandbox. They're not virtual machines, they're not containers, and so they don't have access to the host OS. Everything that a worker can do is defined by the bindings that it has and the implementation of those bindings in the worker's runtime. And for WorkerZPC, we don't expose the host OS There's no good way to configure the system resolver to on-demand to use a specific private resolver.

[7:29] and that traffic through a tunnel. And so we implement a user space DNS client. And that allows us to send the DNS queries for the private host name and your VPC service configuration when a connection is initiated by your worker by calling the fetch method on the binding through to a clopter tunnel and through to your private DNS resolver. The results come back for the private host name and you get a private IP. And we're then able to establish a connection. If you notice here, a worker's VPC is all... responsible for doing the TLS session. That is because we don't want to do any encryption inside of the shared worker sandbox. We'd like to keep that outside of the shared address space. And so the plain text byte stream that comes out of Cloudflare workers gets upgraded into the TLS session and that flows on to your private origin. And from the perspective of your private origin those packets are going to appear as if they're coming from the machine that the Cloudflare D is running on with the same source IP as that machine.

[8:26] And so VPC services are really great for if you want like per-resource capabilities. You want to define specific destinations that you know about ahead of time. They're also useful when you don't want to have a single global routing table. A good example of when this can happen is let's say you do an acquisition and you have multiple hyperscaler VPCs that are under your responsibility. And they're all using the same shared address space. If you had a global routing table, you'd have to decide what VPCs you're going to change. that address space to use. But with VPC services, you're defining your resources and you're giving them an ID. And so workers can identify those resources by their ID instead of using IPs which can conflict across networks. But sometimes you don't want to specify all of your private resources ahead of time.

[9:12] Maybe you're doing service discovery or you need to connect to a ton of resources or change that at runtime. And that's what the VPC network binding is for. And we have two variants of the VPC network binding. There's the VBC network binding to tunnels and the VBC network binding to the entire Cloudflare One network. And for VBC network bindings to tunnels, you're exposing everything that Cloudflare D can access. So if Cloudflare D is running, anything that it can access, including the public internet, is available. And this is useful for not just connecting to dynamic resources and your private APIs and data databases, but you can also connect to things on the public internet. And it's kind of like a VPN for your worker, where your sub requests can appear as if they're coming from your network. but you still can keep your compute on our platform.

[9:55] The coolest feature of Work of GBC, though, is arguably the Cloudflare 1 network binding, which lets you use the existing Cloudflare 1 routing table, which exposes not just Cloudflare Tunnel, but all of our other off-ramps, including the Layer 3 off-ramps like Cloudflare WAN for IPsec and Cloudflare Network Interconnect and Cloudflare Mesh. And something else that happens when you're using the CF1 network binding is your traffic. is going through Cloudflare Gateway. And this means your traffic that is coming from workers VPC using the CFO network binding is logged and processed and has policies applied to it just like traffic coming from the Cloudflare One client or from Cloudflare WAN. And so this lets you use Gateway to monitor what is happening in your workers. And this is really useful if you're running agents and workers because you can use all of the same protections that you use for your employees for agentic traffic.

[10:44] And so you can set up Gateway. to log all the network traffics from your agents and you can also use gateway policies to filter the sites your agent can access you can use our data loss prevention product to inspect network payloads coming to and from your agents and for sensitive data the cloud for one network like i said supports more layer three off ramps like ip sexy and i and mesh and those work differently behind the scenes than when we send traffic to cloud for tunnel for layer four tunnels we're getting a byte stream out of workers and We're just proxying that over to Cloudflare D. And it's Cloudflare D, the machine that it's running on, is responsible for turning that into Layer 3 packets. But when we're off-ramping to one of our Layer 3 products, it's Cloudflare's responsibility to take that byte stream coming out of workers and turn it into packets.

[11:29] And one of the difficult problems of that is that could happen on any machine in our fleet. And so we need to make sure that we have a way to get that traffic back to the same machine that initiated the Layer 4 to Layer 3 downgrade. And the way it's done is that we're going to do it. we do that is with Cloudflare source IPs, which identify the specific Cloudflare metal that is being used for the downgrade. So when they come back with the return side packets with that source IP now in the destination field, any of our metals is able to look at that packet and then route it to the original metal responsible for the downgrade. It can get turned back into a byte stream and returns to the worker. What's coming next for Worker ZPC? We're exploring more connectivity options inside of VPC services. We want to support MTLS so you can configure the client cert and private key that's going to be used when we establish the TLS session.

[12:21] And you can configure a list of server certs that you trust. And we want to support more connectors like Mesh so you can provide the ID of a mesh node, not just the tunnel ID when you create a VPC service. And we're also looking into deeper integrations with Gateway. We want to make it possible to tag traffic that's coming out of workers. And... one of the neat things that this might enable is tagging traffic with an identity that you can create at runtime and this might be useful for agentic workloads that are running in dynamic workers or in sandboxes you'd be able to to run those and your um your runtime around them can decide this this agent is running on behalf of this human and you can use a policy that is not just operating on an agent pretending to be a human but an agent opera using delegated authority that will be separate and um i think this is gonna enable a ton of neat use cases.

[13:08] And so let's recap. VPC services are best for exposing specific private resources without having to configure a routing table. VPC networks are best for when you want to connect to a whole tunnel and expose everything that that tunnel can access. Or if you want to leverage your existing investment in the Cloudflare 1 routing tables, or you want to use one of our Layer 3 off-ramps, um, CF1 network. bindings also let you send traffic through cloud for gateway for using gateway policies for filtering or data loss prevention or doing logging for traffic awesome thank you guys for coming

## Related sessions

- [Your agent wrote it. Who’s on call?](https://www.cloudflare.com/connect/2026/session/your-agent-wrote-it-whos-on-call)
- [How the Internet really works: Into the depths of Internet infrastructure](https://www.cloudflare.com/connect/2026/session/how-the-internet-really-works-into-the-depths-of-internet-infrastructure)
- [Building P1 on Cloudflare: AI-native web composition and governance](https://www.cloudflare.com/connect/2026/session/building-p1-on-cloudflare-ai-native-web-composition-and-governance)

## More from Connect

- [All sessions](https://www.cloudflare.com/connect/)
- [Get notified for Connect 2027](https://www.cloudflare.com/connect#2027)