Egress gateways and source translation
Give private workloads controlled outbound access through stable public identities.
Egress gateways translate permitted outbound traffic from a private network to an assigned public address. They do not publish an inbound listener for each private droplet.
Configure an outbound path
Create a gateway under Networking → Gateways, select its private network, and assign a regional public address. Add the gateway as the appropriate default or destination-specific route. A gateway without a route receives no selected traffic from the network.
Set an outbound firewall policy before connecting production guests. Translation does not grant permission to destinations that the effective firewall rejects. DNS access is a separate requirement from HTTPS access to the resolved address.
Stable source identity
External services observe the configured egress address where translation applies. Use that address in provider allowlists only after testing the actual path. A guest with a direct public route can bypass a default gateway depending on its interface and route configuration.
Changing the egress address affects new translated flows after application. Existing flows can continue under their connection state or be interrupted during the transition. Keep both addresses permitted at external providers while a reviewed migration requires overlap.
Connection capacity
Translation consumes connection-tracking entries and source-port capacity. Large numbers of short-lived connections to the same destination can exhaust that capacity before the gateway reaches its throughput limit.
Monitor active mappings, failed allocations, packet drops, and gateway health. Reuse application connections where appropriate and add supported address capacity rather than assuming more guest vCPU will resolve an egress limit.
Redundancy
Select the region's supported redundant gateway mode when private services need outbound access through a host failure. Failover preserves the configured service identity, but connection continuity depends on the gateway mode and state path. Applications must handle interrupted external connections.
Do not implement a hidden second gateway by pointing another guest at the same public address. Address ownership and route activation must use the managed service's failover procedure.
Remove a gateway
Move or remove its dependent routes first. Check package mirrors, external APIs, backup workers, and identity-provider calls that use the path. Gateway deletion can leave an otherwise healthy private application unable to reach dependencies.
Detach or release the public address explicitly according to retention policy. A stopped gateway can still retain an address reservation. See Public address API and Route API for those independent resources.