Leaf Nodes & Sidecars
The wasmCloud Q3 2025 Roadmap sets out plans for an overhaul to scheduling in the next major release of wasmCloud. The new scheduling API will not use NATS to communicate between components by default, but will still support distributed communication via NATS. For more information, see the Roadmap and Issue #4640: “Intentional distributed networking.”
NATS leaf nodes are a flexible way to extend NATS infrastructure. Leaf nodes enable segmentation or isolation of traffic and/or security boundaries.
wasmCloud can use leaf nodes to simplify lattice configuration. A common pattern involves starting a NATS leaf node alongside a wasmCloud host on a system (virtual or otherwise). The leaf node is configured with credentials for authenticating with an external NATS cluster. By delegating the NATS authentication to the leaf node, the wasmCloud host can connect to the leaf node anonymously.
This type of "anonymous localhost" connection is commonly used in the sidecar pattern, which is why we've labelled this this "sidecar leaf node" pattern.
This segmentation enables bridging disparate infrastructure. Using leaf nodes at the "edges" or boundaries of your infrastructure allows the lattice to expose a single, flat topology, while NATS and leaf nodes take care of all the hard work of optimizing traffic patterns for the interest graph across an arbitrarily complex network. Leaf nodes can be used to string together disparate infrastructures, multiple private cloud environments, etc. Their simplicity is key; check out the NATS documentation linked above to learn more.
A powerful feature of leaf nodes is that traffic is kept local whenever it can be. For example, if a wasmCloud host issues an invocation, and a target of the invocation is available on the leaf network, the traffic will be routed locally, reducing latency and preventing cross-network traffic.