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

# Transport

> How data flows in and out of cyrnel

Cyrnel has two distinct transport layers: the **external** API that clients use,
and the **internal** channel between the runtime and its modules.

## External Transport

The cyrnel server exposes a JSON-over-HTTP REST API. Clients use it to interact
with processes, modules and services.

## Internal Transport

### Process service ⇄ environment

The active environment module is invoked through the in-process
`EnvironmentModule` interface (no IPC). Each `ProcessService.create` allocates
a `pid`, which is also the **execution id** (`eid`) handed to the environment.
The environment streams events back through the same in-process
`EnvironmentBindings` callbacks (`setState`, `emitStdout`, `emitStderr`,
`emitOutput`, `setError`).

### Environment ⇄ user code

The bundled environment compiles / transpiles and runs user code. Code runs in
a fresh context per execution with **as much restriction as possible**. The
only way out of the environment is through references explicitly installed for
cyrnel.

### Environment ⇄ adapter

When user code calls an invoke, the call returns to the host as a reference
invocation, which the `ModuleService` resolves to the correct adapter and
forwards as `adapter.invoke({ serviceId, toolId, parameters })`.

### Adapter ⇄ end service

Adapters speak whatever protocol the end service speaks. The bundled
`openapi` adapter speaks HTTP based on the OpenAPI document supplied at
install time. Custom adapters are free to dial gRPC, message queues,
databases, hardware interfaces, etc.