Skip to main content
Popsink connectors are always the client: a connector worker opens an outbound TCP connection to your database and keeps it open. When that database is reachable over the public internet and fronted by a firewall, the rule you need is an inbound one on your side, whose source is the address the connector leaves from. On a Popsink-managed deployment, that address is one of the static egress IPs below, fixed per region.

​
Addresses

Each is a single address — allowlist it as a /32 (34.78.134.240/32, and so on). They are static and do not rotate; we announce any change before it takes effect.
Allowlist the region your deployment runs in, and any region you may be moved or expanded to. If you are not sure which one you are on, ask support@popsink.com — or simply allowlist all five, which costs nothing and survives a region change.

​
Writing the rule

The rule is always the same shape: source one of the addresses above, destination your database host, port the database port only. Popsink needs no inbound path other than that, no callback and no reverse tunnel.
An IP allowlist is a filter, not authentication. Keep TLS on and keep the connector’s credentials least-privilege — see Security and compliance.

​
When this page does not apply

Connectors run in your cluster, so they leave from your egress address, not ours. Give the cluster a stable one — a NAT gateway with a fixed IP — and allowlist that; the routing gotcha section explains why a pod IP is not usable here.
If the database has no public address at all, an allowlist cannot help and you need a tunnel instead — IPsec, SSH or an overlay network. See Tunnels and private connectivity.
These addresses cover connector traffic to your sources and targets. The control plane never initiates a connection into your network at all; see Control plane and data plane.

Tunnels and private connectivity

The alternative when the source has no public address to allowlist from.