Skip to main content
Clustering is optional. A single node works standalone. Clustering enables:
  • Dashboard aggregates metrics across all nodes
  • Per-region drill-down for provider performance comparison
  • Cluster health monitoring (node status, region discovery)
Each node makes its own provider-selection decision from local measurements; there is no cross-node coordination in the request hot path. Peers can still supply recovery hints for local block protection, and optional global block publication has a separate shared-storage contract. See block continuity before treating a multi-node deployment as one continuity domain.

​
Requirements

  • A private DNS A record that resolves to every node’s reachable IP address.
  • Named Erlang nodes in the form lasso@<IP>, with the same private cookie.
  • Connectivity between nodes on EPMD port 4369 and Erlang distribution ports. Keep these ports private; Docker HTTP port mappings alone do not provide it.
  • A unique, stable LASSO_NODE_ID for each instance.

​
Configuration

For each release/container instance, set: Replace the example IP and DNS name with your network’s values. For a second node at 10.0.0.12, use RELEASE_NODE=lasso@10.0.0.12 and a different LASSO_NODE_ID; keep the cookie, DNS query, and basename the same. Supply matching profile YAML to every node. Reload each node after adding or editing profiles. In Compose, put these values in each instance’s .env and recreate its container with docker compose up -d --force-recreate --wait. Nodes poll DNS every five seconds. The deployment network must allow direct access to the IPs in DNS. Check the running node’s name and peers:
Each node should list the other members. An empty peer list means the node has not joined; check names, cookie equality, DNS results, and private connectivity. Setting discovery variables alone does not name a VM launched with plain mix phx.server; the release settings above apply to release/container startup.

​
Geo-Distributed Deployment

For optimal performance, deploy one Lasso node per region and route application traffic to the nearest node (via GeoDNS, anycast, or your load balancer’s geographic routing). Each node independently:
  • Measures latency to upstream providers from its region
  • Selects providers using its configured strategy and local observations
  • Maintains independent circuit breaker state
The dashboard aggregates data across all nodes for unified observability with regional drill-down.