Network Security
The network model rests on two rules that work together. At the cloud edge, a public client can only reach a service if its source IP matches the service's allowed_cidrs allowlist; a default-deny baseline drops everything else. Private cluster traffic (replication, attachments, and east-west connections between your apps and services) travels over an internal SDN subnet that never crosses the public edge, so it is unaffected by the allowlist.
IP Allowlisting
By default, a new service rejects all inbound connections. You must explicitly allow your IP ranges before any client can connect.
How the allowlist is evaluated
allowed_cidrs is an explicit allowlist applied at the cloud-edge firewall. Each inbound connection to an exposed port is checked against the list:
- If the source IP falls inside any listed CIDR, the connection is accepted and proceeds to the TLS handshake on the engine's port.
- If it matches none of them, the default-deny baseline drops it before it reaches the database. No port scan, banner, or error is returned.
The allowlist governs only public ingress to the exposed engine ports. It never affects internal SDN traffic.
Add your IP
Find your current public IP, then append a /32 host route for it:
# Your current public IP
curl -s ifconfig.me
# Add it (keep any existing entries, PATCH replaces the whole list)
curl -u admin:password -X PATCH \
https://api.foundrydb.com/managed-services/{id} \
-H "Content-Type: application/json" \
-d '{"allowed_cidrs": ["203.0.113.10/32", "10.0.0.0/8"]}'
allowed_cidrs is replaced wholesale on each update, so always send the complete desired list, not just the new entry.
Add allowed CIDRs
curl -u admin:password -X PATCH \
https://api.foundrydb.com/managed-services/{id} \
-H "Content-Type: application/json" \
-d '{"allowed_cidrs": ["203.0.113.10/32", "10.0.0.0/8"]}'
View current allowed CIDRs
curl -u admin:password https://api.foundrydb.com/managed-services/{id} \
| jq '.allowed_cidrs'
Remove access
To remove all external access (e.g. after maintenance):
curl -u admin:password -X PATCH \
https://api.foundrydb.com/managed-services/{id} \
-H "Content-Type: application/json" \
-d '{"allowed_cidrs": []}'
CIDR Recommendations
| Scenario | CIDR |
|---|---|
| Single server | 203.0.113.10/32 |
| Office network | 203.0.113.0/24 |
| VPC / private network | 10.0.0.0/8 or tighter subnet |
| CI/CD (static IP) | 203.0.113.100/32 |
Avoid 0.0.0.0/0 unless you are behind a separate firewall or gateway.
DNS
Every service gets a fully qualified domain name:
{service-name}.{region}.foundrydb.com
Replicas are addressable individually:
{service-name}-replica-1.{region}.foundrydb.com
DNS is automatically updated during failover, you do not need to change connection strings when a replica is promoted.
Ports
Only the database port (or ports) for the selected engine are exposed at the cloud edge, and even those are reachable only from IPs in allowed_cidrs. No SSH, admin UIs, or management APIs are reachable from the internet.
| Engine | Exposed ports |
|---|---|
| PostgreSQL | 5432, 5433 (PgBouncer) |
| MySQL | 3306, 6033 (ProxySQL) |
| MongoDB | 27017 |
| Valkey | 6380 (TLS) |
| Kafka | 9093 |
| OpenSearch | 9200 |
| SQL Server (Babelfish) | 1433, 5432 |
Exposed vs SDN-only ports
Some engines bind ports that are not exposed at the cloud edge. These carry cluster-internal traffic only and are reachable solely from inside the service's private SDN subnet, never from the public internet:
- Valkey exposes the TLS port
6380to clients. The non-TLS port6379is bound for SDN-internal replication and Sentinel coordination and is blocked at the cloud edge. - Inter-node traffic (PostgreSQL streaming replication, MySQL replication, MongoDB replica-set heartbeats, the Kafka KRaft quorum, OpenSearch transport) stays on the SDN. None of these listeners are exposed publicly.
The default-deny baseline means the absence of a rule is the absence of access: if a port is not explicitly exposed for the engine, it is unreachable from the internet regardless of allowed_cidrs.
Private SDN Traffic
Replication between nodes, attachment connections to companion apps, and east-west traffic between your own services travel over a private SDN subnet that is dedicated to the cluster. This path bypasses the public firewall entirely: it is not governed by allowed_cidrs, is not reachable from the internet, and does not consume an exposed public port.
This separation is why you only ever need to allowlist the client IPs that connect from outside. Internal cluster traffic is already isolated.
Network Isolation
Each service runs on a dedicated virtual machine. Services in your account do not share compute or storage with other customers. Network-level isolation is enforced at the hypervisor.