How Weft is built

The fabric

Each site runs the Weft agent on Ubuntu 24.04. Sites are joined by WireGuard tunnels, one over each uplink. Inside them, VXLAN carries both routed traffic and any stretched layer-2 segments, with BGP EVPN telling each site where every network lives. Routing is FRRouting, and failed links are detected by BFD in under a second.

Your own networks sit in a separate routing table from the tunnels that carry them, so nothing you route can capture the fabric's own links.

A control plane outside the packet path

Weft's control plane is serverless and runs in AWS's London region. It holds your intended configuration, keys' public halves and health, and talks to each site over an outbound connection the site opens — no inbound ports for management.

It is never in the path of your traffic. Every site holds its complete configuration and re-applies it every thirty seconds, so a missed message heals itself and an unreachable control plane leaves the network forwarding exactly as it was.

Changes reach one site first

A change to the fabric goes to a single canary site and is held there until that site confirms it applied cleanly and is healthy. Only then does the rest of the fleet receive it. Agent upgrades work the same way, with a watchdog that rolls a site back if the new version does not come up.

Drift detection

Being told what to install is not the same as having it installed. Every site compares what its kernel actually holds against what it put there — routes, routing rules, addresses, WireGuard peers and their allowed addresses, the firewall policy chain in order, and its Wi-Fi access point — and reports any difference by name. A site where someone has hand-edited the firewall shows up as a warning, not as a healthy site quietly enforcing the wrong policy.

Bring-up from a browser

1. In the console, open Add a Linux node and copy the command it gives you.
2. Run it on a fresh Ubuntu 24.04 machine. It checks the machine first and changes nothing if something is wrong, then installs the agent, verifies its checksum and enrols with a one-time invitation.
3. The site generates its own keys, connects, and appears in the console. Its uplinks, site port and routed port are chosen from lists of the interfaces it reports — no interface names to guess.

For new hardware there is also an unattended Ubuntu install that runs the same steps on first boot.

What you can see

• Latency and loss on every path between every pair of sites, worst first, with history.
• Packets allowed and denied by each policy contract.
• Every site's agent version, architecture, uplinks and warnings.
• Every change, where it is in the canary process, and whether it was verified.

A set of fleet-wide invariants runs every hour and reports anything that should never be true, such as a site that has not said what hardware it runs on.

Platforms

• Sites: Ubuntu 24.04 LTS
• x86-64
• ARM64
• Clients: macOS
• Windows
• Linux