Skip to content

REMOTE.md

Latest commit

 

History

History
162 lines (104 loc) · 7.66 KB

REMOTE.md

File metadata and controls

162 lines (104 loc) · 7.66 KB

Remote Access

Use this when you want to connect to a T3 Code server from another device such as a phone, tablet, or separate desktop app.

Recommended Setup

Use a trusted private network that meshes your devices together, such as a tailnet.

That gives you:

  • a stable address to connect to
  • transport security at the network layer
  • less exposure than opening the server to the public internet

Enabling Network Access

There are two ways to expose your server for remote connections: from the desktop app or from the CLI.

Option 1: Desktop App

If you are already running the desktop app and want to make it reachable from other devices:

  1. Open Settings → Connections.
  2. Under Manage Local Backend, toggle Network access on. This will restart the app and run the backend on all network interfaces.
  3. The settings panel will show the default reachable endpoint, with a +N control when more endpoints are available. Expand it to inspect alternatives such as loopback, LAN, private-network, or HTTPS endpoints.
  4. Use Create Link to generate a pairing link you can share with another device.

The default endpoint controls the QR code and primary copy action for pairing links. You can change it from the expanded endpoint list. The preference is stored by endpoint type, so choosing the local LAN endpoint survives normal IP address changes when you move between networks.

When no user default is saved, the app uses the built-in LAN endpoint for pairing links when available. You can set another endpoint as the default from the expanded endpoint list.

  • HTTPS/WSS-compatible endpoints work from https://app.t3.codes, but are not made the default automatically.
  • Non-loopback HTTP endpoints are useful for direct LAN pairing.
  • Loopback-only endpoints are not useful for another device unless that device is the same machine.

If the copied link points directly at http://192.168.x.y:3773, open it from a client that can reach that LAN address. If it points at https://app.t3.codes/pair?..., the hosted web app will save the environment and connect directly to the backend URL in the link.

Tailscale Endpoints

When the desktop app can detect Tailscale, it adds Tailnet endpoints to the reachable endpoint list.

Depending on your Tailscale setup, this may include:

  • the machine's 100.x.y.z Tailnet IP
  • a MagicDNS name
  • an HTTPS MagicDNS endpoint when Tailscale Serve is configured for this backend

The Tailscale HTTPS endpoint uses the clean MagicDNS URL, such as https://machine.tailnet.ts.net/, and is disabled until the app verifies that the URL reaches this backend. Use Setup on the Tailscale HTTPS row to opt in. The desktop app restarts the backend with the same server-side behavior as t3 serve --tailscale-serve, then the server asks Tailscale Serve to proxy HTTPS traffic to the local backend.

The Tailscale support is an endpoint provider add-on. The core remote model still works without Tailscale: LAN HTTP endpoints, custom HTTPS endpoints, future tunnels, and SSH-launched environments all use the same saved environment and pairing flow.

For https://app.t3.codes, prefer an HTTPS Tailnet or other HTTPS endpoint. A plain http://100.x.y.z:3773 endpoint can still work from a desktop client or another browser page served over HTTP, but it will not work from the hosted HTTPS app because of browser mixed-content rules.

Option 2: Headless Server (CLI)

Use this when you want to run the server without a GUI, for example on a remote machine over SSH.

Run the server with t3 serve.

npx t3 serve --host "$(tailscale ip -4)"

t3 serve starts the server without opening a browser and prints:

  • a connection string
  • a pairing token
  • a pairing URL
  • a QR code for the pairing URL

From there, connect from another device in either of these ways:

  • scan the QR code on your phone
  • in the desktop app, enter the full pairing URL
  • in the desktop app, enter the host and token separately
  • in the hosted web app, open a hosted pairing URL when the backend is reachable over HTTPS

Use t3 serve --help for the full flag reference. It supports the same general startup options as the normal server command, including an optional cwd argument.

For hosted web pairing over Tailscale HTTPS, opt in to Tailscale Serve:

npx t3 serve --tailscale-serve

By default this configures Tailscale Serve on HTTPS port 443 and advertises https://machine.tailnet.ts.net/. Advanced users can choose a different HTTPS port:

npx t3 serve --tailscale-serve --tailscale-serve-port 8443

Note The GUIs do not currently support adding projects on remote environments. For now, use t3 project ... on the server machine instead. Full GUI support for remote project management is coming soon.

Option 3: Desktop-Managed SSH Launch

Use this when you want the desktop app to start or reuse T3 Code on another machine over SSH.

  1. Open Settings → Connections.
  2. Under Remote Environments, choose Add environment.
  3. Select the SSH launch flow.
  4. Enter the SSH target, such as user@example.com.
  5. Confirm the launch. The desktop app probes the host, starts or reuses a remote T3 server, opens a local port forward, and saves the environment.

After setup, the renderer connects to a local forwarded HTTP/WebSocket endpoint. The remote host still owns the actual T3 server, projects, files, git state, terminals, and provider sessions.

SSH launch is a desktop feature because it needs local process and SSH access. Once the environment is paired and saved, it uses the same environment list and connection model as direct LAN, Tailscale, HTTPS, or future tunnel-backed environments.

How Pairing Works

The remote device does not need a long-lived secret up front.

Instead:

  1. t3 serve issues a one-time owner pairing token.
  2. The remote device exchanges that token with the server.
  3. The server creates an authenticated session for that device.

After pairing, future access is session-based. You do not need to keep reusing the original token unless you are pairing a new device.

Hosted Web App Pairing

The hosted web app at https://app.t3.codes can save a remote backend in browser local storage from a URL like:

https://app.t3.codes/pair?host=https://backend.example.com:3773#token=PAIRCODE

Use hosted pairing when the backend is reachable from the browser over HTTPS/WSS. This includes a backend behind a trusted HTTPS tunnel or another HTTPS endpoint you operate.

Do not use hosted pairing for plain HTTP LAN URLs such as http://192.168.x.y:3773. Browsers block an HTTPS page from connecting to an insecure HTTP or WS backend. For those endpoints, use the direct pairing URL shown by the desktop app or CLI from a client that can open that HTTP URL directly.

Hosted pairing does not proxy traffic through T3 Code. The browser still connects directly to the backend URL in the pairing link.

Managing Access Later

Use t3 auth to manage access after the initial pairing flow.

Typical uses:

  • issue additional pairing credentials
  • inspect active sessions
  • revoke old pairing links or sessions

Use t3 auth --help and the nested subcommand help pages for the full reference.

Security Notes

  • Treat pairing URLs and pairing tokens like passwords.
  • Prefer binding --host to a trusted private address, such as a Tailnet IP, instead of exposing the server broadly.
  • Anyone with a valid pairing credential can create a session until that credential expires or is revoked.
  • Hosted pairing links keep the credential in the URL hash so it is not sent to the hosted app server, but it can still be exposed through browser history, screenshots, logs, or copy/paste.
  • Use t3 auth to revoke credentials or sessions you no longer trust.