Documentation Index
Fetch the complete documentation index at: https://iii.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
What a Worker is
Workers are what actually do things in an iii system. Every category of capability is built as a
Worker: queues, scheduling, sandboxing, observability, agents, business logic, devices, and even
code executing in a browser.
Specifically, a Worker is a process that connects to the Engine over WebSocket and announces a set
of Functions it can run and Triggers to register. Once connected, those Functions are invocable from
anywhere in the system and those Triggers will respond to their events without per-pair integration
code between the caller and the Worker.
The Worker concept is intentionally narrow. A Worker is not a microservice, a job runner, or a
sidecar. It is a participant in the Engine’s live registry that contributes Functions and Triggers.
Whether the Worker is a long-lived process serving thousands of invocations per second or a
short-lived process that connects, registers, runs once, and shuts down, the Engine treats it the
same.
Worker isolation
Workers are intended and designed to be independent processes. One Worker crashing does not affect
others. The Engine connects to each Worker over a separate WebSocket and routes invocations only to
Workers that are currently connected. A crash, restart, or network partition affecting one Worker
does not propagate to the others. The crashed Worker’s Functions and Triggers drop out of the
routing table on disconnect, and every other Worker keeps serving.
