> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cyberun.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Gateway and tunnels

> How Cyberun agents connect, how tasks reach them, and how proxied services work.

The **agent gateway** is the WebSocket surface every Cyberun agent
connects to. Agents dial out to the gateway from wherever they
are; once connected, they hold the connection open and accept
tasks from it. There is no inbound listener on the agent host —
the gateway never initiates the connection.

This page describes the surface from the operator's point of view.
End-user product flows live in the [Cloud](/cloud/overview) tab.

## What the gateway does

* **Accepts agents.** Agents present an agent credential (`ak-`)
  when they connect. The gateway validates the credential, looks
  up the team, and registers the agent in the team's pool.
* **Dispatches tasks.** When Cyberun Cloud accepts a task, the
  gateway picks an eligible agent in the team's pool and hands
  the task off to it.
* **Streams progress.** Status, partial outputs, and final
  artifacts flow from the agent through the gateway back to the
  client that submitted the task.
* **Proxies services.** When a task asks the agent to expose a
  service — a ComfyUI UI, a container service running on the
  agent — the gateway proxies HTTPS requests for that service
  through the same outbound connection. The operator does not
  publish a separate port on the agent host.

## What agents need on the network

```mermaid theme={null}
flowchart LR
    Agent["Cyberun agent<br/>(your GPU host)"]
    Gateway["Cyberun gateway<br/>(your deployment)"]
    Cloud["Cyberun Cloud API"]
    Browser["Browser / API client"]

    Agent -- outbound WebSocket --> Gateway
    Browser -- HTTPS --> Cloud
    Cloud -- task dispatch --> Gateway
    Gateway -- proxy --> Agent
```

* An outbound HTTPS connection from the agent host to the gateway
  URL configured for the deployment. The Cyberun-managed service
  publishes a single gateway URL; self-hosted deployments choose
  their own.
* No inbound exposure on the agent host. Firewalls that block
  inbound connections are fine.
* No persistent agent-to-agent path. Agents do not need to reach
  each other.

In multi-site deployments, more than one gateway may run. An agent
connects to whichever gateway is closest; the rest of the platform
sees a uniform pool.

## Tunneled services

A workflow can ask the agent to expose a service while a task is
running — most commonly the ComfyUI web UI, so a user can interact
with it. The flow looks like this:

1. The agent starts the service on a local port.
2. The gateway opens a tunnel to that port through the existing
   outbound connection.
3. A browser request to a deployment URL is routed through Cloud
   to the gateway, then through the tunnel to the service.
4. When the task ends (or the user closes the tab), the tunnel
   closes.

From the user's point of view, the service appears as a regular
URL served by the deployment. From the operator's point of view,
the agent never opened a port that the outside world could see.

The same model handles container services — long-running
containers an agent hosts and the gateway addresses by name. The
contract is similar; details belong in the runbooks shared with
operating partners.

## What is not on this page

* The fragment-level protocol the gateway and agent speak inside
  the WebSocket connection.
* Internal RPCs between platform components (server-to-gateway,
  gateway-to-gateway).
* Tuning knobs, timeouts, and retry budgets.

These are partner-channel materials. For the public HTTP surface
that clients and integrations use, see the
[API reference](/api-reference/introduction).