Short answer: iroh 1.0.0 is the 1.0 stable of the iroh peer-to-peer stack, and the release is built around one idea: you dial peers by their public key, not by an IP address. The release also includes bearer-token relay access control, custom TLS root configuration for relays, multi-hostname Let's Encrypt on relays, configurable NetReport, and happy-eyeballs concurrent IPv4/IPv6 relay connection. For an operator, the headline is that addressability is now key-based, which changes how you reason about reachability, and the relay path gained first-class access control.
Identity is the key, not the address
The defining change in iroh 1.0.0 is the shift to key-based dialing. A peer is a public key, and the stack resolves that key to a reachable endpoint using whatever path works: a direct connection, a relay, or a hole-punched path. This is not a cosmetic change; it is the foundation of the design. It means a peer keeps the same identity across network changes, reboots, and address changes, and it means an operator configures a topology in terms of identities rather than a list of IPs that drift.
The trade is that reachability becomes a property of the stack's resolution rather than something you pin. If a key is resolvable, the stack finds a path; if it is not, the connection fails for a reason that is about resolution and connectivity, not about a wrong IP in a config file. Debugging follows that model: you check whether the key resolves and what paths are available, not whether an address is correct.
The relay path got real access control
One of the most operationally significant additions in 1.0.0 is bearer-token access control in iroh-relay, implemented without an external authorization service. A relay can require a bearer token to accept connections, and it validates its own TLS configuration through a configurable server certificate verifier. This is the difference between a relay that anyone can use and one that an operator has explicitly gated.
For an operator running a relay in a topology with multiple parties, this is the mechanism that turns the relay from a public convenience into a controlled one. The token is the access boundary, and the custom TLS verifier means the relay's trust in its own certificate chain is something you set, not something inherited from a default.
Multi-hostname TLS and NetReport
1.0.0 also lets a relay serve multiple hostnames under Let's Encrypt, which matters when a relay is fronted by a domain with several names. And it adds configurable NetReport, the stack's own assessment of a host's connectivity: whether it can reach peers directly or must go through a relay, and the quality of those paths. Configuring NetReport means an operator can adjust how the stack judges its own network, which is useful in environments where the default probes give a misleading picture.
The happy-eyeballs change is small but real: relay connections now try IPv4 and IPv6 concurrently rather than sequentially, which reduces connection latency on dual-stack networks. It is the kind of improvement that does not change your config but makes the relay path faster where the network supports it.
Breaking changes to understand
As a 1.0 release, iroh carries some breaking changes that an operator upgrading from a pre-1.0 build must account for. The relay dependency updates and the custom-transport export changes are the ones most likely to surface in a build. The release is stable, which is the point, but stable does not mean no migration work: an operator on a pre-release build should read the breaking-change notes and test a representative connection before treating the 1.0 build as a drop-in replacement.
The 1.0 milestone is the right place to pin. Earlier builds are pre-stable and carry no stability promise; 1.0 is where the API and the behavior are intended to hold. If you are running iroh in a long-lived topology, 1.0.0 is the version to standardize on and test against.
What the release does not prove
The release record describes the capabilities of the stack; it does not describe your topology. Key-based dialing only works if your peers' keys are resolvable in your environment, relay access control only matters if you run a relay, and NetReport is only useful if you tune it to your network. Each of these is a capability to adopt deliberately. The stable release is the foundation; the operator's job is to wire the topology, set the relay policy, and verify the paths actually form in the deployment.
Limitations
- A release note is not a deployment audit. It does not inspect your operating system, network policy, credentials, storage, backups, or administrative process.
- Version numbers and documentation change. Pin the exact artifacts you test, record the date, and re-check upstream material before a production change.
- A feature that exists in a package or command does not automatically fit your threat model. Authentication, authorization, logging, patching, recovery, and abuse controls remain operator responsibilities.
- This article contains no benchmark, uptime promise, adoption statistic, cost saving, or client result. Measure those claims in your environment; the release record can only describe what shipped.
Related infrastructure context
For the physical layer around a systems deployment, TismTek provides fiber and network infrastructure work near Aurora. The team also documents on-premises compute and private AI systems. For a site discussion, call (720) 694-1976. See the iroh peer-to-peer networking explained for recovery planning and the private AI systems overview for the broader on-premises context.
Sources
- iroh v1.0.0 release notes — consulted September 15, 2026.
- iroh v1.0.0-rc.1 prior release candidate — consulted September 15, 2026.
- iroh project blog and documentation — consulted September 15, 2026.