Managed Tunnels for Local Services
Publish a service running on any agent's machine at a managed URL, decide who can reach it and watch its traffic live.
These images are illustrations of the concept, not screenshots of the actual product.
Overview
Managed tunnels are the VibeControls concept for sharing a service that runs on one of your own machines without opening firewall ports or hand-rolling port forwards. A dev server on a laptop, an API on a staging VM or a database on a GPU box can be published through a tunnel that the agent on that machine maintains, with a stable URL, a visibility setting and a record of how it is used.
Developers routinely need to show a preview to a reviewer, point an external callback at a local build or let a teammate query a database that lives on a private network. The usual answers are tunnel tools started in a spare terminal, forgotten SSH forwards and URLs pasted into chat. The concept brings those tunnels into the workspace, so they are listed in one place, tied to the agent and project that own them, and can be stopped as easily as they were started.
The illustrated experience moves through three screens. The tunnels list shows every tunnel as a card with its status, provider, public URL, protocol and port, the address it forwards to, its visibility and the data it has carried, with Open, Stop or Start and delete actions on each card. A five-step creation wizard walks through provider, protocol and target, hostname, policies and a final review, and saves the tunnel as a draft that mints its public URL only when it is started. The detail page for a database tunnel shows its configuration, a copyable connection string and an activity panel with data transferred, latency, request rate and error rate.
Tunnels sit in the Infrastructure section next to the sandbox and are designed to connect with the rest of the product. Each tunnel is served by a registered agent, can be linked to a vibe so its visibility follows the project, and carries its own sessions, usage and audit tabs. Exposing a local service becomes an accountable, reversible operation rather than a side effect nobody remembers to clean up.
What this concept shows
- Tunnel cards with active, degraded, idle and offline status badges
- Provider badges for the built-in tunnel service and third-party tunnel providers, with provider and status filters
- Protocol, port, forwarded address, visibility (private, public or internal) and data transferred for every tunnel
- Inline Open, Stop, Start and delete actions on each tunnel
- Five-step creation wizard covering provider, protocol and target, hostname, policies and review
- Draft-first creation that mints the public URL only when the tunnel is started
- Workspace visibility linked to a vibe, optional basic auth and tags
- Detail page with configuration, a copyable connection string and live data, latency, request rate and error rate tiles
How it works
- Open Tunnels under Infrastructure and filter the list by provider or status to find the tunnel you need.
- Choose New tunnel and pick a provider in the first step of the wizard.
- Select the protocol, the agent and the local target address and port, then choose a hostname.
- Set policies such as visibility, basic auth and tags, and confirm every setting on the review step before creating the tunnel as a draft.
- Start the tunnel from the list to mint its public URL, then use Open to try it.
- Open the tunnel's detail page to copy the connection string and watch sessions, data transferred, latency and error rate.
Who it's for
- Full-stack developers sharing previews of local work
- Backend and data engineers who need to reach services on private machines
- Platform engineers who govern what a workspace exposes publicly
- Freelancers and consultants demoing work to clients
Illustrations
3 illustrations of this concept. Select one to view it full size.
Tunnels List with Status and Traffic
This illustration shows the Tunnels page in the Infrastructure section of the application shell. Tabs across the top switch between Tunnels, Domains, Sessions, Usage, Audit and Providers, and a New tunnel button sits beside the page title, which explains that local services can be exposed on a managed tunnel domain or on custom domains. A search field filters tunnels by name or slug, with dropdowns for provider and status. Each tunnel is a card showing its name, a status badge (active, offline, degraded or idle), a provider badge, the public URL, and the protocol and port with the address it forwards to and its visibility: private, public or internal. On the right, each card shows the volume of data transferred, an Open button, a Stop or Start button depending on its state, and a delete icon. Tunnel names, addresses and volumes are sample data.
Create Tunnel Wizard, Review Step
This illustration shows the create tunnel flow, reached from Infrastructure, Tunnels and New tunnel, with the subtitle explaining that it exposes a local service through a managed tunnel. A stepper marks five stages: Provider, Protocol and target, Hostname, Policies and Review, with the first four checked off and Review in progress. The review card lists the chosen provider, the tunnel name, the agent that will serve it, the protocol, the local target address and port, the requested hostname, the visibility (here scoped to the workspace and linked to a vibe) and whether basic auth is on. Tags for frontend and preview appear below. A notice explains that the tunnel is created as a draft and that starting it mints the public URL, which is shown in advance. Back and Create tunnel buttons finish the step. The agent, hostname and tags are sample data.
Database Tunnel Detail with Live Activity
This illustration shows the detail page for a TCP tunnel that exposes a read-only database on a private network. A back link returns to the tunnel list. The header shows the tunnel name, its protocol, port and local address, tags for database and read-only, and a Stop tunnel button, active and provider badges and a Share button. Tabs cover Overview, Endpoints, Sessions, Domains, Usage, CLI, Audit and Settings. On the Overview tab, a Configuration card lists the slug, provider, protocol, a passthrough TLS mode, the local target and basic auth. A Connection card holds a copyable database connection string and a hint to point a desktop database client at it. The Activity panel lists active sessions, attached domains, the primary hostname, the serving agent and the creation date, with tiles for data transferred in the last 24 hours, average latency, request rate and error rate. All values are sample data.
Topics
- localhost tunnel
- expose local service
- managed tunnels for developers
- port forwarding dashboard
- share local dev server
- database tunnel connection string
- public preview URL
- private and public tunnels
- tunnel traffic monitoring
- secure tunnel manager
Related concepts
Targets and Agent Mesh Topology
Register the machines your agents can reach over SSH or directly, and see the agent-to-agent mesh as an interactive graph.
3 illustrations
Project Workspaces and Notes
Vibes tie a piece of work to its repo branch, folder, bound agents, environment variables and notes, so context travels with it.
3 illustrations
Sandboxed Script Runner
Try scripts written by coding agents in a short-lived, resource-capped sandbox and review the result before it touches a real machine.
1 illustration
Usage Analytics and Audit Trail
Count what the fleet did over any period, then drill into a searchable record of who did what, where and with what result.
2 illustrations