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. Last modified on June 9, 2026
