Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Remote access through the cloud broker

The cloud broker lets you operate your radio from outside your network with no port forwarding, no VPN and no dynamic-DNS setup. The proxy next to your radio opens a persistent outbound WebSocket (wss) uplink to the broker; clients anywhere connect to the broker, prove they’re yours, and the broker brokers a WebRTC session between them and your proxy.

The public broker runs at podsdr-broker.fly.dev. You can also self-host one.

Step 1 — start the uplink

From the server bundle directory, on the machine next to the radio:

./run-cloud.sh home            # "home" = the name this proxy shows in clients
PROXY_NAME=shack ./run-cloud.sh   # same, via environment variable

(Windows: run-cloud.bat home.)

By default this also keeps serving the web client on the LAN over HTTPS on port 8080, exactly like run.sh — one process does both. Control that with:

  • PORT=8443 ./run-cloud.sh — change the local HTTPS port.
  • NO_LOCAL_WEB=1 ./run-cloud.sh — pure cloud uplink, no LAN web server.

Step 2 — pair the proxy to your account

While the proxy is unclaimed (not yet attached to any account), the broker issues it a short pairing code, which the launcher highlights in the console:

>>> PAIRING CODE for "home":  XXXX   -- enter it in a client Cloud hub panel to claim this proxy <<<

Open the Cloud hub panel in any client — web, desktop GUI or Android — and enter the code. That claims the proxy under your account:

  • The broker stops issuing pairing codes for it.
  • On later starts the launcher prints >>> proxy "home" is already claimed -- authorized clients can connect now <<<.
  • Only clients authorized under your account can reach it. The broker signs session tokens with its key, and your proxy verifies them against the hub public key it was started with — the broker can’t be silently swapped out from under you.

If the code scrolled away, it’s in the proxy log; when running as a systemd service:

journalctl -u podsdr-proxy | grep "with code:"

Step 3 — connect from anywhere

In a client’s Cloud hub panel, your claimed proxies (and the radios each one offers) are listed once you’re signed in to the same account. Pick one and connect — the audio/IQ/control traffic flows over a WebRTC connection negotiated through the broker, traversing NAT on both ends.

Self-hosting the broker

run-cloud.sh targets the public broker via two environment variables you can override:

BROKER_URL=wss://my-broker.example HUB_PUBLIC_KEY=<hex key> ./run-cloud.sh shack

The broker (podsdr-broker) is designed to deploy on fly.io; see docs/deploy-fly.md in the repository for the deployment walkthrough. The HUB_PUBLIC_KEY must be the public half of your broker’s signing key — proxies refuse session tokens signed by any other broker.