Skip to main content
By default, iroh endpoints use the public relays maintained by n0.computer to facilitate connections when direct peer-to-peer links aren’t possible. The public relays are great for development and testing, but production deployments should run their own.

​
Configure your endpoint

Once you have one or more relay URLs, configure your endpoint to use them: Your dedicated relays require authentication by default. Your endpoint authenticates to them with your project’s API key. The iroh_services::preset() builder handles this for you: it mints a short-lived access token scoped to your endpoint’s key and configures the endpoint to use your relays. Add the iroh-services crate to your project: 
cargo add iroh-services
Then build a preset and bind your endpoint with it: 
use iroh::Endpoint;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    // Build a preset pointing at your dedicated relays, authenticated with
    // your project's API key. In production, load the key from a config file
    // or environment variable instead of hardcoding it.
    let preset = iroh_services::preset()
        .relays([
            "YOUR_RELAY_URL_US",
            "YOUR_RELAY_URL_EU",
        ])?
        .api_secret_from_str("YOUR_API_KEY")?
        .build()?;

    // Bind the endpoint with the preset, then wait until it's online to
    // confirm it has an authorized connection to a relay.
    let endpoint = Endpoint::bind(preset).await?;
    endpoint.online().await;

    Ok(())
}
Custom relay URLs are available on Pro and Enterprise projects. On a free project, pass your API key to the preset without relays(...) to authenticate against the public relays and surface your relay traffic on the dashboard.
Relays you self-host outside of Iroh Services are configured directly with RelayMode::Custom; see Dedicated Infrastructure.

​
Why use your own relay?

Running dedicated relays gives you:
  • Isolation: your traffic isn’t mixed with other applications
  • Performance: relays close to your users reduce latency and improve NAT traversal success
  • Capacity: the shared public infrastructure is rate-limited
  • Redundancy: distribute relays across regions or cloud providers for failover
  • Compliance: keep relayed traffic inside your own network or jurisdiction
Iroh’s relay architecture is uniquely suited to multi-relay deployments because relays are stateless. Clients automatically fail over between relays in your list, so adding capacity or surviving an outage is just a matter of running more relay processes. See Dedicated Infrastructure for the deeper architecture story.

​
Get a relay

You have two paths. Pick managed if you want a relay running today. But you’re never locked in! You can always self-host later if you want.

Deploy a managed relay

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

Self-host a relay

Run the iroh-relay binary on a server with a public IP and DNS name. Automatic TLS via ACME is built in.
For production, run at least two relays in different geographic regions, for example one in North America and one in Europe. iroh clients try multiple relays automatically, so if one becomes unreachable they’ll seamlessly fall back to another. Each relay handles up to 60,000 concurrent connections. For larger deployments, run multiple relays per region or contact us to size up.

​
Learn more

For the full architecture story (why stateless relays make uptime management easier, how multi-cloud resilience works, and managed relay deployment steps) see Dedicated Infrastructure.