Cloudflare Workers now support explicit selection of a virtual network for each VPC binding by using the network_id field with the format cf1:vnet:<UUID>. The previous shortcut cf1:network still points to the account’s default VPC. This change enables a single Worker script to attach to multiple, isolated VPCs, which is useful when back‑ends reuse the same private address ranges.
How to Bind a Worker to a Specific VPC
In the Wrangler configuration, replace the generic network identifier with the full VNET reference. The snippet below shows the JSONC representation; the equivalent TOML format follows the same key/value pattern.
{
"$schema": "./node_modules/wrangler/config-schema.json",
"vpc_networks": [
{
"binding": "PRODUCTION",
"network_id": "cf1:vnet:",
"remote": true
}
]
}
For TOML, the same binding looks like:
[[vpc_networks]]
binding = "PRODUCTION"
network_id = "cf1:vnet:"
remote = true
Multiple VPC Bindings in a Single Worker
Because each entry in vpc_networks is independent, you can declare several bindings, each pointing to a different VPC. This pattern solves the classic problem of two services that both expose, for example, 10.0.0.5 on separate private networks. By assigning distinct binding names, the Worker can address each back‑end without IP conflict.
Operational and Security Considerations
- Configuration hygiene: Every binding must contain a valid UUID. Mistyped IDs will cause deployment failures or silent routing to the default network.
- Network isolation: Separate VPCs keep traffic segregated at the network layer. Engineers should verify that required firewall rules exist in each VPC for the Worker’s egress.
- Remote flag: The example sets
remote = true, indicating the Worker runs in the remote VPC context. Changing this flag may affect latency and billing; confirm the intended mode before promotion. - Deployment impact: Adding or removing bindings triggers a redeploy of the Worker script. Plan changes during a maintenance window if downstream services are sensitive to brief connectivity loss.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopt the explicit network_id syntax whenever you need to reach a non‑default VPC or when multiple back‑ends share private address spaces. Review existing Worker configurations for implicit defaults and replace them with concrete VNET IDs to gain predictable routing. Validate each UUID against your Cloudflare dashboard, test connectivity in a staging environment, and update any associated firewall policies. Monitoring should include checks that the expected VPC binding is active after each deployment.
