|
2 | 2 | title: "Relays" |
3 | 3 | --- |
4 | 4 |
|
5 | | -Relays are servers that temporarily route encrypted traffic until a direct, P2P connection is |
6 | | -feasible. Once this direct path is set up, the relay server steps back, and the |
7 | | -data flows directly between devices. This approach allows Iroh to maintain a |
8 | | -secure, low-latency connection, even in challenging network situations. |
| 5 | +Relays are servers that temporarily route encrypted traffic until a direct, P2P connection is feasible. Once this direct path is set up, the relay server steps back, and the data flows directly between devices. This approach allows Iroh to maintain a secure, low-latency connection, even in challenging network situations. |
| 6 | +There are situations where a direct connection can’t be established, and in those cases traffic falls back to running through the relay. Relay servers do not have access to the data being transmitted, as it’s encrypted end-to-end. |
9 | 7 |
|
10 | | -There are situations where a direct connection _can't_ be established, and in |
11 | | -those cases traffic falls back to running through the relay. Relay servers **do |
12 | | -not** have access to the data being transmitted, as it's encrypted end-to-end. |
| 8 | +Relays serve two roles in iroh: |
13 | 9 |
|
14 | | -We're working on formally collecting the direct connection rate from production |
15 | | -iroh networks. Anecdotal evidence points to roughly 9 out of 10 networking conditions we see in practice allowing a direct connection to be established. Our holepunching implementation is deterministic - if it works between two devices once, it should continue to work as long as their networking setup remains stable. |
| 10 | +1. **Holepunching assistance.** When two endpoints first connect, they exchange network information through the relay to attempt a direct P2P connection. |
| 11 | +2. **Encrypted traffic fallback.** If a direct connection can't be established (due to strict NATs, firewalls, or other network conditions), traffic flows through the relay instead. |
16 | 12 |
|
17 | | -## Public relays |
| 13 | +Once a direct path is established, the relay steps back and data flows peer-to-peer. Relay servers **cannot read** any of the traffic they handle — it's encrypted end-to-end. |
18 | 14 |
|
19 | | -iroh is configured with a set of public relays provided by [n0.computer](https://n0.computer) that are free to use. The public relays rate-limit |
20 | | -traffic that flows through the relay. This is to prevent abuse, and ensure the |
21 | | -relays are available to everyone. There are no guarantees around uptime or |
22 | | -performance when using the public relays. |
| 15 | +In practice, roughly 9 out of 10 networking conditions allow a direct connection. iroh's holepunching implementation is deterministic: if it works between two devices once, it will continue to work as long as their networking setup stays stable. |
23 | 16 |
|
24 | | -We recommend using the public relays for development and testing, as they are |
25 | | -free to use and require no setup. However, for production systems, we recommend |
26 | | -using dedicated relays instead. |
| 17 | +## Deploy your own relay |
| 18 | + |
| 19 | +<Card |
| 20 | + title="Deploy a dedicated relay" |
| 21 | + icon="server" |
| 22 | + href="https://services.iroh.computer?utm_source=docs&utm_content=concepts-relays" |
| 23 | +> |
| 24 | + Sign up for Iroh Services and spin up a managed relay for your project in minutes. |
| 25 | +</Card> |
27 | 26 |
|
28 | | -## Dedicated relays |
29 | 27 |
|
30 | | -For production use, we recommend using dedicated relays. Dedicated relays are relay |
31 | | -servers that are either self-hosted or provided as a managed service. Dedicated |
32 | | -relays provide better performance, security, and uptime guarantees compared to |
33 | | -the public relays. |
| 28 | +## Why relays are better |
34 | 29 |
|
35 | | -## Why this architecture is powerful |
| 30 | +Unlike traditional servers, relay servers are **stateless**. They don't store your application data — they just facilitate connections. |
36 | 31 |
|
37 | | -This approach makes uptime management significantly easier compared to |
38 | | -traditional client-server architectures: |
| 32 | +- **No database synchronization.** Nothing to replicate across relay instances. |
| 33 | +- **No state migration.** When a relay goes down, clients reconnect to another with no data loss. |
| 34 | +- **Simple scaling.** Spin relay instances up or down like any lightweight service. |
| 35 | +- **Automatic failover.** Iroh can attempt to connect to multiple relays automatically; as long as one is reachable, your peers find each other. |
39 | 36 |
|
40 | | -**Stateless servers, stateful clients** |
41 | | -Unlike traditional servers that store your application's data and state, relay |
42 | | -servers are just connection facilitators. All your business logic and data lives |
43 | | -in your clients. This means: |
| 37 | +This inverts the traditional model: relays are disposable connection facilitators, while your clients own all the application state and logic. |
44 | 38 |
|
45 | | -- **No database synchronization** - You don't need to worry about keeping multiple server databases in sync or handling data replication |
46 | | -- **No state migration** - When a relay goes down, clients simply reconnect to another relay without any data loss or state transfer |
47 | | -- **Simple server management** - Relay servers are lightweight and easy to spin up or down. No complex deployment procedures or data migration steps |
| 39 | +## Public relays |
48 | 40 |
|
49 | | -**Automatic failover** |
50 | | -iroh clients automatically try multiple relays when connecting. If one relay is unavailable, clients seamlessly fall back to another relay in your list without application-level retry logic. Your peers will find each other as long as at least one relay is reachable. |
| 41 | +Iroh hardcodes a set of public relays provided by |
| 42 | +[n0.computer](https://n0.computer), free to use. |
51 | 43 |
|
52 | | -**Multi-cloud resilience** |
53 | | -For even better guarantees, you can distribute relays across multiple cloud providers. If one provider experiences an outage, your application keeps running on relays hosted elsewhere. Since relays don't store state, you can freely mix providers without worrying about cross-cloud data consistency. |
| 44 | +Public relays: |
54 | 45 |
|
55 | | -**Cost-effective scaling** |
56 | | -Adding capacity means spinning up more lightweight relay instances, not provisioning databases or managing complex stateful server infrastructure. You can easily scale up for peak usage and scale down during quiet periods. |
| 46 | +- Rate-limit traffic to prevent abuse |
| 47 | +- Carry no uptime or performance guarantees |
| 48 | +- Are shared across all iroh developers worldwide |
57 | 49 |
|
58 | | -This architecture inverts the traditional model: instead of treating servers as precious stateful resources and clients as disposable, relay-based architectures treat relays as disposable connection facilitators while clients own the application state and logic. |
| 50 | +**Public relays are suitable for development and testing.** For production, use dedicated relays. |
59 | 51 |
|
60 | | -## Connection Changes |
| 52 | +## Dedicated relays |
61 | 53 |
|
62 | | -During the lifespan of a connection, networking conditions can change, for |
63 | | -example when a user switched from 5G to WiFi, plugs in an ethernet cable, or a |
64 | | -sysadmin modifies router configurations. The connection may change from direct |
65 | | -to relayed, or even a mixed combination of the two. Iroh will automatically |
66 | | -switch between direct and relayed connections as needed, without any action |
67 | | -required from the application. |
| 54 | +Dedicated relays are relay servers provisioned exclusively for your project — either managed through Iroh Services or self-hosted. |
68 | 55 |
|
69 | | -## Read more |
| 56 | +They offer: |
| 57 | + |
| 58 | +- **Isolation** — no noisy neighbors; your traffic is yours alone |
| 59 | +- **Uptime guarantees** — SLAs available via [Iroh Services](/iroh-services/relays) |
| 60 | +- **Version locking** — stay on a specific iroh version or run blue/green deployments |
| 61 | +- **Multi-region & multi-cloud** — deploy relays across regions and providers for resilience |
| 62 | + |
| 63 | +## Deploy your own relay |
| 64 | + |
| 65 | +<Card |
| 66 | + title="Deploy a dedicated relay" |
| 67 | + icon="server" |
| 68 | + href="https://services.iroh.computer?utm_source=docs&utm_content=concepts-relays" |
| 69 | +> |
| 70 | + Sign up for Iroh Services and spin up a managed relay for your project in minutes. |
| 71 | +</Card> |
| 72 | + |
| 73 | +Or self-host using the open-source relay binary: |
70 | 74 |
|
71 | | -- [Dedicated infrastructure guide](/deployment/dedicated-infrastructure) |
72 | 75 | - [Relay source code](https://github.com/n0-computer/iroh/tree/main/iroh-relay) |
73 | 76 | - [Relay binary releases](https://github.com/n0-computer/iroh/releases) |
74 | | -- [Managed relay service](/iroh-services/relays) |
| 77 | +- [Dedicated infrastructure guide](/deployment/dedicated-infrastructure) |
75 | 78 |
|
0 commit comments