Tunnels and remote access

A tunnel publishes your dashboard to a public URL so you can reach it away from the machine — phone on the subway, laptop at a café. Three providers are built in; every remote browser must pair before it gets in. The trust rules behind this page are in Security model.

Choosing a provider

Rules of thumb: localtunnel for zero-setup trials; ngrok for a personal stable URL with minimal config; Cloudflare for a permanent hostname on your own domain.

Configuration

In ~/.vibearound/settings.json (or the desktop settings screen):

{
  "tunnel_provider": "ngrok",
  "ngrok_auth_token": "2ab...",
  "ngrok_domain": "myname.ngrok.app"        // optional reserved domain
}

{
  "tunnel_provider": "cloudflare",
  "cloudflare_tunnel_token": "eyJ...",       // from the Zero Trust dashboard
  "cloudflare_hostname": "va.example.com"
}

{ "tunnel_provider": "localtunnel" }

Cloudflare needs one manual step

VibeAround starts cloudflared tunnel run --token … and uses your hostname for generated URLs — but it does not create the Cloudflare Published application route. In Zero Trust, add one for the same tunnel:

Then open https://vibe.example.com/va/ — the dashboard lives under /va/, so test that path, not just the root.

To isolate Cloudflare from VibeAround: stop VibeAround, serve anything on 127.0.0.1:12358 (python3 -m http.server 12358 --bind 127.0.0.1), and curl -i https://vibe.example.com/. A Cloudflare 404 before your temp server answers means the problem is in the hostname/DNS/route/tunnel-health layer, not VibeAround. References: Published applications, run parameters.

The tunnel starts with the daemon. Status and the public URL show in the dashboard, va tunnels, and the desktop app; va tunnel kill <provider> stops one without restarting the daemon.

First visit from a remote browser: pairing

Opening the public URL on a new device shows the pairing gate:

1. The browser displays a 6-digit code (valid 60 seconds, refreshable).
2. Confirm it from a surface you already trust:
   • type /pair <code> in any connected IM chat, or
   • approve it locally (dashboard/desktop on the machine), or
   • va pair flows from the CLI (pair start --wait --save also stores auth for CLI use against a remote daemon).
3. The browser is bound to the daemon's current auth token and behaves like a local one.

Pairing survives browser restarts but not daemon restarts (tokens are regenerated). Local origins (localhost, 127.0.0.1, the desktop app) never see the gate.

What a tunnel exposes — and what it never does

Through the tunnel, after pairing: the dashboard SPA, web chat, web terminal, previews, and the WebSocket endpoints — everything token-gated. Preview share links (/preview/s/<slug>) are the one deliberate exception: no pairing, no token, single preview, 10-minute expiry.

Never reachable through a tunnel: the local API bridge and agent-as-API endpoints (loopback-only), the MCP endpoint's local-bridge surface, and provider credentials in any form.

Remote CLI

The va CLI can target a remote daemon: va --base-url https://va.example.com --token <token> status, or save auth once via the pairing flow (va pair start --wait --save) and use va normally. --auth-file points at an alternate saved auth.

Troubleshooting

Source anchors: src/core/src/tunnels/ (providers: ngrok, localtunnel, cloudflare), src/core/src/config.rs (tunnel settings), src/core/src/auth/pair.rs (60 s codes), src/server/src/web_server/auth.rs (local-origin trust), src/core/src/previews/store.rs (share TTL), src/cli/src/ (pair/tunnel commands). Last verified: v0.7.11