Networking & Egress
Marshal is designed to run entirely inside your own network. This page covers the network model you should expect, the outbound access the cluster needs, and how to plan access for whoever runs the install. For the pieces that make this possible architecturally, see Architecture; for the full pre-install checklist, see Installing Marshal.
The network model
By default, Marshal’s Kubernetes control plane and the application itself are not exposed to the public internet. Everything — the API, the gateway, the web dashboard, and every session pod — runs inside your VPC or VNet, reachable only from inside your network (or through whatever access path you choose to expose, such as your own internal load balancer or ingress).
No inbound access into your environment is ever required for Marshal to operate. The cluster only needs to make outbound connections — nothing on the Marshal side needs to reach in.
Reaching the cluster during install
Because the cluster isn’t exposed to the internet, whoever runs the install
(terraform apply, helm install, or your GitOps sync) needs a way to reach
inside your network first.
You already have VPN or bastion access
Nothing extra to set up — run the install from a machine that already has VPN or bastion access into the target VPC/VNet, the same way you’d reach any other private resource in your network.
Outbound egress the cluster needs
The cluster needs outbound HTTPS (443) to two destinations, and nothing else:
| Destination | Purpose |
|---|---|
registry.marshal.codes | Image and Helm chart pulls. In a production install this traffic is routed through a pull-through cache that runs in your own environment — your nodes pull from your own registry mirror, and the cache is the only thing that talks to registry.marshal.codes directly. See Installing Marshal for how the cache is set up on your target cloud. |
keys.marshal.codes / tokens.marshal.codes | License verification — the cluster checks your installation credentials against Marshal’s public keys and refreshes them periodically. |
That’s the complete list. Marshal doesn’t need outbound access to anything else to operate, and — as noted above — never needs inbound access into your environment.
If your network policy blocks egress by default, allow-list exactly these two destinations (plus your own internal DNS/NTP/etc. as usual) rather than opening broader outbound access.
Planning access for the install
Before you start the install, make sure you’ve settled:
- Who runs the install, and from where — their own machine, or a bastion — and that they have (or can get) network access into the target VPC/VNet.
- Egress rules cover the two destinations above.
- Your hostname decision — the internal hostname your developers will
use to reach Marshal (e.g.
marshal.yourcompany.com). You don’t need working DNS yet, just the string, since it’s required as input before the first install step. You’ll wire the actual DNS record once the cluster’s load balancer has an address.
The full prerequisite checklist — credentials, database, tooling — lives in Installing Marshal.