This example shows one vine binary deployed to four Linux machines:
alpha: user workstation advertising10.42.0.0/24beta: server node advertising10.42.1.0/24gamma: second workstation advertising10.42.2.0/24relay: relay-capable node advertising10.42.254.0/24
All four nodes join the same overlay network:
network_id = "home-net"
The intended path behavior is:
alphareachesbetadirectly when a directlibmeshsession is available.gammareachesbetathrough signaling-assisted setup when direct reachability needs help.gammareachesalphathroughrelaywhen direct setup fails.alphafalls back torelayif an existing direct session tobetadrops.
The examples in this directory are operator-facing config assets, not Zig embedding samples.
They are designed to be copied to multiple PCs alongside the same vine binary.
Each authenticated peer owns exactly one overlay prefix in this showcase:
alphaowns10.42.0.0/24betaowns10.42.1.0/24gammaowns10.42.2.0/24relayowns10.42.254.0/24
The relay node is still a normal peer with a normal prefix. Relay capability is an explicit policy flag, not a special identity type.
Peer IDs in the example configs are placeholders. In a real deployment, replace them with vine identity export-public
or vine identity fingerprint output derived from each machine's persisted libself identity.
Overlay IPs are routing coordinates only. They do not identify the node.
The example assumes:
alphabootstraps fromrelaybetabootstraps fromrelaygammabootstraps fromrelayrelaybootstraps fromalpha
That keeps one relay-capable node easy to discover while avoiding a single completely isolated first-start path.
- Copy the same
vinebinary to all machines. - Generate one local
libselfidentity per machine. - Install the matching node config from this directory.
- Replace example peer IDs and UDP addresses with real values before starting the daemon.