Rayfish Mesh VPN With No Control Plane

Private connectivity usually grows a control plane. Teams add accounts, relay regions, DNS, ACLs, and ownership for the service that makes the mesh work. Rayfish takes a different path: it builds a peer-to-peer mesh VPN powered by iroh, with no control server to host or trust.

The project is new and clearly marked experimental, so this is not a drop-in production recommendation. It is worth watching because it packages several ideas SRE teams care about: identity-based addressing, NAT traversal, Magic DNS, per-device firewalls, and declarative provisioning.

What Is Rayfish?

Rayfish is a Rust mesh VPN with a ray CLI and a local daemon. The daemon owns the TUN device and iroh endpoint, while normal commands talk to it over a local socket. Users create a private network, invite peers, and reach them by names like alice.gaming.ray.

Unlike classic VPN setups, Rayfish does not ask you to manage static IPs, peer configs, or a central certificate authority. Each machine has a cryptographic identity, derives stable virtual addresses from that identity, and connects directly to other peers when possible.

Key Features

• No hosted control plane: Peers discover the network through a DHT, and the coordinator can be offline after members are admitted.
• NAT traversal through iroh: Hole punching, QUIC transport, automatic port mapping, encrypted relay fallback, and a fixed UDP port option help peers connect across real networks.
• Magic DNS: Operators can use name.network.ray instead of memorizing virtual addresses.
• Closed by default: Networks admit peers through one-time invite codes, reusable fleet keys, or live approval.
• Layered local firewall: Rayfish adds a userspace firewall for mesh traffic on top of the host firewall, with per-port and per-peer rules.

Installation

The upstream quick start builds Rayfish from source and starts the daemon:

cargo build
sudo ray up

After setup, day-to-day commands can run without sudo for the configured operator.

Usage Pattern

A minimal private network looks like this:

ray create --hostname alice
ray invite gentle-amber-fox
ray join <invite-code> --name lab --hostname bob
ray status
ping alice.lab.ray
ray ping alice
ray netcheck

ray ping reports latency, packet loss, and whether the path is direct or relayed. ray netcheck shows the local UDP port, relay latency, public addresses, and reachability state.

Operational Tips

Treat Rayfish as lab software until it matures. The README says it is pre-1.0, unaudited, and may change wire formats or local config. That matters for incident access, compliance boundaries, and fleet automation.

Start with disposable networks. Test firewall rules, invite revocation, relay behavior, and ray report before putting anything sensitive behind it.

Also compare it honestly with the tools you already run. Rayfish is interesting when avoiding a coordination server is the point. If your team needs mature policy management, enterprise identity, or audited remote access today, keep it in the evaluation lane.

Conclusion

Rayfish is a useful signal for SRE teams watching private networking. It shows how far peer discovery, NAT traversal, and identity-based addressing can go without a conventional control plane. For lab meshes and research environments, it is worth a careful test.

At Akmatori, we build AI agents for SRE teams that help investigate alerts, inspect infrastructure, and automate operational workflows. If you need a resilient cloud and edge foundation for private infrastructure, explore Gcore for production-ready global infrastructure.