Remote serial port with Live Relay

Live Relay makes a physical serial port on one of your machines behave as a real port on another. The site machine shares the port, the operator machine opens a connection whose type is Remote Serial (Live Relay), and the cloud in between forwards the bytes without reading them.

Both ends dial out to the cloud, so it works across NAT with no public address and no inbound port — the same network posture as Live Console. The difference is what crosses the link. Live Console is a live window in a browser: text events, frame-limited, view and send. Live Relay is a transparent byte pipe speaking RFC 2217 end to end, so everything a local port can do still works:

Change baud rate, framing and flow control from the operator side, or keep the remote port's own configuration.
Drive DTR/RTS and Break; the control-line lamps follow the remote port's modem lines.
Run protocol streams unmodified — Modbus RTU polling, XMODEM/YMODEM file transfer, firmware updates.

By default both machines are signed in to the same account: you can only relay to your own devices. To let a colleague without an account in, use an invite code — opened in their own copy of the application, or straight in a browser with nothing installed. For how this path compares with RFC 2217, transparent TCP forwarding and Live Console, see Choosing a remote access path.

Share a port (site side)

Sign in inside the application (Cloud menu → Sign In).
Check Cloud → Live Console. The relay rides on the same cloud presence, so the main switch must be on; the consent switches below it stay greyed out until it is.
Check Cloud → Live Relay, or reach the same switch from Live Sync in the status bar. It is off by default and deliberately not implied by Allow Remote Send or Allow Remote Port Control — a relay is the whole port, handed over.
Open the serial connection you intend to share. Only serial connections are offered for relay: RFC 2217 describes a serial port, so a TCP or UDP endpoint has nothing for it to control.

While an operator holds the port, the status bar says so — the Live Sync cell turns orange and reads In use, and the notice names the operator — and the local window keeps displaying the traffic — data with no local sender is a takeover you should be able to see. Unchecking Live Relay ends every active relay from this machine at once.

Use the port from another machine (operator side)

Sign in with the same account.
In a connection's settings, choose Remote Serial (Live Relay) as the port type.
Pick the target in the "Select a Remote Serial Port" dialog. It lists your online devices and their serial ports, and marks the ports whose sharing side has not allowed relay. The port list is fetched from the device on demand, so it can take a few seconds to fill; the dialog keeps asking every 2 seconds for up to about 45 seconds, then says so if the device has not answered.
Decide who sets the serial parameters — the same rule as an RFC 2217 client: keep "use remote configuration" checked to leave the port as the site configured it, or clear it to push your own baud rate and framing when the connection opens.
Start the connection. The status bar reads "Live Relay · port · connecting", then "connected" once both ends are paired.

From then on it is an ordinary connection: Text/HEX send and receive, timestamps, logging, control lines, CRC tools and file transfer all work, and it can be bridged onward like any other port — including to a local TCP server for other programs.

Use the remote port from other programs (local TCP server)

On the operator machine, the application can hand a remote serial port on to other programs — a terminal program, a script, your own test tool, or a virtual COM driver that turns it into a local COM port or /dev/tty* device. This works for a Live Relay connection and for a direct RFC 2217 client connection alike:

Click the pane of the connection whose type is Remote Serial (Live Relay) or Remote Serial (RFC 2217) so it has the focus.
Choose Cloud → Remote Serial Port to Local TCP Server…, or pick the same entry from Live Sync in the status bar.
Choose how the client talks to it: RFC 2217 (the default) or Raw TCP.
Enter a TCP port (3000 is suggested; ports this window already uses are skipped) and click OK.

Like the RFC 2217 Server quick share, the port is open to any computer that can reach this one unless you restrict it, and the dialog says so. On a shared or untrusted network, tick Restrict to specific addresses / subnets and list the addresses allowed to connect — 127.0.0.1 alone keeps it to programs on this computer.

Then point your tool at 127.0.0.1:3000 on this computer, or <this computer's address>:3000 from another one. In RFC 2217 mode that is, for example, serial.serial_for_url('rfc2217://127.0.0.1:3000', baudrate=115200) in Python, or HW VSP3 with RFC 2217 ticked. In Raw TCP mode, use a plain socket, com0com + com2tcp on Windows, or socat PTY,link=/dev/ttyV0 TCP:127.0.0.1:3000 on macOS and Linux.

RFC 2217 (the default) passes the client's settings through to the remote port: baud rate, data bits, parity, stop bits, flow control, DTR, RTS and Break go to the far end over the connection's own RFC 2217 session. The client is answered with what the remote port answered, so a baud rate the device server rounds shows up as the rate actually in use, and the remote's CTS/DSR/RI/DCD come back as they change. If the remote port is not connected, has not accepted RFC 2217 control, or a file transfer is using it (queries are still answered), the client gets no answer and times out, and the status bar says why. "Keep the remote port's own configuration" only stops the pane from sending its own parameters; see Taking control of the serial parameters. Choose Raw TCP if the remote settings must not be changed.
Raw TCP carries only bytes, for socat, nc and terminal programs. The serial parameters are the ones set in the remote connection's own pane, and control lines do not travel over it. Do not point a raw client at the RFC 2217 mode: it would see Telnet negotiation bytes and doubled 0xFF.
It never opens the remote port by itself. Opening a relay takes over a remote port and uses traffic, and dialling a device server takes it over too, so it only happens when you start that connection; until then the link shows as degraded.
One client at a time. The link is saved with your settings like any bridge and appears under Tools → Bridges… as Remote Serial Local Server :<port>, where it can be disabled or removed.
For a Live Relay connection, bytes through it are relay traffic and count against the same monthly allowance. A direct RFC 2217 connection does not go through the cloud and uses no allowance.

Share from a headless machine (the spu command)

A site machine does not need a desktop session. The direct-download build ships a small console program spu beside the GUI (the Mac App Store build does not include it):

spu -l                                   # list local serial ports
spu login --email user@example.com       # sign in; prompts for the password without echo
spu -D /dev/ttyUSB0 -b 115200            # raw local terminal (stdin ↔ serial)
spu -D /dev/ttyUSB0 -b 115200 --share    # share this port through Live Relay

spu login stores the account session in the same profile the GUI uses; for provisioning scripts, pipe the password to --password-stdin instead of putting it on the command line. -S / --share opens the port and turns on relay consent only — no Live Console traffic stream, no remote send, no generic port-control commands — and it is strictly the sharing side: it never selects or dials another machine's port. An idle sharing agent is a control-plane presence; nothing is captured or uploaded until an operator actually engages the port.

Share with a colleague (Live Share)

The two sections above are about two machines of your own. To let a colleague who has no account work on the port with you, use an invite code: the site machine mints a time-limited code for one open serial port, and your colleague either pastes it into their own copy of the application and gets exactly the port you would have got, or opens it in a browser with nothing installed. They need no registration, no subscription and no bound device; the traffic stays on your side.

This is independent of Live Relay, in both directions: that switch admits your own other machines, an invite admits the holder of the code, to that one port, for that long. For minting, the three browser levels, spu --invite and everything the host can take back, see Live Share.

Good to know

One relay per port. A second operator asking for a port that is already relayed is refused loudly rather than silently sharing a byte stream that would give each side half of every reply.
A relay that drops — either end going offline, the session closed from the other side — ends; it is not silently redialled. Start the connection again deliberately.
The relay is rate-limited per session. A stream faster than the allowance is throttled with real back-pressure toward the source, and a brief "rate limited" advisory appears; each session also has a data ceiling, after which it is closed.
Common open failures: the sharing side's Live Relay is off (permission_denied), the port is already relayed (relay_busy), the device is offline, or the account's cloud traffic allowance for the month is used up.
Run one copy of the application per computer on the sharing side. Two copies share the machine's identity and take each other's commands; the application warns when it sees this.
Timing quirks aside, the traffic itself is exactly what a direct RFC 2217 connection would carry — byte-for-byte, escaping included.

Traffic, quota and subscription

Live Relay does not require Pro; every account can use it. What differs is the monthly traffic allowance — 10 MB per direction on a free account, 1 GiB with Pro (a paid licence or an active subscription), then purchased traffic packs. It bills by usage, not by fleet size, and a forgotten full-speed session would drain a free allowance in minutes.
Relayed bytes are metered against the same monthly cloud traffic allowance and top-up balance as Live Console; there is no separate relay quota.
Budget with this number: a port running flat out at 115200 8N1 in both directions moves about 22.5 KB/s — roughly 81 MB per hour. Most debugging sessions are far below that, but a busy binary stream is not.

Security and privacy

Sharing is off by default, and consent lives on the machine that owns the port; nothing on the web or in the cloud can switch it on remotely.
Both legs are outbound encrypted connections. A relay pairs two machines on the same account, or one machine with the holder of an invite code it minted itself — either way the machine that owns the port is what authorises it.
Within an accepted relay, changing serial parameters and driving DTR/RTS/Break are intentional parts of handing the port over — grant Live Relay only where that is acceptable.
A browser guest sees that one port's decoded text, passed through a short cloud buffer with the same size and retention as Live Console; how far they can go is fixed when you mint the code, checked once by the server and once by your device, and cannot be raised from the web.
Switching Live Relay off or signing out ends all relays immediately. These data flows are disclosed in the Privacy Policy.

Remote serial port with Live Relay

On this page