Preview URLs

Last updated: 2026-09-21

A preview URL is a public https:// link to a dev server running on your paired Mac or in a cloud sandbox — your Next.js app, an API, a Storybook, anything listening locally. Open it on your phone, share it with a teammate, or point a webhook at it. The traffic tunnels straight to the device; nothing is exposed on your network and no ports are opened.

Preview privately on your phone#

Inside a project's Preview browser on iOS or Android, enter a local address such as localhost:3000 or web.localhost. RepoGo keeps that origin private to your phone and forwards it to the project's host over the encrypted device connection. This does not create a public URL; use a target below when you need a shareable link or webhook endpoint.

Browse your workspace#

Open the workspace's Browser tabs and tap + for a new tab. The start page includes bookmarks, history, tunnels, and detected dev-server ports. Tap a port to open it or manage a public URL under Tunnels.

Control the iOS preview through MCP#

For agents started from RepoGo on your iPhone or iPad, connect RepoGo's MCP server and enable it for the workspace. RepoGo automatically supplies that workspace and the device you started the turn from. Start a new turn after updating the host and servers so the agent receives the new connection configuration.

For an external desktop connector:

Connect an MCP client to https://repogo.app/api/mcp?workspace=<workspaceId>&client=<deviceId> using your RepoGo MCP connection credentials. workspaceId is the saved workspace's 64-character ID; deviceId selects your RepoGo iPhone or iPad. Keep the client pin in the URL so every call controls the same device. Coding agents can also supply the workspace through their connection's X-Repogo-Workspace header.

The browser tool lists, opens, reads, and interacts with tabs in that workspace. It cannot select a tab from another workspace. Snapshot screenshots arrive as images in MCP clients that support image results. Both desktop MCP clients and coding agents can use browser control on your account.

Add a target#

A target is what the URL points at. Tap Add Target on a device and enter either:

• A port — 3000, 8080. RepoGo routes to http://localhost:<port> on the device.
• A host — web.localhost, api.localhost:5000. RepoGo routes to that host on the device, forwarding the Host header so a local reverse proxy can pick the right service.

RepoGo assigns the target a public hostname and returns its URL immediately, for example:

https://macbook-3000-ab12.repogo.dev

Toggle a target off to take its URL offline without giving it up, and back on to restore it — the URL doesn't change.

Long press a target — in the environment's settings, on the browser start page's Tunnels section, or in the ports picker — for Edit, Copy URL, Share, and Delete. Editing changes what the target points at and keeps the same public URL; deleting gives the URL up. Android confirms a delete before it runs.

URLs persist across restarts#

When you add a target, its public hostname is stored against the device, not minted fresh each session. That means the URL is stable:

• It survives sandbox sleeps and wakes — a cloud sandbox that idles out keeps the same URL when it comes back.
• It survives Mac Host restarts and reconnects — quit and reopen the host, or move to a different network, and the same link keeps working once the device is back online.
• It survives environment.json restarts — services exposed automatically (see below) reuse their assigned URL every boot.

A target's URL only changes if you delete the target and add it again. So once you've shared a preview link, it stays good.

The link is live only while the device is online and the target's server is actually listening. If the device is asleep, RepoGo wakes it on demand; if the dev server isn't running yet, the URL returns an error until it comes up.

Run multiple services without port conflicts#

Host targets are the answer to "two apps both want port 3000." Instead of mapping ports, give each service its own hostname and route by host on the device:

Each gets its own stable preview URL, and there are no port collisions because the device routes on the Host header rather than a port number.

Hostnames instead of ports#

The preview gateway forwards the original Host header to your device unchanged — a request to https://…-web-….repogo.dev arrives on the device as web.localhost, and whatever serves that name locally handles it.

This matches the Vercel-style portless model (apps claim *.localhost names instead of fighting over :3000). Already running portless? Set the portless name as your target — web.localhost, api.localhost, or just web — and RepoGo handles the public forwarding for you. Each name gets its own stable preview URL; traffic tunnels to your device with the right Host header. No separate tunnel or port mapping per app.

You don't need portless for this to work — any stack that answers on hostnames (your framework's dev server, nginx, Caddy, a local proxy) is the same: pick the hostname as the target and RepoGo does the rest.

Expose services automatically#

You don't have to add targets by hand. In your repo's environment.json, mark a service expose: true and RepoGo creates its preview URL the first time it starts and reuses the same URL on every wake:

{
  "services": [
    { "name": "web", "cmd": "bun install && bun dev", "target": "web", "expose": true },
    { "name": "api", "cmd": "bun install && bun start", "target": "api", "expose": true }
  ]
}

A bare "target": "web" is shorthand for web.localhost. See Start Services Automatically for the full environment.json reference.

Where to manage targets#

• Per device — open a paired Mac or sandbox and use Add Target / the targets list to add, rename, toggle, or remove URLs.
• Per repo — declare exposed services in environment.json so they come up automatically wherever the repo runs.

Preview says “refused to connect”#

If a page opens in a separate browser but fails in an embedded web preview, check whether its X-Frame-Options or Content-Security-Policy frame-ancestors header blocks embedding. Allow https://repogo.app in your development configuration and restart the dev server. Keep your production restrictions in place.