Skip to main content

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.

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 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

  • 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.