Lofenta Private Network (LPN)

Reaching another project on the same node is a single hop, project to bridge to project. Reaching a project on a different node crosses machines, and that is where the routed WireGuard mesh does the work.

Every node hosting at least one member of a network runs a dedicated WireGuard interface for that network, wired to a local Docker bridge carrying that node's member addresses. Nodes peer with each other over that interface, and each peer's AllowedIPs is set to the remote node's /27 block, not a single address. WireGuard treats AllowedIPs as a routing table: when node A needs to reach a member IP that falls inside node B's block, it already knows that block belongs to node B's peer and sends the packet straight there, encrypted, without any routing your application has to think about.

Add or remove a node from a network and the reconcile loop rewrites the peers on every node. The addressing scheme is what keeps that routing correct without manual tables.

Create a named network (for example prod), then attach your projects to it. Every attached project gets a fixed name on that network, in one form:

worker.prod.lpn.lofenta.internal

That name works the same whether both projects run on the same node or on two different nodes entirely, and it resolves for any client connected to the network too. It is DNS, not a proxy or a symlink: each node's local resolver for the network maps the name straight to the member's 100.64 address. A project keeps its normal public URL as well, the private name is additive, not a replacement.

You do not have to be a Lofenta project to join an LPN. From a network's page in the dashboard you can add a client, a device identity with its own WireGuard keypair and a 100.64 address from the network's reserved client block.

Key handling is one-shot by design: the server generates the keypair, returns the full config, including the private key, exactly once, and stores only the public key and the assigned IP afterward. If you lose the file you cannot recover the private key, you regenerate it, which issues a new keypair and revokes the old one.

A downloaded config looks like this:

[Interface]
PrivateKey = <yours, shown once>
Address = 100.64.12.230/32
DNS = 100.64.12.1

[Peer]
PublicKey = <node A public key>
Endpoint = <node A public IP>:51900
AllowedIPs = 100.64.12.0/27
PersistentKeepalive = 25

[Peer]
PublicKey = <node B public key>
Endpoint = <node B public IP>:51905
AllowedIPs = 100.64.12.32/27
PersistentKeepalive = 25

Notice there is one [Peer] entry per node that hosts a member of the network, not one entry for the whole network. Each peer's endpoint is that node's public IP and WireGuard listen port, and its AllowedIPs is scoped to that node's own /27. Your computer does not funnel every packet through one central gateway, traffic to a project on node A goes straight to node A, traffic to a project on node B goes straight to node B. Every node carrying a member of the network is a gateway into it, and adding a node to the network appends a peer the next time you regenerate your config.

The WireGuard listen ports nodes use for LPN (one per network per node, in the 51900 to 52899 range) are not open to the whole internet. A node only completes a handshake with a client whose source IP is on that client's allowlist, every other source is dropped before WireGuard ever sees the packet.

When you add a client, the dashboard can detect your current public IP and prefill it. If your ISP rotates your address later, a one-click "update my IP" on that client keeps the tunnel working, and you can list more than one CIDR if you connect from more than one place. This sits on top of WireGuard's own key-based authentication, not instead of it, a stolen config still cannot be used from an unlisted network.