Network peering
Connect project networks with explicit route exchange and project consent.
Network peering permits traffic between two approved private networks. Both sides retain their own address allocation, firewall policy, and resource ownership.
Request a connection
Open Network → Connections → Request peering and select the remote network ID. Networks must be in a supported connectivity scope and have non-overlapping routable ranges. Cross-project peering requires an authorized operator in each project to approve its side.
The request records the proposed subnet export set. The remote project can accept that set, narrow its own exports, or reject the request. A pending request creates no active forwarding path.
Route exchange
Accepted peering installs routes only for approved subnet prefixes. It does not export the remote project's default route, public egress, or other peering connections. Peering is non-transitive: a path from A to B and from B to C does not provide A with a path to C.
Address overlap introduced by a later subnet edit is rejected while it would conflict with the connection. A route prefix that becomes unavailable is removed from the active export set and recorded in the connection journal.
Firewall and DNS
Peering establishes reachability, not an allow rule. Configure source and destination firewalls for the actual private ranges or supported remote identity selectors. A rule allowing the local network does not implicitly include its peers.
Private DNS zones are not exported automatically. Add conditional forwarding or explicit service records when clients need remote names. Verify that resolution does not expose unrelated project records.
Validate before traffic changes
Check the connection's applied revision on both sides. Test a dedicated service from each direction, including the intended protocol and response size. A working ICMP test does not establish that the application port or return path is permitted.
For a connection replacing a VPN path, inspect route preference and return routing before switching production traffic. Asymmetric paths can interact with stateful firewalls and connection tracking.
Revoke or delete
Either side can revoke peering. New forwarding stops after the withdrawal is applied; existing connections can break. The other project receives a connection state event but retains its own resources and audit history.
Deleting a project with active peerings requires withdrawal first. The connection record does not grant the requesting account permission to read or mutate remote droplets. Use Routes, Firewalls, and Network API to inspect each layer separately.