Lifecycle
- The worker starts in Node.js, Python, Rust, or the browser.
- The SDK connects to the engine WebSocket endpoint.
- The worker registers functions, trigger types, triggers, and optional service metadata.
- The engine routes matching invocations to that worker.
- The SDK sends results or errors back over the same connection.
SDKs
External workers can run locally, in containers, on separate hosts, or in browser tabs. They only need network access to the engine WebSocket endpoint.
A Worker is any process that connects to the iii Engine over WebSocket using an SDK and registers Functions. The Engine routes incoming triggers to the correct Worker, which executes the handler and optionally returns a result.
Workers are independent processes — they can be written in any language, run anywhere, and crash without affecting other Workers.
Diagrams
Architecture
Lifecycle Overview
Creating a Worker
A Worker is simply any collection of registered Functions and Triggers that has registered itself with the iii engine. See How to use Functions and Triggers for details on registering functions within workers. Read below for Worker responsibilities and configuration.What Workers Do
Init Options
The second argument toregisterWorker() configures the Worker’s behavior:
Reconnection Config
Workers reconnect automatically on disconnect using exponential backoff:Python naming: Python uses snake_case for these fields:initial_delay_ms,max_delay_ms,backoff_multiplier,jitter_factor,max_retries.
Worker Lifecycle
When a Worker connects, the SDK sends its metadata to the Engine viaengine::workers::register:
worker_id and the Worker’s status transitions through:
Worker Metadata
You can inspect all connected Workers at runtime:For details on building and deploying Workers in production, see the Quickstart tutorial or the SDK Reference.