Compose, extend, and observe every backend service in real time using three primitives: Workers, Functions, and Triggers.
iii is a backend runtime framework that collapses the integration story of queues, cron jobs, HTTP, state management, AI agents, and observability into a single live system surface. Instead of wiring each new capability to every other service through point-to-point integrations, iii lets you add a worker with one command and makes it instantly available to the entire system without configuration glue.
The framework is built around three primitives: Workers (processes that register capabilities), Functions (units of work with stable identifiers like content::classify or orders::validate), and Triggers (anything that causes a function to run — HTTP endpoints, cron schedules, queue subscriptions, state changes, stream events, or custom triggers you define). This mental model applies equally to TypeScript API services, Python data pipelines, Rust microservices, and Go workers.
iii’s engine is written in Rust using Tokio for async execution, with Axum serving the WebSocket-based protocol through which workers register their functions and receive invocations. SDKs are available for Node.js, Python, Rust, and Go, and the entire system is observable out of the box via OpenTelemetry — traces, metrics, and logs flow through the same runtime rather than requiring separate instrumentation per service.
The project is designed to be the foundation for both human developers and AI agents working in the same system: when a task needs a capability the system does not have, an agent can add a worker, discover its functions, call them, and trace what happened — using exactly the same interface a developer would use.
iii worker add CLI for installing pre-built capabilities into any projectiii worker add queue to get a managed queue with DLQ, retry logic, and fan-out without a separate Kafka or RabbitMQ deploymentArchitecture
iii is a modular, layered Rust monorepo organized around a central engine crate (engine/src/) that separates concerns across distinct modules: engine/ (the async WebSocket hub and function dispatch loop), workers/ (built-in capability providers — queue, cron, state, pubsub, stream, observability, HTTP, bridge, shell, and exec), invocation/ (HTTP invoker, auth resolution, and function call orchestration), protocol.rs (the WebSocket message type hierarchy shared between engine and SDKs), and trigger.rs/function.rs (the registry abstractions that decouple trigger sources from function handlers). Workers implement the Worker trait from workers/traits.rs, which provides a uniform interface for all built-in and external workers. The architecture is event-driven: functions register with the engine’s FunctionsRegistry, triggers register with the TriggerRegistry, and the engine routes invocations through an async dispatch path instrumented with OpenTelemetry. Adding a built-in subsystem requires implementing Worker and wiring adapters (state, queue, pubsub each expose pluggable adapter traits with in-memory and Redis backends). The engine binary also encompasses the CLI (worker scaffolding, project init, live reload) and an Axum-based REST API for the console and external callers.
Tech Stack
The engine runtime is written in Rust 2024 edition using Tokio for async I/O and Axum 0.8 for both the WebSocket worker protocol and the HTTP REST API. Distributed tracing uses the full OpenTelemetry stack — tracing, tracing-opentelemetry, opentelemetry_sdk, and opentelemetry-otlp with gRPC export. State and queue adapters optionally use Redis (redis crate with tokio-comp). Configuration is parsed from YAML via serde_yaml. The workspace includes four SDK packages: the Node.js SDK (iii-sdk on npm, TypeScript with tsdown build and vitest tests), Python SDK (iii-sdk on PyPI), Rust SDK (sdk/packages/rust/iii), and Go SDK (sdk/packages/go/iii). The developer console is a React + Rust application. Build tooling uses Turborepo (turbo.json) for polyglot orchestration, pnpm workspaces for Node.js packages, Biome for JS/TS linting, and the function-macros proc-macro crate for ergonomic engine-side function registration.
Code Quality
The engine has an extensive integration and end-to-end test suite under engine/tests/ covering queue concurrency and resilience, HTTP middleware chains, RBAC security, cron scheduling, pub/sub configuration, state streaming (including Redis-backed variants), DLQ redrive, external sandbox invocation, and CLI project initialization — over 30 distinct test files. SDKs have their own unit tests (Go’s client_test.go, protocol_test.go, channels_test.go; Node’s observability tests with Vitest). Error handling uses anyhow with thiserror for typed errors and tracing for structured logging throughout. Type safety is strong: Rust’s type system enforces the protocol message enum with serde(tag = 'type') exhaustive matching, and JSON schemas are generated via schemars for trigger and function configurations. Benchmarks (benches/) cover startup time, concurrent invocation throughput, HTTP loopback latency, and protocol serde performance.
What Makes It Unique
iii’s key differentiating concept is zero-integration composition: instead of each service needing to know about every other service’s API, queue topic, or config format, iii provides a shared runtime catalog where all workers discover each other automatically. The iii worker add command is genuinely novel — it installs a capability into a live running system and every other worker immediately gains the ability to call it, without restarts or configuration changes. The three-primitive model (Worker, Function, Trigger) deliberately unifies what would normally be four separate systems (a queue broker, a cron daemon, an HTTP router, and a state cache) under a single invocation and observability model. The bridge worker enables multi-engine federation without a service mesh. Most distinctively, agents and developers share exactly the same interface: an agent adding a new capability at runtime is mechanically identical to a developer running iii worker add.
The iii engine runtime is released under the Elastic License 2.0 (ELv2), a source-available license that permits internal self-hosting without restriction. The meaningful limitation is that you cannot offer the engine’s capabilities as a managed or hosted service to third parties — building a cloud product where your customers access the iii engine is prohibited under ELv2. All other components (SDKs for Node.js, Python, Rust, and Go; the CLI; the developer console; and documentation) are licensed under Apache 2.0, which carries no restrictions on use, modification, or distribution.
Running iii yourself means operating the engine binary on a Linux server. The binary has no mandatory external dependencies — Redis is optional and only required if you use distributed queue or state adapters instead of the in-memory defaults. This makes the baseline footprint modest: a single process replaces what would otherwise be a separate queue broker, cron daemon, state cache, and HTTP router. You are responsible for provisioning the host, managing optional Redis infrastructure for high-availability deployments, and keeping the binary current as the project ships releases frequently. No license key mechanism exists in the source code; all engine capabilities are available to self-hosters who comply with ELv2 terms.
There is no official hosted or managed version of iii available at the time of writing, so there is no cloud tier to benchmark self-hosting against. Compared to managed orchestration platforms such as Temporal Cloud or AWS EventBridge, self-hosting iii gives you a unified, observable runtime across all services without vendor lock-in, but you absorb full operational responsibility — uptime, capacity planning, upgrade coordination, and observability infrastructure. Given the project’s rapid release cadence (over 100 releases since launch), establishing a deliberate upgrade cadence and monitoring the changelog closely is advisable before putting iii into critical production paths.
No Code Platforms · AI Development · Developer Tools
Visual LLM workflow platform with RAG pipelines, agent capabilities, and model management for building production AI applications.
Developer Tools · Game Development · Design Tools
Free, MIT-licensed 2D and 3D game engine with one-click multi-platform export and no royalties.
Developer Tools · Databases · Search
The open-source Postgres development platform that replaces Firebase with authentication, real-time APIs, edge functions, storage, and vector embeddings — all built on PostgreSQL.