Phone pairing

Pairing lets a phone or another device on your network open the Studio web UI without exposing it to the internet. Approve one device, keep it in the trusted list, revoke it when you are done.

What pairing is

• The local Studio keeps listening on 127.0.0.1:5117 and a LAN listener on 5118.
• A non-loopback browser is refused until LAN access is on and the device is paired.
• Pairing uses a QR code or a short PIN; the resulting device token is stored hashed.
• A paired phone gets the mobile scope, not the full desktop admin surface.
• Pairing is for the Studio UI. The Compute API has its own bearer token.

This is not a reverse proxy or a public tunnel. Both devices must be on the same network, or connected through a VPN you trust.

Enable LAN pairing

1. Settings → Phone pairing (the tab id is pair).
2. Turn on Allow LAN device pairing. The change takes effect immediately; no restart.
3. Keep the admin surface on loopback. Pairing setup is still loopback-only.
4. If Windows asks, allow the Studio process on private networks only.

Pair a device

1. Open the pairing panel on the desktop Studio. It shows a QR code and a short PIN.
2. On the phone, open the LAN address shown (for example http://192.168.1.20:5118) and scan the QR or enter the PIN.
3. Confirm the device on the desktop. The phone receives a device token and is added to the trusted list.
4. The phone now opens the mobile Studio. Sessions, chats and saved models are the same local data.

A one-time login QR is also available when you want a short-lived session rather than a long-lived trusted device.

Manage devices

• Trusted devices lists what has been approved; revoke anything you no longer use.
• Revoking a device invalidates its token immediately; the phone must pair again.
• Turning LAN pairing off stops new pairings and refuses non-loopback browsers.
• A lost phone should be revoked first, then rotate any provider keys it could see.

Remote Studio

The combined server image serves Studio on 5117 and sets Studio__LanEnabled=true, so a browser on another machine is redirected to /pair. The same pairing rules apply.

If you cannot reach the pairing UI, the container can create an offer and approve it locally. From the host:

docker exec <container> curl -s -X POST http://127.0.0.1:5117/gateway/api/pairing/new

# open http://<public-ip>:5117/pair, enter the token and PIN, then:
docker exec <container> curl -s -X POST \
  http://127.0.0.1:5117/gateway/api/pairings/<ID>/approve \
  -H "Content-Type: application/json" -d "{\"mode\":\"desktop\"}"

On Runpod, use the pod's web terminal for the same commands. Keep the Studio port restricted in the provider firewall; pairing is not a substitute for that.

Security

• Device and pairing tokens are stored hashed; PINs are salted and deliberately slow.
• Secrets are AES-GCM encrypted with the local key box.
• The mobile scope is enforced by the server, not just hidden in the UI.
• Admin pairing setup stays on loopback.
• Use a trusted private network; guest Wi-Fi with client isolation will not reach the LAN listener.

Problems