Network Requirements
Estuary manages your data plane by connecting to it, so each instance accepts inbound connections on a small set of ports.
These requirements are the same for private and BYOC deployments in AWS, GCP, and Azure. Estuary configures the data plane's own security rules in both cases. On a BYOC deployment, where the data plane runs in your own cloud account, check that any firewall, routing, or policy controls you maintain around it allow the traffic below. Share these requirements with your security team early, so the network design is settled before provisioning.
How Estuary reaches your data plane
The brokers and reactors that run your tasks accept inbound connections on port 443 from two sources:
- Estuary's control plane, which starts connectors and applies your task configuration.
- Your own users, who connect to preview data, read collections, and view task logs. This path exists so your data travels from your data plane straight to your users, without passing through Estuary's control plane. It is optional, and only applies to the dashboard features that read data directly.
Each instance has its own address and is reached individually rather than through a load balancer or a single virtual IP, which means a NAT or DNAT rule pointing at one backend will not work.
Ports
| Port | Role | Purpose | Source |
|---|---|---|---|
| 443 | Brokers and reactors | The main data plane API surface | Estuary's control plane and your users, or your allowlist |
| 9092 | Dekaf | The Kafka-compatible endpoint, if your deployment includes Dekaf | Your Kafka consumers, or your allowlist |
| 2222 | Bastion | Administrative access | Estuary's management addresses, or your allowlist |
| 22 | All | SSH for instance management | Estuary's management addresses only |
| 2379-2380 | etcd | Coordination between your data plane's instances | Your data plane's subnet |
All ports are TCP.
Controlling who can connect
A public address does not have to mean open to the internet. Estuary can apply an allowlist so your data plane accepts connections only from:
- Estuary's control plane addresses, which are added for you.
- Any networks you choose, such as your corporate VPN egress ranges for your users.
Every other source is refused at the network layer. Customers with strict network policies run this way today. To set it up, send your Estuary representative the CIDR ranges you want to allow.
Traffic is encrypted in transit and authenticated with certificates issued per data plane, so an allowlist adds to those protections rather than replacing them.
Outbound access
Your data plane also makes outbound connections. Where your own network policies filter egress, such as a firewall in front of a BYOC deployment, allow these categories:
- Estuary services, for the control plane API, log and metric shipping, and task build artifacts.
- Container registries, for connector and platform images. On a BYOC deployment this includes any registry your own connectors pull from.
- Cloud provider services, for object storage holding your collection data, key management, and identity endpoints when you use IAM authentication.
- Operating system and agent updates, for package repositories, time synchronisation, and TLS certificate renewal.
- Your own sources and destinations, on whatever ports those systems use.
The exact hostnames depend on your cloud, your region, and which connectors you run, and we may change and add categories as the platform evolves. Ask your Estuary representative for the current list rather than deriving one, so your rules stay correct after a platform update.