Relay for restricted networks
Most fleets do not sit on an open network. Devices live behind NAT, on factory VLANs, or behind a corporate firewall that allows only outbound traffic. The question for any fleet platform is the same: how does the control plane reach a device it cannot dial? Meshanics answers it by never needing to dial in.
The connection model: outbound only
The agent initiates every connection. It dials the control plane over a mutually authenticated (mTLS) channel, registers, and then heartbeats on an interval the server assigns. The control plane never opens a connection back to a device.
This has direct consequences for restricted networks:
- No inbound ports on devices. A device needs no public address, no port forward, and no inbound firewall rule. It works behind NAT unchanged.
- Egress is all you allow. The only requirement is that the device can make outbound connections to the control plane's device endpoints.
- Desired state flows on the device's own poll. Update assignments are delivered in the heartbeat response, so a device picks up work the next time it reaches out — there is nothing to push at it.
device (behind NAT) control plane
────────────────── ─────────────
agent ──── outbound mTLS ─────────▶ device API (register, heartbeat)
agent ──── outbound mTLS ─────────▶ artifact repo (verified pull)
◀── desired state in response ──
What a restricted network must permit
For a device to be managed, its network needs to allow outbound, mutually authenticated connections to two endpoints on the control plane: the device API, where it registers and heartbeats, and the artifact repository, from which it pulls verified updates. Both are mTLS-only; both run on stable ports you choose at deployment.
If your environment forces traffic through an egress proxy, route the agent's outbound connections through it the way you would any other service on the host.
Bringing the control plane closer
When even outbound reach is constrained — a cell that can talk to a local gateway but not to a central site — the control plane can be placed inside the restricted zone. A single-node deployment on a local box gives devices a control plane they can reach with a short, local egress rule, while the operators who run rollouts work against that same node. For a zone with no path out at all, see Offline & air-gapped operation.
On the roadmap
For environments where devices cannot reach any control plane directly, we are developing a dedicated relay: a forwarding component you place at the network boundary so a device's outbound connection terminates locally and is carried to the control plane on its behalf, without granting either side inbound access to the other. The trust model does not change — the device still pins its own anchor and verifies every update itself; a relay only carries bytes. This is in progress and not part of the current release; the outbound-only model above is what ships today.