Skip to main content
By default, iroh will use public shared infrastructure to facilitate connections over DNS and end-to-end encryption over relays. This infrastructure comprises:
  1. Relays
  2. Discovery Servers (DNS)
Relays forward traffic when direct peer-to-peer connections are not possible as well as facilitates holepunching for direct connections. These servers are managed and maintained by the n0 team, and are shared by a global public network of developers. We recommend using the public relays for development and testing, as they are free to use and require no setup. However, for production systems, we recommend using dedicated relays instead.

​
Why use dedicated relays in production?

Using a dedicated relays can provide several benefits, including improved performance, enhanced security, better uptime guarantees, and greater control over your network infrastructure. By using your own servers, you can optimize connection speeds and reduce latency for your specific use case. If you require more control over your relay infrastructure, you can choose to self-host your own relay or upgrade to a managed relay service. This managed relay service is monitored by the n0 team who maintain the iroh project, and offers SLAs around uptime and performance. Sign up for a free trial of n0des to get access to purchase a managed relay with uptime SLAs. We recommend setting up at least two relays for redundancy in different regions. For example, you could set up one relay in North America and another in Europe.

​
Why this architecture is powerful

This approach makes uptime management significantly easier compared to traditional client-server architectures: Stateless servers, stateful clients
Unlike traditional servers that store your application’s data and state, relay servers are just connection facilitators. All your business logic and data lives in your clients. This means:
  • No database synchronization - You don’t need to worry about keeping multiple server databases in sync or handling data replication
  • No state migration - When a relay goes down, clients simply reconnect to another relay without any data loss or state transfer
  • Simple server management - Relay servers are lightweight and easy to spin up or down. No complex deployment procedures or data migration steps
Automatic failover
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. Multi-cloud resilience
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. Cost-effective scaling
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. 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.

​
Using dedicated relays

To use dedicated relays with your iroh endpoint, you need to configure the endpoint to use your relay’s URL. For detailed information on configuring custom relays, including code examples and API documentation, see the iroh relay configuration guide.