Does iroh use relay servers?
Yes — and relay servers are a core part of what makes iroh connections reliable. See the Relays concept page for a full overview. Relays serve two roles: they assist with NAT Traversal to help establish direct P2P connections, and they act as an encrypted fallback when a direct connection can’t be made. In practice, roughly 9 out of 10 connections go direct — the relay is only a stepping stone. Because relays are stateless (they route encrypted packets but store nothing), they’re cheap to run and easy to scale. There’s no database to sync, no state to migrate, and automatic failover across relay instances is built in. By default iroh is configured with four public relay servers run by number 0 — two in the US, one in Europe, and one in Asia — free to use for development and testing. To prevent abuse, throughput through public relays is rate-limited. For production workloads, you can run a dedicated relay or self-host your own.Can relays read the traffic they route?
No, all connections in iroh are end-to-end encrypted. We use QUIC which is based on TLS 1.3. From the perspective of our QUIC implementation, the relay is “just another UDP socket” for sending encrypted packets around. Because the relays are relaying traffic, they theoretically know that Endpoint ID X talks to Endpoint ID Y and how many bytes are sent this way, but only for as long as these endpoints haven’t established a direct connection yet. However, we don’t record this data on our relays.How secure is iroh’s end-to-end encryption?
Iroh provides a secure, encrypted, forward and backward-secret, authenticated data channel between you and the recipient and protects you both from eavesdroppers. This assumes the Endpoint ID you’re connecting to was exchanged securely, e.g. via scanning a QR code, sharing a link with the Endpoint ID in an encrypted chat app or using a trusted server and the corresponding secret keys haven’t been compromised. The established connection is a QUIC connection, which together with TLS 1.3 specifies how it’s encrypted. This specification is widely used, for example as part of the latest generation of HTTP, HTTP3. Instead of PKI-based certificates, at the moment iroh uses self-signed certificates with Endpoint IDs to authenticate both ends of the connection, borrowing the libp2p handshake specification. In the future, we plan on switching to the raw public key TLS certificate type instead. To make use of this end-to-end encryption, no additional setup in iroh is required, it is always enabled. Be aware of security caveats to forward secrecy when using the opt-in 0-RTT feature.What if number 0 stops running relay servers?
You’re not dependent on us. The relay code is open-source, and running your own is possible. The easiest path is a dedicated relay via Iroh Services, which gives you an isolated, managed relay with uptime guarantees. If you’d rather self-host, you need a server with a public IP and a DNS name pointing to it — automatic TLS via ACME is built in. Either way, configure the relay URL for your endpoint (see Custom Relays) and you’re set. Running your own relay doesn’t affect interoperability. Your endpoints can still connect to peers using other relay servers, and since relays are stateless and logic lives at the client, can be swapped independently.Is establishing a connection without relays or when offline possible?
Yes. When you share aEndpointAddrs with “direct addresses”, then iroh will try to use these addresses to establish a connection with or without a relay.
If you’re in a local network together you can enable local network discovery to help establish connections in LANs even when the EndpointAddr doesn’t contain direct addresses.
How can I control which relay servers iroh connects to?
Iroh will only talk to relay servers that it knows URLs for. By default iroh is configured with 3 relay servers from the defaultRelayMap.
If you do not disable the default discovery services or other discovery services, then iroh might connect to relay servers discovered that way.
By changing iroh’s relay mode or relay map you can control the home relay the endpoint connects to, and by wrapping or writing your own Discovery service, you gain control over the relay URLs iroh can discover.
How can I monitor endpoint connection status to update a UI?
If you want a proxy for general internet connectivity, you can watch whether the endpoint currently has a relay connection:impl Watchable<Value = bool> that reflects whether the endpoint believes it’s connected to a relay — a reasonable signal for “has outside connectivity”.
How do you limit which nodes can join?
Iroh gives you full control over which endpoints are allowed to connect via endpoint hooks. Hooks let you intercept incoming connections before they’re accepted, so you can allow or reject them based on the connecting endpoint’s ID, your own allowlist/denylist logic, or any application-specific policy.What is “Discovery” in iroh and which one should I enable?
For most usage, using the services that are enabled by default in theiroh::Endpoint::builder is the best default.
Discovery helps iroh find ways to connect to a specific Endpoint ID.
The Endpoint ID on its own can only be used to identify if you’re talking to the right recipient, but doesn’t tell how to address the recipient on its own.
Via configured discovery mechanisms, iroh resolves an Endpoint ID to IP addresses and relay URLs that help to actually attempt a connection.
For more information on available discovery mechanisms, take a look at the discovery module.
It’s also possible to combine multiple discovery mechanisms at once, or write your own.
We think it’s particularly helpful to write application-specific discovery mechanisms that are tailored to an application’s need.
What ports does iroh use?
Iroh listens on Two UDP ports — one for IPv4 and one for IPv6, used for direct P2P connections; configurable viaendpoint::Builder
Iroh will work behind firewalls that only allow TCP outbound, but direct connections won’t be possible in that case — all traffic will fall back to the relay.
It’s totally possible that you maintain connections to multiple relays at a time, if you’re connected to iroh endpoints that have another home relay than yours. Each of these connections will use another TCP socket.
How would onion-routing work with iroh?
Iroh supports custom transports, which means you can route connections over Tor. Check out our blog post on using iroh with Tor for a walkthrough of how this works in practice.How is iroh development funded?
The company behind iroh is number 0. It is partly venture capital and partly founder backed (as in: founders have invested their own money). Number 0 is healthy and has investors we actually think are a value-add. We earn revenue through Iroh Services, which provides managed relay and DNS discovery infrastructure to keep your endpoints connected — from free public infrastructure for development and testing, to dedicated cloud deployments for production. We rely on iroh remaining open source, and are committed to keeping it that way, including server-side code for relays and DNS discovery.How does iroh compare to WebRTC?
Both iroh and WebRTC solve the same core problem — establishing direct P2P connections across NATs — but they make very different tradeoffs. WebRTC was designed for real-time media (audio and video) in browsers. It brings a complex stack: ICE for NAT traversal, STUN/TURN for relay, DTLS for encryption, SCTP for data channels, and a signaling layer that you have to implement yourself (WebRTC deliberately leaves signaling unspecified). This flexibility is powerful but adds significant complexity and is more expensive to run at scale. Iroh is built around QUIC (TLS 1.3) and focuses on reliable, encrypted data connections. The API is simpler: you connect to an endpoint ID and get a QUIC connection. Relays are stateless and cheap. Hole-punching works roughly 9 out of 10 times. There’s no signaling layer to design — discovery mechanisms handle address resolution.- Browser support. Both WebRTC and iroh work in browsers. Get started with iroh in the browser. However, WebRTC remains the only choice for hole-punched connections due to the current state of Web APIs.
- Media streaming. WebRTC has first-class support for audio and video. Iroh is a general-purpose data transport, but you can run MoQ (Media over QUIC) on top of iroh for low-latency media streaming.
- Simplicity. Iroh’s connection model is significantly simpler to reason about and integrate. No SDP, no ICE candidate negotiation, no signaling server to build.
How does iroh compare to MQTT?
MQTT and iroh solve different problems, though they can overlap in IoT and device communication scenarios. MQTT is a publish/subscribe messaging protocol built around a central broker. Devices connect to the broker, publish messages to topics, and subscribe to topics they care about. It’s lightweight, well-suited to constrained hardware, and great for fan-out messaging (one message to many subscribers). The tradeoff is that the broker sits in the middle of all communication — it sees everything, and it’s a single point of failure and scaling pressure. Iroh is a P2P transport. There’s no broker — endpoints connect directly to each other, and all traffic is end-to-end encrypted. This means no central party can observe your data, and there’s no broker to scale or maintain. The main practical differences:- Pub/sub. MQTT has native topic-based pub/sub built in. Iroh doesn’t, though iroh-gossip provides gossip-based fan-out on top of iroh connections.
- Privacy. MQTT brokers require you to encrypt messages at the application level. Iroh connections are always end-to-end encrypted out of the box.
- Central infrastructure. MQTT requires a broker that all clients can reach. Iroh works across NATs without any central server, using relays only as a fallback.
- Constrained devices. MQTT was designed for low-power, low-bandwidth hardware. Iroh’s QUIC-based stack has higher resource requirements, but we do have solutions for constrained IoT environments — get in touch if this is relevant to your use case.
How do iroh and libp2p compare?
Iroh is designed to be modular: you get a solid, reliable connection layer and compose protocols on top of it. Libp2p bundles more functionality — DHT, pubsub, transport negotiation — but those components are more tightly coupled, which makes the system harder to configure and reason about. The iroh project was founded by developers deeply involved with libp2p who wanted a library where you spend time on your protocol, not on networking configuration. Where iroh tends to win:- Peer discovery and NAT traversal. Iroh’s NAT traversal and discovery story is significantly smoother. Getting peers to find each other reliably is one of the hardest parts of libp2p in practice; iroh has largely solved this.
- Direct messaging. Iroh gives you reliable, encrypted QUIC connections directly to specific peers — straightforward to build routing or direct message delivery on top of.
- Gossip. iroh-gossip provides gossipsub-like fan-out on top of iroh connections.
- Blob transfer. Iroh has a built-in blob transfer protocol for exchanging hash-addressed data, similar to what you’d use IPFS for.
- DHT. Libp2p has a Kademlia-based DHT; iroh does not. If your design depends on DHT-based routing or content discovery, that’s a gap.
Do you support keys other than Ed25519?
No. Iroh endpoint IDs are Ed25519 keys, and that’s intentional. Ed25519 is deeply integrated across the stack: it’s used to signEndpointAddrs for Pkarr and other address lookups, as the raw public key trust root in mTLS, and for authentication in the relay protocol. Supporting pluggable key types would require threading that complexity through all of these systems simultaneously, with significant risk and little practical benefit for most use cases.
If you have a specific need around key types, open an issue and we’re happy to discuss it.