Skip to main content
By default, iroh will use public shared infrastructure to facilitate connections over address lookup and end-to-end encryption over relays. This infrastructure comprises:
  1. Relays
  2. Address Lookup
Relays forward traffic when direct connections are not possible as well as facilitates NAT traversal for direct connections. These servers are managed and maintained by n0.computer, 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.

Deploy a dedicated relay

Sign up for Iroh Services and spin up a managed relay for your project in minutes.

Self-host a relay

Learn how to self-host a relay for your project.

​
Using dedicated relays

To use dedicated relays with your iroh endpoint, configure it with your relay URLs: 
use iroh::Endpoint;
use iroh::relay::RelayUrl;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let relay_url1: RelayUrl = "YOUR_RELAY_URL_US".parse()?;
    let relay_url2: RelayUrl = "YOUR_RELAY_URL_EU".parse()?;

    let endpoint = Endpoint::builder()
        .relay_mode(iroh::endpoint::RelayMode::Custom(vec![relay_url1, relay_url2]))
        .bind()
        .await?;

    Ok(())
}
For full deployment steps, see the managed relay guide.

​
Why use dedicated relays in production?

Using 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. 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.