Documentation Core concepts

Channels and Relay

Permit an exact Cell generation to reach a named service endpoint through a bounded Channel.

Product guide · implementation in progress

On this page

Relay and Channels: scoped service communication

The canonical name is Cella Relay, with executable name cella-relay.

A Channel is a directional permission to communicate with a named service endpoint. It binds the caller, destination, generation, protocol, limits, and lifetime. Relay carries the traffic allowed by that Channel.

Example: one Agent Cell may call the backend-test HTTP endpoint implemented by a Service Cell. That grant does not expose every service port, the application's filesystem, its environment variables, or its credentials.

cellad authorizes and administers Channels. Relay carries the data, while provisioned endpoints bind traffic to the admitted identities. Expired or revoked Channels must stop working; an old grant cannot silently transfer to a new agent generation.

Relay is separate from Gateway: Relay carries governed service traffic; Gateway executes credentialed external operations. Relay has no provider credential authority and is not a general host or internet proxy.

Agent CellAuthorized ChannelCella RelayNamed service endpointService Cell
Data follows the exact Channel grant. Relay does not expose the service’s secrets or filesystem.

Further reading: Why Channels and Relay are separate.

What a Channel permits

A Channel names an exact caller and destination endpoint, not an entire machine. Its contract can constrain protocol, methods or messages, request and response bounds, resources, lifetime, and revocation. Endpoint identities are bound to the admitted generations; knowing an address is not authorization.

For example, the following is an illustration of the contract, not runnable configuration or the final API:

yaml
caller: agent-cell / generation-7
destination: backend-test / generation-3
endpoint: health-http
protocol: HTTP
scope: GET /health
lifetime: current authorized lease

That grant permits the health request and its bounded response. It does not permit a different service, another port, a service filesystem read, process inspection, secret access, or an arbitrary host or internet connection.

How a request crosses the boundary

  1. An agent requests access to a named Service through its admitted request path.
  2. cellad evaluates identity, current policy, endpoint scope, limits, and any required approval, then provisions an exact Channel grant.
  3. Relay carries traffic using the provisioned data-plane identities. The agent does not call Relay's control API or configure a route itself.
  4. Evidence records the authorization and the defined traffic observations, results, limits, and gaps without exposing secret values.
  5. Expiry, revocation, or generation replacement ends that grant. A replacement Run receives fresh authorization rather than inheriting the old lease.

Declared paths include Cell-to-Cell traffic, an explicitly enrolled local service, and local-client preview. A Connected Service remains externally owned; Channel mediation does not make its runtime a protected Service Cell. If Relay is unavailable, the governed service path fails closed while admitted local workspace work can continue.

Name Carries or represents Authority boundary
Channel Bounded live traffic to a named Service endpoint cellad authorizes; Relay carries the data
Connection A logical external provider identity and credential source Gateway resolves credentials and executes a typed Effect
Link Authenticated remote operator intent The target installation's cellad remains authoritative

“Cella Relayer” is an older informal name. Use Cella Relay and cella-relay in current documentation.

Source: docs/concepts/components.md · Current feature milestones