Remote access

The supported cross-machine unit in Helmora is a bridge. Run one beside the agents and repositories on each machine, pair it to your account, and reach it from the app. How the app reaches it depends on where you are.

Same machine: no relay at all

When the app and the bridge are on the same host, the app talks to the bridge over loopback and sends plain protocol JSON. Nothing leaves the machine, and the relay is not involved in any way. This is the quiet default when you’re sitting at the computer the agents run on.

The bridge does not expose that plaintext surface beyond loopback.

Remote: the managed relay

Otherwise, the app uses Helmora’s managed relay. Both the app and the bridge authenticate as devices on your account, establish their end-to-end encryption state, and exchange opaque envelopes; the relay routes between them and sees routing metadata rather than agent traffic. See Security for the exact boundary.

Both ends make outbound connections, so neither needs an inbound port. Use this path when:

• the app is on a phone or a browser away from the bridge;
• the bridge sits behind NAT or a residential firewall;
• more than one bridge is paired to your account; or
• you simply want the normal transport rather than a local shortcut.

If a bridge shows offline, check the bridge process, its pairing, and its outbound HTTPS/WebSocket access before anything else — see Troubleshooting. Opening provider-specific ports is not a workaround for a relay problem.

Alternative: your own tunnel

If you’d rather not use the managed relay, you can reach the bridge directly over a transport you operate — a TLS-terminated reverse proxy, an SSH forward, or an authenticated private overlay such as a mesh VPN. Helmora does not create, own, or manage those tunnels; you do.

Minimum posture if you go this way:

• Keep the bridge bound to loopback unless you have deliberately enabled its direct-listener configuration and authentication gate.
• Terminate TLS, or use an authenticated private overlay.
• Never publish a bare development port to the public internet.
• Preserve the app and bridge account claim in the handshake — the bridge still validates that the connecting client belongs to the paired account and device.

One thing to be explicit about: a direct transport bypasses relay routing and the relay’s end-to-end envelope encryption, because that layer exists to keep the relay out of your payloads and there is no relay in the path. The confidentiality of a direct connection is whatever your tunnel provides. That is a fine trade when you control the tunnel and a bad one when you don’t.

What is not supported

• No self-hosted relay. There is no supported self-hosted relay offering today. The choice is the managed relay or your own tunnel straight to the bridge.
• No tunnelling a provider daemon. Running one bridge on machine A and pointing it at an agent daemon on machine B is not a supported topology. Pair a bridge on machine B instead — that keeps its credentials, folders, processes, and transcripts where they belong, and makes the device selector in the add-agent flow mean something.

Recommended shape

phone / browser
       |
account + managed relay
       |
bridge on your laptop    -> local Claude Code / Codex / Copilot / OpenCode / Goose
bridge on your desktop   -> local Claude Code / Codex / Copilot / OpenCode / Goose

One bridge per machine, each paired to the same account, each selectable in the app. See Pair a bridge for the setup.