Use Shared Relays
Use authenticated, multi-tenant relays for the standard Pro production setup.
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 your own relays
To use a specific set of relays with your iroh endpoint, configure your relay URLs as part of an iroh-services preset:Recommended setup
Place relays as close as possible to the users they serve. Shorter network paths reduce latency and improve response times, including time to first byte when a connection uses a relay. For a globally distributed user base, prioritize regions near your largest user populations. For redundancy, run at least two relays in different regions. This placement should complement proximity: choose regions that keep relays near users while avoiding a single regional point of failure.Why this architecture is powerful
This approach makes uptime management significantly easier compared to traditional client-server architectures: Stateless servers, stateful clientsUnlike 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
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
Enterprise plans 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 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.