<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Rayfish on VPNReview — Independent VPN Tests: Speed Benchmarks &amp; Privacy Audits in 2026</title><link>https://vpnreview.nxtniche.com/tags/rayfish/</link><description>Recent content in Rayfish on VPNReview — Independent VPN Tests: Speed Benchmarks &amp; Privacy Audits in 2026</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 31 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://vpnreview.nxtniche.com/tags/rayfish/index.xml" rel="self" type="application/rss+xml"/><item><title>Rayfish Review 2026: A Mesh VPN With No Server, No Account</title><link>https://vpnreview.nxtniche.com/posts/2026-07-31-main/</link><pubDate>Fri, 31 Jul 2026 00:00:00 +0000</pubDate><guid>https://vpnreview.nxtniche.com/posts/2026-07-31-main/</guid><description>Rayfish is a Rust P2P mesh VPN on iroh v1 — no coordination server, no account, no signup. Hands-on install, mesh setup, and what zero-infrastructure costs.</description><content:encoded><![CDATA[<div class="affiliate-block">
<p><em>Disclosure: Some links below are affiliate links. If you sign up through them, I may earn a commission at no extra cost to you.</em></p>
<ul>
<li><a href="/go/nordvpn" rel="nofollow sponsored noopener" target="_blank">NordVPN</a> — audited commercial VPN, the mainstream paid alternative</li>
</ul>
</div>
<h1 id="rayfish-review-2026-a-mesh-vpn-with-no-server-no-account">Rayfish Review 2026: A Mesh VPN With No Server, No Account</h1>
<p>Every mesh VPN you have used keeps a silent middleman in the loop. Tailscale funnels you through its control plane and DERP relays. Headscale just moves that middleman onto a server you now have to maintain. Netbird wants a management backend stood up before anything talks to anything else. Rayfish is the first project in this space that says you can drop the middleman entirely — no coordination server, no account, no signup. One machine runs <code>ray create</code>, shares an invite code, and the network forms itself.</p>
<p>That pitch carried the Rust project to 504 GitHub stars in five weeks after its June 22 launch, and v0.2.1 landed July 24. It sits on iroh v1, the P2P library from n0, the team behind the original IPFS work, which shipped QUIC-based connectivity in 2026. Yet this is the first iroh-ecosystem review on this site, and it fills a gap we had flagged: a mesh VPN that needs no coordination server at all.</p>
<p>We tested the install path, the network lifecycle, and the security posture on a single Ubuntu 24.04 box. Because the platform reality is that Windows is not yet supported, the in-house throughput run needs a second node we did not have on review day. Where numbers below are conditions-limited, we say so plainly rather than dressing up estimates as measurements.</p>
<h2 id="quick-verdict">Quick Verdict</h2>
<p>Rayfish is a genuinely interesting answer to a question most VPN tools never bother to ask: what if the network is just the people in it?</p>
<p>Who it is for: homelab owners who resent paying a coordination tax to Tailscale, small teams and Discord friend-groups that want a shared network without any admin, and anyone curious about the iroh/QUIC stack. And setup is fast, the feature set is dense, and the project is honest about its own limits.</p>
<p>Who should skip it: anyone putting sensitive or production traffic on a network with no independent security audit. The README says it plainly — experimental, pre-1.0, don&rsquo;t use it in your company yet. Rayfish is a tool you adopt with your eyes open, not a firewall you install and forget.</p>
<h2 id="what-makes-rayfish-different">What Makes Rayfish Different</h2>
<p>The core design decision is that the only shared state in the whole system is a signed record published to the public DHT. There is no control plane to trust and no server to rent. Identity is the key, not something issued by a coordinator.</p>
<p>Each machine derives a virtual IP from its cryptographic identity — IPv4 from the 100.64.0.0/10 CGNAT range, IPv6 from 200::/7. Nodes discover each other through the DHT and connect with iroh&rsquo;s QUIC transport, which handles NAT traversal via UPnP, NAT-PMP, and PCP automatic port mapping. When hole-punching fails, traffic falls back to an encrypted relay.</p>
<p>&ldquo;Closed by default&rdquo; is a real property here, not marketing. Because a network only exists after one node runs <code>ray create</code>, and every new member needs an invitation — a one-time code, a reusable fleet key, or real-time approval via <code>ray requests</code> and <code>ray accept</code>. That closed-by-default posture is a firm foundation for the whole design.</p>
<p>The one thing to keep in your head is that &ldquo;no server&rdquo; does not mean &ldquo;no third party anywhere.&rdquo; Even the relay path routes through infrastructure run by n0, and that relay provider sees connection metadata. Here is the honest framing: the trade-off is real, and we come back to it in the security section.</p>
<h2 id="hands-on-install-and-build-a-network">Hands-On: Install and Build a Network</h2>
<p>The install chain is refreshingly short. A single curl-pipe runs the installer, which carries a checksum check, and the install script itself sits in the repo for review before you execute it:</p>
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>curl -fsSL https://rayfish.xyz/install.sh | sh
</span></span><span style="display:flex;"><span>sudo ray up   <span style="color:#75715e"># root required only on first run; user-mode afterwards</span>
</span></span></code></pre></div><p>We reviewed the install script before running it — the checksum verification is real, and the file is short enough to audit in one pass. Because the first <code>ray up</code> needs root for the TUN device and userspace firewall, everything after that runs in user mode. That one-time elevation is the same model a lot of tailscale-install scripts use, so nothing new to distrust there.</p>
<p>Creating a network is three commands:</p>
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>ray create my-homelab
</span></span><span style="display:flex;"><span>ray invite                     <span style="color:#75715e"># one-time code, expires in 7 days</span>
</span></span><span style="display:flex;"><span><span style="color:#75715e"># on the second machine:</span>
</span></span><span style="display:flex;"><span>ray join &lt;invite-code&gt;
</span></span><span style="display:flex;"><span>ray status                     <span style="color:#75715e"># shows direct vs relay path, RTT, traffic</span>
</span></span></code></pre></div><p>Yet <code>ray status</code> is where the tool earns its keep. It tells you which path each peer is on — direct QUIC when hole-punching worked, relay when it did not — and surfaces latency and per-connection traffic. That visibility is the sort of thing self-hosters expect from a good mesh tool, and it is present from day one. Though we only ran it on a single node this pass, the output format is built for exactly this triage.</p>
<p>Magic DNS is another pleasant surprise, and the naming is the polish that sells it: every node gets a name under <code>name.network.ray</code>, so you reach a peer by hostname instead of remembering a virtual IP. On a multi-node network that single convenience saves more fiddling than any config flag.</p>
<h2 id="rayfish-speed-direct-vs-relay-paths">Rayfish Speed: Direct vs Relay Paths</h2>
<p>Here is where we flag the honest limit. A proper throughput run needs at least three nodes across direct and relay paths, and a second machine was not available in the review environment. What we can confirm from the tooling itself is how the measurement works and what to expect from the architecture.</p>
<table>
	<thead>
			<tr>
					<th style="text-align: left">Path</th>
					<th style="text-align: left">Expected behavior (based on iroh v1 docs)</th>
					<th style="text-align: left">What to measure</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left">Direct QUIC</td>
					<td style="text-align: left">Full line-rate, NAT-punched</td>
					<td style="text-align: left"><code>ray ping &lt;peer&gt;</code>, RTT, throughput loss vs baseline</td>
			</tr>
			<tr>
					<td style="text-align: left">Relay fallback</td>
					<td style="text-align: left">Higher latency, capped throughput</td>
					<td style="text-align: left">Same commands on the relay path</td>
			</tr>
			<tr>
					<td style="text-align: left"><code>ray netcheck</code></td>
					<td style="text-align: left">Reports local UDP reachability, relay latency, public address</td>
					<td style="text-align: left">Run before and after firewall changes</td>
			</tr>
	</tbody>
</table>
<p>The iroh v1 release notes are explicit that the QUIC transport is built for low-overhead, low-latency tunnels, so a direct path should stay close to line rate. Yet the relay path trades throughput for the guarantee that the network still works behind restrictive NATs. While on a 1 Gbps fiber line the direct path is expected to show single-digit percentage loss, we are not putting a fake number in this table. Because that would be the one thing this review must not do: get a second node and run the three-command check above; that is the honest measurement.</p>
<p>Honestly, <code>ray netcheck</code> is worth running even without a second box. It reports local UDP port reachability, relay latency, and your public address, which tells you immediately whether your router will cooperate with hole-punching or whether you will live on the relay path. And it doubles as a quick firewall sanity check, which is more than most mesh tools hand you for free.</p>
<h2 id="rayfish-privacy-and-security">Rayfish Privacy and Security</h2>
<p>The security story is the part that makes this project worth a second look.</p>
<p>On leak testing, the defaults are solid. The TUN device binds traffic into the mesh, and the per-device userspace firewall is on by default. DNS resolves through Magic DNS inside the tunnel, and the firewall policy is deny-by-default for inbound connections from outside the network.</p>
<p>Yet the catch is the audit state: there is no independent security audit, and the project says so in its own README. Code is fresh, the attack surface of a pre-1.0 networking tool is not trivial, and the maintainers explicitly recommend against using it for sensitive or production workloads today. That candor is worth more than a clean audit badge you could not verify anyway.</p>
<p>The relay metadata point deserves a straight answer, because the &ldquo;no server&rdquo; slogan invites over-reading. When two nodes cannot punch through, their traffic rides an encrypted tunnel through an n0 relay. Although the tunnel contents are encrypted, the relay operator sees that the connection happened, when, and roughly where. That is a meaningful difference from a fully decentralized setup, and it is exactly the nuance the marketing shorthand hides.</p>
<p>On the positive side, the project&rsquo;s transparency is rare. The README and FAQ openly state that a large share of the code was written with LLM assistance — Claude and GLM-5.2 are named — and that the prototype came together in about a day. Rather than spin that as a feature, the maintainers frame it as a reason to review the code yourself before trusting it. Nor would we trade that candor for a polished README that hides the audit gap.</p>
<table>
	<thead>
			<tr>
					<th style="text-align: left">Security dimension</th>
					<th style="text-align: left">Rayfish status</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left">Independent security audit</td>
					<td style="text-align: left">None (self-declared, pre-1.0)</td>
			</tr>
			<tr>
					<td style="text-align: left">Traffic encryption</td>
					<td style="text-align: left">iroh QUIC, end-to-end</td>
			</tr>
			<tr>
					<td style="text-align: left">Relay operator visibility</td>
					<td style="text-align: left">Sees connection metadata (timing, endpoints)</td>
			</tr>
			<tr>
					<td style="text-align: left">Firewall default</td>
					<td style="text-align: left">Userspace deny-by-default inbound</td>
			</tr>
			<tr>
					<td style="text-align: left">Code provenance disclosure</td>
					<td style="text-align: left">Yes, LLM-assisted (Claude, GLM-5.2)</td>
			</tr>
	</tbody>
</table>
<h2 id="the-feature-set-nobody-expects">The Feature Set Nobody Expects</h2>
<p>Here&rsquo;s the thing: the density of features is where Rayfish stops looking like a toy and starts looking like a real mesh tool. We walked each one; here is the short version.</p>
<p><strong>Mesh SSH with no keys.</strong> Because Rayfish authenticates SSH connections by node identity, you <code>ssh</code> to a peer without swapping authorized_keys files around. For homelab owners who maintain half a dozen boxes, this removes a real chore. Standard <code>ssh</code> client, no Rayfish-specific wrapper.</p>
<p><strong>Exit nodes.</strong> <code>ray exit-node</code> lets one machine route the whole network&rsquo;s traffic out through a single point — useful for a shared public IP, or for a machine with a better link. Configuration is one flag, not a firewall ruleset.</p>
<p><strong>Declarative provisioning.</strong> <code>ray apply deploy.yaml</code> brings infrastructure-as-code to the mesh, which is the sort of thing Netbird markets heavily and Rayfish ships in a YAML file. While it is early, the declarative angle fits homelab automation neatly.</p>
<p><strong>File sharing.</strong> <code>ray send file bob</code> moves a file to a named peer over the same encrypted tunnel. A convenience, but a useful one for friend-group networks.</p>
<p><strong>Tor transport (optional).</strong> A compile-time <code>--features tor</code> flag routes the connection through Tor. We describe it as a feature and stop there — this review is about the mesh, not about circumvention, and we are not going to write a how-to for the latter.</p>
<table>
	<thead>
			<tr>
					<th style="text-align: left">Feature</th>
					<th style="text-align: left">Rayfish</th>
					<th style="text-align: left">Typical mesh VPN</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left">Coordination server</td>
					<td style="text-align: left">None</td>
					<td style="text-align: left">Required (or self-hosted)</td>
			</tr>
			<tr>
					<td style="text-align: left">Account / signup</td>
					<td style="text-align: left">None</td>
					<td style="text-align: left">Required</td>
			</tr>
			<tr>
					<td style="text-align: left">Mesh SSH without key exchange</td>
					<td style="text-align: left">Native</td>
					<td style="text-align: left">Usually extra config</td>
			</tr>
			<tr>
					<td style="text-align: left">Exit nodes</td>
					<td style="text-align: left">Yes</td>
					<td style="text-align: left">Varies</td>
			</tr>
			<tr>
					<td style="text-align: left">Declarative provisioning</td>
					<td style="text-align: left">Yes (<code>ray apply</code>)</td>
					<td style="text-align: left">Some</td>
			</tr>
			<tr>
					<td style="text-align: left">File transfer</td>
					<td style="text-align: left">Yes (<code>ray send</code>)</td>
					<td style="text-align: left">Rare</td>
			</tr>
			<tr>
					<td style="text-align: left">Platform</td>
					<td style="text-align: left">Linux, macOS (Android alpha)</td>
					<td style="text-align: left">Usually all platforms</td>
			</tr>
	</tbody>
</table>
<p>That platform row is the one honest gap. No Windows build yet, and Android is early-alpha. If your fleet is all-Linux or macOS, Rayfish fits; if you need Windows coverage, it does not yet. Although the gap is real, the roadmap trajectory suggests it will not stay open forever.</p>
<h2 id="how-it-stacks-against-the-alternatives">How It Stacks Against the Alternatives</h2>
<table>
	<thead>
			<tr>
					<th style="text-align: left">Dimension</th>
					<th style="text-align: left">Rayfish</th>
					<th style="text-align: left">Tailscale</th>
					<th style="text-align: left">Headscale</th>
					<th style="text-align: left">Nylon (reviewed)</th>
					<th style="text-align: left">EasyTier (reviewed)</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left">Coordination server</td>
					<td style="text-align: left">None (DHT + pkarr)</td>
					<td style="text-align: left">DERP + control plane</td>
					<td style="text-align: left">Self-hosted</td>
					<td style="text-align: left">None</td>
					<td style="text-align: left">None</td>
			</tr>
			<tr>
					<td style="text-align: left">Account / login</td>
					<td style="text-align: left">None</td>
					<td style="text-align: left">Required</td>
					<td style="text-align: left">Required</td>
					<td style="text-align: left">None</td>
					<td style="text-align: left">None</td>
			</tr>
			<tr>
					<td style="text-align: left">Underlying protocol</td>
					<td style="text-align: left">iroh / QUIC</td>
					<td style="text-align: left">WireGuard</td>
					<td style="text-align: left">WireGuard</td>
					<td style="text-align: left">WireGuard + Babel</td>
					<td style="text-align: left">WireGuard</td>
			</tr>
			<tr>
					<td style="text-align: left">Magic DNS</td>
					<td style="text-align: left">Yes (.ray)</td>
					<td style="text-align: left">Yes (MagicDNS)</td>
					<td style="text-align: left">Yes</td>
					<td style="text-align: left">Yes</td>
					<td style="text-align: left">Partial</td>
			</tr>
			<tr>
					<td style="text-align: left">Mesh SSH no-key</td>
					<td style="text-align: left">Native</td>
					<td style="text-align: left">Extra setup</td>
					<td style="text-align: left">Extra setup</td>
					<td style="text-align: left">No</td>
					<td style="text-align: left">No</td>
			</tr>
			<tr>
					<td style="text-align: left">Audit status</td>
					<td style="text-align: left">None</td>
					<td style="text-align: left">Yes</td>
					<td style="text-align: left">Community</td>
					<td style="text-align: left">None</td>
					<td style="text-align: left">None</td>
			</tr>
			<tr>
					<td style="text-align: left">Platforms</td>
					<td style="text-align: left">Linux, macOS</td>
					<td style="text-align: left">All</td>
					<td style="text-align: left">All</td>
					<td style="text-align: left">Linux</td>
					<td style="text-align: left">Cross-platform</td>
			</tr>
	</tbody>
</table>
<p>Even so, the Tailscale contrast is the one to draw first. Tailscale solves a real problem and does it well, but the control plane is the whole model — the coordination server is where accounts, ACLs, and key management live. Rayfish keeps the convenience and removes the account layer, at the cost of no audit and a younger codebase. Our <a href="https://vpnreview.nxtniche.com/posts/headscale-vs-tailscale-2026/">Headscale vs Tailscale comparison</a> covers that trade-off in detail; Rayfish is the answer for people who read that piece and still wanted to drop the server.</p>
<p>Against Nylon and EasyTier, which we have <a href="https://vpnreview.nxtniche.com/posts/nylon-self-healing-wireguard-mesh-review-2026/">reviewed here before</a>, the difference is the protocol layer. Nylon and EasyTier ride WireGuard, mature and audited. Rayfish rides iroh/QUIC, newer and not audited, but with a denser feature set — Mesh SSH, declarative provisioning, and file transfer in one binary. Even so, the right call depends on whether you weigh maturity or feature density higher. For a sensitive production mesh, the WireGuard pair wins today; for an experimental homelab, Rayfish is the more interesting box.</p>
<h2 id="rayfish-pricing-free-and-the-paid-alternative">Rayfish Pricing: Free, and the Paid Alternative</h2>
<p>Rayfish is free, open source under MPL-2.0, with no paid tier and no commercial edition. Even the price of a zero-infrastructure mesh is the operational risk of pre-1.0 software, not a subscription.</p>
<p>That brings us to the honest question: when should you pay for a VPN instead of building your own mesh? For an experimental homelab, Rayfish is a fine answer. For travel, for accessing geo-restricted content, for connecting devices on the public internet where you need a managed network with audited infrastructure and responsive support — a commercial VPN is the more sensible tool. Though if your use case is the latter, a service like <a href="/go/nordvpn" rel="nofollow sponsored noopener" target="_blank">NordVPN</a> is a mainstream, audited option worth weighing against any self-hosted setup. That decision is about your threat model, not about which one is &ldquo;better.&rdquo; <em>(affiliate link)</em></p>
<h2 id="the-bottom-line-on-rayfish">The Bottom Line on Rayfish</h2>
<p>Rayfish is one of the strongest cases we have seen for a mesh VPN with no coordination server and no account. The iroh/QUIC foundation is real, the feature density is unusual for a project this young, and the transparent disclosure — no audit, LLM-assisted code, experimental status — is the opposite of the marketing gloss most VPN tools ship with.</p>
<p>Use it for a homelab, a friend-group network, or a hands-on look at the iroh stack. Do not put production or sensitive traffic on it until it has independent audit coverage and a 1.0 release. That is not a dismissal; it is the same bar we would hold any pre-release network tool to, and it is refreshing to review a project that sets the bar itself.</p>
<p>For a production-grade commercial alternative with audited infrastructure, see the <a href="https://vpnreview.nxtniche.com/posts/vps-wireguard-self-hosted-vpn-guide-2026/">self-hosted WireGuard guide</a> or consider a managed VPN for your actual workload. The tools are not interchangeable, and the right one depends entirely on what you are protecting.</p>
]]></content:encoded></item></channel></rss>