GoKawiilWhen two devices can't get a direct connection, a relay carries the connection so data still flows. If the relay accepts anyone, then anyone who learns its URL can push traffic through it. And they will learn it: it ships inside every client you distribute and it's visible to anyone watching a connection get established.
Because of this, we've decided that managed relays on Iroh Services are now authenticated by default. Only endpoints carrying a token issued by your project's API key can use them.
There's nothing to switch on. If you already connect through the iroh_services preset, your endpoints authenticate themselves.
One caveat: this is the default for relays deployed from June 2026 onward. If you deployed a relay before then, it stays open, so nothing breaks for the endpoints already using it. To turn it on, head to your relay's authentication settings under Relays > Settings.
Someone finds your relay URL in a public repo, a client bundle, or a screenshot, and starts spamming your infrastructure until it falls over.
You spent effort spinning up your own relay, but someone else's traffic still competes with yours. A relay has finite bandwidth and finite connection slots, whether it's a box you're renting, a VM under your desk, or capacity you're paying us for, and whoever else found the URL is now using it.
If you run your own relays, you can build your own authentication scheme -- iroh is unopinionated about that. But if you're using our managed relays, until this month we didn't give you a way to easily control access. Now we have shipped the first piece of the authentication puzzle -- API keys. You can issue, rotate, and delete them without limits. These are the same API keys you already use to push metrics, so if you're on Iroh Services you have one.
Deploy a dedicated relay, free for 30 days.
Every relay connection starts with an HTTP handshake, the same one that upgrades to the websocket. Authentication travels in a standard header:
Authorization: Bearer Copy Copied!
... continue reading