nylon is a WireGuard mesh that reroutes around a failed link by itself

Routing without a control plane

Nylon is a self-healing WireGuard mesh that routes around failures. If a link goes down, nylon reroutes traffic through the next-best path in seconds. No manual intervention, no central coordination servers, just like how a real network should be.

The design decision that everything else follows from is the second half of that sentence. Most overlay networks have a control plane: a server that hands out keys, tells nodes about each other and keeps the map of the network. Tailscale has one, Nebula has one, ZeroTier has one, and that server becomes a dependency, a cost and a piece of your threat model.

nylon has none. Nodes exchange routes directly over the same WireGuard tunnel that carries your data.

That single design choice produces the properties the documentation lists. There is no SaaS dependency and no single control plane. And there is multi-hop routing: unlike Tailscale, Nebula or ZeroTier, nodes do not need to be directly reachable from each other, and nylon forwards through intermediate hops automatically.

That last point is the practical one. In the usual overlay networks, if two nodes cannot reach each other directly the path is broken. In nylon, the traffic goes through whatever intermediate nodes exist, and the mesh keeps working as long as the graph is connected. For a network spread across sites with no public address on some of them, or with NAT in the way, that is the difference between working and not.

The convergence target is stated as under 10 seconds after a link failure, and there is an animated demo of it in the documentation.

The rest of the deployment story is deliberately minimal. One statically-linked binary, one UDP port, 57175, and one YAML config. That is the whole footprint.

The project is Go, Apache-2.0 licensed, with the default branch main, releases v0.4.6 from 2026-08-27, v0.4.5 from 2026-07-28 and v0.4.4 from 2026-07-07, and the last push on 2026-09-30. The documentation lives at nylon.jq.ax.

Babel over WireGuard, with latency as the metric

The implementation choice is stated in one sentence and it explains the whole behaviour. Under the hood, nylon implements the Babel routing protocol, RFC 8966, on top of a modified wireguard-go, using measured latency as the routing metric.

Babel is a distance-vector routing protocol designed for networks where nodes cannot all reach each other and where links come and go. The properties that matter for a mesh are the ones nylon needs: it copes with partial connectivity, it converges quickly, and it needs no central authority to tell peers what the topology looks like. Each node learns the topology from its neighbours and gossips what it learns onward.

Using measured latency as the metric rather than hop count is what makes the paths sensible. A mesh spread across sites has paths of very different lengths and qualities, and picking the fewest hops would regularly choose the slow one. Babel's metric is extensible, so plugging latency into it means the routing converges onto the fastest path it can find rather than the shortest.

The wireguard-go it sits on is modified. The modified WireGuard implementation is a separate project, polyamide, and it is the data plane: the documentation says the data-plane runs entirely in wireguard-go, polyamide, capable of 10+ Gbps throughput.

So the architecture is a clean split. The cryptography and the packet transfer are WireGuard's, unmodified in the part that matters. The routing is Babel, which is what makes the mesh self-healing. And the two are joined by the modification to wireguard-go.

On the security of that arrangement, the documentation is explicit. Nylon does not modify WireGuard's cryptographic code, and all nylon control traffic, meaning route updates and probes, is sent inside the encrypted WireGuard tunnel.

That second point is worth pausing on, because it is the question a reader of any mesh VPN will have. Route updates are the one thing that would reveal the shape of your network if they travelled in the clear, so they travel encrypted, inside the same tunnel that carries your data. The control traffic is not a side channel on the public internet.

The dependency list supports the reading. There is a BART routing table library, a caching library with a time to live, a broadcast library, a ping library for the latency probing, and go-ping for measuring round trip times, along with the network composition and netip libraries for address handling, cobra for the command line, structured logging, and a multi-logger package.

Installing it, and the honest limitations

The installation is a single command on Linux, along with a systemd service that runs it with the configs in /etc/nylon:

curl -fsSL https://raw.githubusercontent.com/encodeous/nylon/main/install.sh | sh

Or you can download the binaries directly from the releases page, and the documentation then covers the setup, the configuration reference, guides for connecting WireGuard clients, port forwarding and comparisons with Tailscale and Nebula. Sample systemd service and launchctl plist files are under the examples directory, so the macOS service is handled alongside the Linux one.

The note about stability is the part to read. The author daily-drives nylon on Linux and macOS, the routing protocol has an extensive test suite and there are integration tests with simulated network conditions. But the config format may still change between releases.

That last clause is the practical warning. The project is pre-1.0, the version line is at 0.4.6, and a configuration format that can change between releases means you should keep your configuration under version control and expect to adjust it when you upgrade.

The Windows limitation is stated just as plainly. The Windows client has known issues, and the recommendation is to connect Windows machines as passive WireGuard clients via a Linux or macOS gateway.

That recommendation connects directly to the multi-hop feature. A Windows machine that cannot run the routing daemon still works as a WireGuard client pointing at a gateway node, and the mesh routes its traffic onwards from there. It is the same property that makes the mesh useful, applied to the one platform that is not supported as a first-class node.

The documentation also carries the trademark note. Nylon is not an official WireGuard project, and WireGuard is a registered trademark of Jason A. Donenfeld. And for security concerns the documentation points to contacting the author directly.

The remaining feature worth highlighting is the client compatibility one. Stock WireGuard clients on iOS, Android and Windows can connect to the mesh with zero extra software, and mobile clients move between gateways without extra setup.

That is a significant practical advantage over the alternatives. If you already use WireGuard on your phone, the mesh does not require you to install a new client and accept a new set of permissions and background behaviour.

What the repository contains

The repository layout shows a project that has been built with testing in mind, and the directory names describe the design.

There is core/ which holds the routing implementation and the test suite, protocol/ for the wire format, polyamide/ for the modified WireGuard, state/ for the persistent state, and log/ for the logging. There is cmd/ and a cli.go and a main.go for the command line. There is demo/ with a docker-compose.yml and a record.sh for producing the demonstration, and docs/ for the documentation site.

Then the directories that show how seriously the testing is taken: e2e/ for end-to-end tests, integration/ for integration tests, perf/ for performance work, and example/ for the service files.

The dependency list backs that up. There is testcontainers, which is the library that spins up throwaway containers for integration tests, and a test library, a comparison library for test assertions, a goroutine leak detector, and a network composition library for building test topologies.

The goroutine leak detector is worth a mention, because it is a category of test that matters enormously for a program whose whole job is to maintain long-lived state about peers and routes. A leaked goroutine in a routing daemon is a slow leak of memory and of open connections, and the leak detector turns that class of bug into a test failure.

The network composition library is the other one that stands out. Building a test network of nodes with specific links, then breaking specific links and asserting on convergence, is exactly the kind of test that a routing protocol needs and that is painful to write by hand.

The build tooling is a mise.toml, which is a task runner that pins the tool versions for a Go project, and the module requires Go 1.26.3, which is a recent toolchain requirement.

The model is that of a serious networking project rather than a weekend experiment: the dependency list includes the Moby client for talking to a container runtime, a protobuf implementation for the wire format, a cryptography library, and a step-based one for certificate handling.

The container build, and what it reveals

The Dockerfile has three stages, and each one tells you something about how the project is used.

The builder stage compiles the binary:

FROM golang:1.26.3 AS builder
WORKDIR /src

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags "-s -w" -o /nylon .

FROM scratch

# Copy binary from builder
COPY --from=builder /nylon /usr/local/bin/nylon

Two things stand out. The build is CGO disabled and cross-compiled to Linux, which is what makes the result statically linked and therefore runnable on any Linux distribution regardless of the libc it was built against. And the linker flags strip the symbol table and the DWARF data, which cuts the binary size and removes the debugging information from a release artefact.

The runtime stage is built FROM scratch, which is the most minimal possible base image. There is no shell, no package manager and no operating system userland in it, just the binary and a working directory. The entrypoint is the binary with the run subcommand.

That choice is not just about size, although a few megabytes is nice for a tool people deploy to many machines. A container with no shell is much harder to use as a foothold, which matters for something that runs with access to a network tunnel.

The third stage is the debug image, and it is the opposite in every respect:

FROM ubuntu:latest AS debug

ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    iputils-ping \
    iperf3 \
    curl \
    iproute2 \
    iptables \
    fping \
    mtr-tiny \
    wireguard-tools \
    net-tools \
    tcpdump \
    dnsutils \
    netcat-openbsd \
    tmux \
    # for demo \
    asciinema \
    python3 && \
    rm -rf /var/lib/apt/lists/*

COPY --from=builder /nylon /usr/local/bin/nylon

WORKDIR /app/config

ENTRYPOINT ["/usr/local/bin/nylon", "run", "-v", "-w", "--dbg-trace-tc"]

It is based on Ubuntu and installs the tools you need to investigate a network problem: ping, iperf3 for throughput measurements, curl, iproute2, iptables, fping, mtr-tiny, wireguard-tools, net-tools, tcpdump, dnsutils, netcat, tmux, and asciinema and python3 for the demo. The entrypoint runs the binary with verbose output, the watch flag and a trace flag for the traffic counters.

The two images together are a good expression of how the project expects to be used. The scratch image is what you deploy, and the debug image is what you reach for when something is wrong and you need to look at packets.

The demo/ directory follows the same pattern, with a docker-compose.yml that brings up a multi-node mesh and a record.sh that captures the terminal session as the animation used in the README, which is why asciinema appears in the debug image's package list.

Where this fits against the alternatives

The comparison the documentation itself invites is with Tailscale, Nebula and ZeroTier, and it is worth being precise about the trade.

What nylon gives up is the ecosystem and the tooling. A hosted overlay network gives you a device management UI, identity handling, key expiry and rotation, sharing a network with people who are not running your mesh, and a support path. None of that is in a self-hosted mesh with a YAML file, and if your requirement is to give a contractor access to three machines without running anything, a hosted service is a much shorter path.

What nylon gives up is also the mobile client story, at least partly. The stock WireGuard client compatibility is good, and roaming between gateways works, but there is no account system and no policy engine behind it. Access control is your configuration.

What it gains is the absence of a control plane. There is no company that can see your node list, no service that can go down, no per-node licence, and no request that your routing information passes through somebody else's server. For a network that connects machines you own, that is a large part of the value proposition, and it is why the project frames it as being like how a real network should be.

The second gain is multi-hop, and it is the one that decides the question for many deployments. If your nodes are spread across sites, home connections and cloud providers, a network where every pair must be directly reachable is a network that will have trouble. Nylon's forwarding through intermediate hops removes that requirement.

The convergence target of under ten seconds is what makes the self-healing claim usable rather than theoretical, and the demo exists so you can see it rather than take it on trust.

The things to weigh honestly are the maturity and the platform coverage. The version is 0.4.6, the config format may change between releases, Windows is not a first-class node, and this is a project maintained by one person with a Discord and a direct contact address for security issues. For a network you depend on, that is a real consideration, and the mitigation is the same as for any self-hosted infrastructure: understand it, run it on your own terms, and keep the configuration in version control.

Editorial conclusion

Adopt nylon if you need a WireGuard mesh where nodes are not directly reachable from each other and you do not want a coordination server or a SaaS dependency. Skip it if you need the full client management and identity features of a hosted overlay network, and if you need Windows as a first-class node. Verify first that your Windows machines can sit behind a Linux or macOS gateway, because the Windows client has known issues, that your configuration format is versioned carefully, since it may still change between releases, and that you understand what it means to run Babel inside your tunnel.

Frequently asked questions

Official sources

1. encodeous/nylon on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases