Skip to main content
IoT Manager devices only ever make outbound connections. There is nothing to open inbound, no port forwarding to configure, and no static/public IP required — the dashboard reaches your devices through a reverse tunnel that the device itself initiates.

​
What the device connects to

DestinationPortPurpose
api.iotmanager.dev443 (HTTPS)Device registration, telemetry reporting, uninstall callback
*.tunnel.iotmanager.dev443 (WSS)Reverse tunnel — terminal, file transfer, container control, public URLs
Both connections are standard HTTPS/WebSocket-over-TLS on port 443 — if your network already allows normal outbound web browsing, it allows this too. No unusual ports, no custom protocols.

​
Behind a restrictive outbound firewall

If your network only allows specific outbound destinations (common in industrial/locked-down environments), allowlist: 
api.iotmanager.dev:443
*.tunnel.iotmanager.dev:443
The exact subdomain under tunnel.iotmanager.dev is assigned per-device and can vary — allowlisting the wildcard is the reliable option. If your firewall doesn’t support wildcard TLS/SNI-based rules, allowlist by destination port 443 to any host under tunnel.iotmanager.dev instead of trying to pin an exact hostname.

​
What’s NOT needed

  • No inbound ports — the device is never listening for connections from the internet.
  • No VPN.
  • No static/public IP address. Devices behind NAT, CGNAT, or on a private LAN with no port forwarding work identically to devices with a public IP.
  • No SSH daemon exposed publicly — the agent’s built-in SSH server only ever accepts the reverse tunnel connection it initiated itself; nothing needs to reach it from outside.

​
Local/offline access

If a device is fully air-gapped (no internet at all), the reverse tunnel obviously can’t connect — but the device’s local web UI is still reachable directly on your LAN. See Offline Use.