Skip to content

Chapter 11 — Deployment

This chapter covers extending a Stolo mesh beyond phones: relay/transport nodes on Raspberry Pi, internet gateways, and fleet deployment practices.

11.1 Why deploy relay nodes

Phones are mesh endpoints: they send and receive their own traffic but do not route for others, and mobile OSes suspend backgrounded apps. A relay node is an always-on device with transport enabled that:

  • Routes traffic between devices that can't hear each other directly (extends coverage);
  • Holds and forwards messages toward devices that are temporarily off the air;
  • Bridges transports — e.g. a Pi with both a LoRa radio and an internet uplink joins the local radio mesh to distant teams via the gateway.

Typical pattern: one Pi relay per site, elevated, on constant power, with a LoRa radio and (optionally) internet.

11.2 Raspberry Pi relay node

Hardware: Raspberry Pi (64-bit Raspberry Pi OS Lite), SD card, power, optional RNode LoRa radio on USB, optional Ethernet/WiFi uplink.

Install:

sudo apt update && sudo apt install -y git
git clone --recurse-submodules https://github.com/RameenHash/gridx.git
bash gridx/deploy/gridx-pi-setup.sh
sudo reboot

The setup script:

  1. Installs system packages (Python 3, pip, venv, cryptography, pyserial, git).
  2. Installs the Stolo engine and its Reticulum/LXMF dependencies.
  3. Adds the user to the dialout group for RNode USB access.
  4. Installs a systemd service (gridx.service) that starts the engine at boot and restarts it automatically on failure.
  5. Configures a WiFi hotspot on wlan0 so phones can join the node directly in the field.

Change the hotspot credentials. The script ships sample hotspot credentials (SSID GridX-Node). Edit the SSID and passphrase in the script — or reconfigure the connection in NetworkManager — before fielding a node. Never deploy the defaults.

Enable transport (routing). The baseline configuration ships with transport off. On a relay node, edit ~/.gridx/reticulum/config:

[reticulum]
  enable_transport = Yes

then sudo systemctl restart gridx. The node now routes traffic for the mesh and appears with a RELAY badge on the Mesh view.

Attach a LoRa radio: plug an RNode into USB — it is auto-detected and configured on the next service start, using the node's radio-region preset. Verify parameters match your fleet (Chapter 5).

Operations:

Task Command
Service status sudo systemctl status gridx
Live logs journalctl -u gridx -f
Network status rnstatus
Restart sudo systemctl restart gridx
Update cd ~/gridx && git pull --recurse-submodules && sudo systemctl restart gridx

Phones join the node's hotspot and communicate over Local WiFi discovery automatically; the app's advanced setup can also point at a node directly.

11.3 Internet gateways and custom backbones

Every install ships connected to the Stolo Gateway (gw.stolo.io:4242), which lets any two Stolo devices with internet reach each other. The gateway relays ciphertext only — see Chapter 10.

Organizations can run their own equivalent:

  1. On a server or reachable Pi, add an Internet (hosting) interface — a TCP server or Backbone interface listening on a port of your choice (default Reticulum port is 4242) — and enable transport.
  2. On each device, add an Internet node (TCP) connection pointing at your server (Chapter 5).
  3. Optionally disable the default Stolo Gateway connection for a fully self-hosted topology — Stolo will not re-add it.
  4. For private meshes, configure IFAC credentials (network name + passphrase) on the interfaces at both ends so only your devices can use the link.

11.4 Fleet deployment practices

  • Radio plan first. Pick one region preset (or a custom parameter set) for the whole fleet — radios only interoperate on identical parameters. Record frequency/bandwidth/SF/CR/TX power in your ops documentation.
  • Organize trust. Provision devices under an organization and trust the org fleet-wide rather than pairwise (Chapter 8). Enable strict mode on unattended devices.
  • License before fielding. Activation needs internet once (Chapter 9); activate and verify each device before it goes off-grid.
  • Background mesh on receivers. Phones that must receive while locked need Background mesh enabled and the Always location grant (Chapter 6) — or a site relay to hold traffic until they wake.
  • Verify end-to-end before departure. Send a test message across every planned transport (WiFi, LoRa, gateway) and confirm Delivered status on the sender.
  • Site relay placement. Height beats power for LoRa. Keep relays on UPS/solar where possible; the service auto-restarts, and the engine auto-reconnects the gateway link through network churn.

11.5 Desktop workstations

macOS and Debian-based Linux workstations install with the repository's make setup (which bootstraps Python, Flutter, and dependencies) and run the engine (make run-backend) and app (make run-frontend) as separate processes. Desktop installs behave like phones (endpoints, transport off) unless configured otherwise, and support USB and Bluetooth RNode radios. Local WiFi discovery requires UDP ports 29716 and 42671 open on the host firewall.