Skip to main content
Workers are the interface between the Engine and the rest of the application. They are responsible for establishing connections to services, implementing trigger types, and supplying application Context. Every capability in iii (HTTP endpoints, cron scheduling, state management, queues, streams, observability) is implemented as a Worker. This modular architecture means the Engine itself stays small and focused on orchestration, while Workers handle all external concerns.

​
Built-in Workers

WorkerProvidesConfig key
HTTPHTTP trigger type, request/response handlingrest_api
QueueAsync message processing with retriesqueue
CronScheduled task executioncron
StateKey-value state storage with atomic updatesstate
StreamReal-time data streams with WebSocket pushstream
PubSubPublish/subscribe messagingpubsub
ObservabilityStructured logging, tracing, and metricsobservability
ExecShell command executionexec
BridgeWebSocket bridge for SDK connectionsbridge

​
How Workers Work

A Worker has two responsibilities:
  1. Register trigger types: A Worker can introduce new ways to invoke Functions. For example, the HTTP worker registers the http trigger type, and the Cron worker registers the cron trigger type.
  2. Supply Context: A Worker can add capabilities to the Context object that gets passed to every Function. For example, the State worker adds state::get, state::set, and other state operations.
Workers are configured in config.yaml (the engine default). Use -c iii-config.yaml to specify a custom path: 
workers:
  - name: iii-http
    config:
      port: 3111
      host: 0.0.0.0
  - name: iii-state
    config:
      adapter:
        name: kv
        config:
          store_method: in_memory
  - name: iii-queue
    config:
      adapter:
        name: builtin
        config:
          store_method: in_memory
You can build your own Workers to integrate any service or infrastructure. See Custom Workers for a detailed guide.