Network Requirements

What Swarmfile actually talks to on the network, so you can configure a firewall allowlist before rollout instead of discovering it by trial and error. Everything below is what the desktop client (engine + tray) initiates outbound - nothing here requires an inbound port opened on your firewall for ordinary use.

Summary#

Which exact hub/identity/releases/updates hostnames a given install uses is a per-install config.json setting, not something baked into the binary at compile time - a fresh install on the standard hosted plan defaults to the prod hosts above; check that file on a specific machine if you need to confirm. See Engine Config File.

Control plane and identity#

The engine talks to one hub host for everything that isn't peer-to-peer file transfer: browsing and editing metadata, reading and writing file content when no peer has it (the "cloud fallback" - this goes through the hub's own storage proxy, not a separate storage domain), and a live SSE connection that pushes changes from other users in real time. Sign-in and token refresh go to a separate identity host - the built-in IdP by default, or your own SAML/OIDC provider if you've configured bring-your-own SSO (see Identity).

Both are plain HTTPS on port 443. No other port is used for control-plane or identity traffic.

Peer-to-peer file transfer#

By default, machines in the same office exchange file data directly over QUIC (UDP) rather than always routing through the cloud - this is what makes LAN-first fast. The engine binds to an OS-assigned ephemeral UDP port for this; it does not listen on a fixed, predictable port unless you explicitly set one (SWARMFILE_IROH_BIND_ADDR in config.json - an operator choice for a specific deployment, not a default).

Peer-to-peer relay and discovery#

Two pieces of this are third-party infrastructure Swarmfile doesn't operate itself, run by Number Zero (the maintainers of the P2P transport Swarmfile builds on):

• Relay fallback, used when two peers can't establish a direct connection (e.g. both behind restrictive NATs): a handful of regional relay hosts (*.relay.n0.iroh.link), reached over HTTPS/443 with QUIC address-discovery on UDP/7842.
• Peer discovery, used to look up how to reach another peer: dns.iroh.link, over HTTPS and plain DNS.

If your firewall policy needs to name every host P2P might touch, these are worth listing alongside your own hub domain - though in practice, if UDP/QUIC is blocked entirely (common on locked-down corporate networks), the simpler answer is usually hub-only mode rather than trying to allowlist P2P traffic through it.

LAN peer discovery#

Finding peers on the same local network uses standard mDNS (multicast DNS, the same mechanism as Bonjour/AirPlay discovery) - no custom protocol, no non-standard port. If your network already blocks mDNS multicast (some corporate/VLAN setups, and Docker bridges, do this by default), Swarmfile still works - it just can't discover LAN peers automatically, and every read falls back to the peer-relay path or the cloud. There's a separate lan_from_office setting for networks that block multicast but where you still want deliberate LAN peer placement; see Deployment Topologies.

Hub-only mode#

For a network that blocks UDP/QUIC outright, or a security policy that wants zero peer-to-peer connections and zero peer IP exposure, hub-only mode turns P2P off entirely - not just "prefers not to use it." With it enabled, the engine never opens a QUIC endpoint, never starts mDNS, and never dials another peer; every file read or write goes over HTTPS to the hub. The entire network surface collapses to the four HTTPS/443 rows in the summary table above (control plane, identity, and - while the tray is active - installer/update checks). Nothing UDP is ever touched.

This is set per-machine (SWARMFILE_HUB_ONLY in config.json), or centrally for the whole org by an owner or admin - a central policy overrides whatever an individual machine has set locally. See Security for how this fits the broader threat model, and Operations for where the setting shows up in your audit log.

Verifying what a specific machine actually needs#

swarmfile doctor runs a battery of connectivity checks - DNS resolution, HTTPS reachability to the hub, an authenticated round-trip, a QUIC dial test (skipped cleanly when hub-only mode is on), and an mDNS listen test (same) - and reports pass/warn/fail for each, with a --json mode for pasting into a firewall-exception ticket. Run it from a machine on the network you're configuring rather than guessing; see swarmfile-doctor.

What's not covered here#

Self-hosted seed and NAS nodes participate in the same P2P swarm as any other machine - no additional inbound ports are required for them either. A seed node run as a headless cloud service (rather than on-prem hardware) can optionally expose a health-check HTTP endpoint for your own orchestration (Kubernetes, Fly.io, etc.) - that's an explicit opt-in for that specific deployment shape, not something a normal desktop or on-prem seed install does, and it's the one case where the engine listens on all interfaces rather than loopback-only. Talk to us if you're deploying that way and need the specifics.