Iii

Iii

iii is an open-source distributed runtime that runs every function, service, and AI agent as a worker over one shared protocol.

71/100Safe BetFreeFree

If your team keeps paying the integration tax on every new capability, iii is worth a weekend of evaluation. The worker registry plus one shared WebSocket protocol is a genuinely different answer to microservice sprawl than Temporal or Dapr, and the agent story is coherent: an agent is a worker, so there is no separate harness to operate. It is early, pre-1.0 software you host yourself — treat it as infrastructure you own, not a service you buy.

Verified 3d ago · liveness 71/100 · cite: rightaichoice.com/tools/iii

Best for
  • Backend engineers tired of wiring queues, cron, streams, and caches into every new service
  • Polyglot teams running TypeScript, Rust, and Python services that need native cross-language calls
  • Agent builders who want agents to be workers on the same runtime instead of a separate harness
  • Platform teams shipping internal capabilities as installable workers from the registry
Not ideal for
  • Teams that need a managed cloud platform rather than a self-hosted runtime
  • Buyers who want GUI configuration or no-code integration flows
  • Alpine Linux shops — the musl build's glibc-only worker install path does not cover Alpine
Visit Website

IntermediateBackend engineers with systems experience should reach first value quickly: install the engine via the shell installer, follow the Quickstart, and a Node.js orchestrator calling a Rust transform and a Python predict function is the documented starter path. Platform teams publishing their first installable worker should budget an afternoon. Agent builders need longer, because wiring an agent as aCLIAPI availableVerified 3d ago
Pricing
Free
FreeFree tier6 hidden costs
Learning curve
Intermediate
Backend engineers with systems experience should reach first value quickly: install the engine via the shell installer, follow the Quickstart, and a Node.js orchestrator calling a Rust transform and a Python predict function is the documented starter path. Platform teams publishing their first installable worker should budget an afternoon. Agent builders need longer, because wiring an agent as a
Runs on
CLI
API available
Who it's for
Backend engineer replacing a queue-plus-worker stackPlatform engineer publishing internal capabilitiesAgent builder whose harness keeps hitting capability gaps
Live sentiment
Is Iii actually worth it?

We scan live Reddit threads, YouTube comments, X posts, G2 reviews and other communities — and hand you an honest verdict in under a minute.

  • Honest verdict, not marketing
  • Real pros & cons from real users
  • Attributed quotes with receipts
Run a free scan

3 free scans · no card needed

Skip it if

Skip iii if you need a managed control plane you don't operate, want no-code GUI configuration, or run a single language across a single service where a runtime adds no leverage.

The 30-second take
Biggest gripe

There is no hosted plan, so the compute, storage, networking, and Kubernetes or Docker hosting bill for running the engine yourself is entirely yours to carry.

Price reality

iii is free and open source: the vendor publishes $0/mo for the full engine, polyglot SDKs, the one-command worker registry, the unified console, durable state with retries and dead-letter handling, and self-hosted deployment to Docker, Kubernetes, edge, browser, Raspberry Pi, or microVM. Your real cost is the infrastructure and engineering time to run it. Against Temporal or Dapr the comparison is not license spend but how much integration and operational scaffolding each one makes you build.

In short

Iii — iii is an open-source distributed runtime that runs every function, service, and AI agent as a worker over one shared protocol. Best for Backend engineers tired of wiring queues, cron, streams, and caches into every new service, Polyglot teams running TypeScript, Rust, and Python services that need native cross-language calls, Agent builders who want agents to be workers on the same runtime instead of a separate harness. Free to use.

What's new in Iii

Checked 3 days ago

Across the latest 8 updates: 4 changelog entries and 4 news mentions.

ChangelogChangelog·17 days agoNewest

Compose panel gains per-worker progress and version reporting

Compose now shows worker states (unchanged, in-progress, completed, failed) plus running versions, ignores empty env_file values with grouped warnings, and no longer passes stored null configuration to workers.

ChangelogChangelog·17 days agoNewest

iii SDKs add 16 MiB outbound / 64 MiB inbound message size limits

Rust, Node, Python and Go SDKs reject oversized JSON messages with payload_too_large rather than closing the connection. Engine limits unchanged.

ChangelogChangelog·17 days agoNewest

iii rejects worker registrations outside session namespace scope

Workers declaring a namespace their auth session forbids now get RegistrationRejected with NAMESPACE_FORBIDDEN and a closed connection instead of silently falling back to default. Node, Python, Rust and Go treat it as fatal.

ChangelogChangelog·17 days agoNewest

iii 0.24.5: Namespace routing changes across SDKs

SDK calls to configuration::* now resolve in the default namespace like engine::* across Node, browser, Python, Rust and Go. Go workers outside default relying on implicit resolution must now name default explicitly.

NewsBlog·Aug 5

Is Your Business Ready for the EU's Lawyers?

iii team post on EU compliance obligations for businesses, filed under the compliance category.

NewsBlog·Jul 30

The Four Loops, Clearly Explained

Architecture post from the iii team explaining the four loops pattern.

NewsBlog·Jul 29

Loop Engineering Is a Pattern, Not a Feature

iii team argues loop engineering is an architectural pattern rather than a product feature.

NewsBlog·Jul 21

Loops, Graphs, and the Layer That Matters

Architecture post from the iii team on loops, graphs, and layering.

What people actually say about Iii — is it worth it?

We ran a structured research pass across product reviews, community discussions, and post-purchase forum threads to surface the patterns vendors won't publish themselves. Below: the recurring strengths, the hidden costs people mention most, and the cohort that consistently regrets adopting this tool.

63 mentions across 4 sources (Reddit, Hacker News, App Store, Lemmy) · researched Jul 3, 2026.

Recurring strengths
  • +Open-source and free to use, reducing financial risk.
  • +Unified three-primitives model simplifies complex service composition.
  • +Polyglot support for Node.js, Rust, Python, Go, and more.
  • +One-command worker installation mirrors npm package simplicity.
  • +Built-in agent support for AI workflows without extra harnesses.
Recurring frustrations
  • −No community feedback to confirm any feature works as advertised.
  • −Zero adoption signals — may be vaporware or unmaintained.
  • −Version 0.20.x indicates alpha-stage instability.
  • −No paid support tiers for enterprise reliability needs.
  • −Lack of documentation or examples beyond marketing claims.
Patterns worth knowing
No relevant feedback on Iii itself
Seen on Hacker News, App Store, Lemmy
All community mentions of 'III' are unrelated
Seen on Hacker News, App Store, Lemmy
Potential for confusion with other products named III
Seen on Hacker News, App Store
Learning curve
intermediateProductive in ~A few hours
Hidden costs people mention
  • • Infrastructure costs for hosting workers

Viability Score

71/100
Safe Bet

How well maintained and how widely used is Iii? Built from what the vendor actually publishes (docs, changelog, tutorials, integrations, pricing), whether the site is live, and how much real users discuss it. How we calculate this

Recent activity
90
Traction
100
Site health
95
User sentiment
not measured
What the vendor publishes
20

Last calculated: October 2026

How we score →

Key Features

  • Three primitives: Function, Trigger, and Worker
  • Worker registry with one-command capability install via compose::add
  • Workers declared in a Compose file and immediately callable system-wide
  • Polyglot SDKs for TypeScript, Python, and Rust
  • Cross-language function calls over a shared WebSocket protocol (ws://localhost:49134)
  • Engine handles serialization and routing between workers
  • Durable state, retries, and dead-letter handling built into the engine
  • compose::update resolves selected workers and shared dependencies as one graph (0.24.5+)
  • Unified console showing live logs, traces, streams, and state
  • Trace query pagination via root-span keys, 2098ms to 35ms on a 50-trace query (0.24.4)
  • Spans accept include_events: false for leaner trace responses (0.24.4)
  • Static musl build installs glibc-only Linux workers on Alpine-adjacent hosts (0.24.5+)
  • Agents run as workers — functions as tools, state as session memory, triggers as orchestration
  • Agents can register new workers at runtime and expose new functions
  • Self-hosted on a laptop, your own cloud, or your hardware with the same worker contract

About Iii

FreeIntermediateAPI availableCLI

iii is a self-hosted runtime for building distributed backends and agentic systems out of three primitives: Function, Trigger, and Worker. Something hosts work, something causes it, something does it. Rather than assembling a queue, a cron scheduler, a stream processor, a cache, and an observability stack and gluing them together, you add a worker — `compose::add` pulls a declared capability into the running system and makes it immediately callable by every other worker. Workers register over a shared WebSocket protocol (ws://localhost:49134). The vendor's own demos show a TypeScript orchestrator calling a Rust function and a Python function, with results returning over the same connection. TypeScript, Python, and Rust are the SDK languages the site currently lists, so services in different languages call each other natively instead of through sidecars or bridges, and the engine handles serialization and routing underneath. The same worker contract applies whether a workload runs in Docker, on Kubernetes, on the edge, on a laptop, or on your own cloud hardware — moving a workload is a redeploy, not a rewrite. Agents get treated as workers too, which is the part worth attention. Their tools are functions, their session context is state, their orchestration is triggers, and the vendor's demo wires a github worker plus an llm-router plus a provider worker into a PR-digest agent without leaving the runtime. An agent that hits a task outside its current capabilities can register a new worker at runtime and expose new functions. Recent releases push on durability and debugging: iii 0.24.4 cut a 50-trace query from 2098ms to 35ms in vendor benchmarks by paginating unfiltered traces via root-span keys, added `include_events: false` for leaner spans, and 0.24.6 is the version on the install page today. It suits backend engineers, platform teams, and agent builders who are finished procuring a separate service for every new requirement, and polyglot teams running

Behind the Verdict

The reason to look at iii is not the agent framing; plenty of projects claim that. It is the worker registry and `compose::add`. Declaring a capability in worker-compose.yaml and having it instantly callable by every other worker is the mechanic that removes the procurement step, and we have not seen another open-source runtime make that quite so cheap. Pick this when you are already running more than one language in production. The TypeScript-to-Rust-to-Python call path in the vendor's demo is the honest test of whether you need this: if your services already talk over HTTP and nobody minds, you probably don't. If you are maintaining sidecars, hand-rolled RPC clients, and a separate scheduler to keep three languages in sync, the shared protocol is a real simplification. Pick it also if you want agents on the same runtime as your services. Tools as functions and session context as state means an agent is not a second system to operate — and the runtime-registration trick, where an agent adds a worker mid-run to gain a capability, is genuinely useful for internal platform work. Pass if you need a managed control plane. iii is installed via a shell script and runs on infrastructure you control; there is no vendor-hosted version to hand the pager to. Pass too if you want GUI configuration or no-code integration flows — this is a Compose file and an SDK, not a canvas. Watch out for the pre-1.0 upgrade cost. The changelog over the last quarter is exactly the shape you'd expect from fast-moving infrastructure: a static musl build that can install glibc-only Linux workers (Alpine still unsupported), and a fix so `compose::update` plans selected workers and their shared dependencies as one graph instead of tripping over conflicting declarations for state or llm-router.

Researching Iii? Get your full AI stack in 60 seconds.

Free, no signup — tell us your goal and get tools matched to your budget & existing stack.

Real-world workflow fit

Concrete scenarios for the personas Iii actually fits — and what changes day-one when you adopt it.

Backend engineer replacing a queue-plus-worker stack

You install the engine, register a Node.js orchestrator over ws://localhost:49134, and add a worker that handles retries and dead-letter logic instead of standing up a message queue. Your Rust data::transform worker and Python ml::predict worker register their functions on the same connection, so the orchestrator calls them like local code.

Outcome: One connection and one set of primitives replaces the queue, the bridge code between services, and the retry logic you would otherwise maintain per service.

Platform engineer publishing internal capabilities

You declare a queue worker, a classifier worker, and a CRM integration as workers recorded in worker-compose.yaml. Application teams register functions and declare triggers on their side; both sides fulfill the same contract, so no bespoke SDK or per-service API contract is written.

Outcome: A capability ships once and every other worker in the system can discover and call it, which removes the coordination work that used to live between platform and application teams.

Agent builder whose harness keeps hitting capability gaps

Your agent runs as a worker on the same runtime as the rest of the system, with functions as tools, state as memory, and triggers as orchestration. When it hits a task outside its current capabilities, it registers a worker at runtime and exposes new functions.

Outcome: The agent extends the system it operates inside instead of waiting on a human to add an integration to a separate harness.

Use Cases

Limitations

  • iii is pre-1.0 software (evidence shows 0.24.6 / 0.24.x) and may ship breaking changes between minor versions, including compose::update changing how it plans shared dependency graphs and 0.24.4 rewriting trace pagination.
  • The engine is self-hosted only — you install it yourself via the shell installer (install.iii.dev) and own upgrades.
  • Agent-support features are new and the worker ecosystem is early.
  • On Linux x86_64 with glibc, iii's static musl build installs workers published only as glibc builds, and Alpine is unsupported.

as of 2026-10-08

Verification history

We have re-verified Iii 8 times since . Each pass re-reads the vendor's own pages and re-checks every listed field against that evidence; passes where nothing had changed are marked as such.

  1. — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
  2. — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
  3. — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
  4. — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
  5. — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
  6. — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it

Showing the 6 most recent of 8 verification passes.

Free to cite with attribution — this page re-verifies continuously.

12-month cost

Project the real annual outlay, including the implied monthly cost when only an annual tier is published.

Annual total
Free
Over 12 months
Effective monthly
Free
Billed monthly

Vendor list price only. Add-on usage, seat overages, and contract minimums are surfaced under Hidden costs & gotchas.

Plans compared

For each published Iii tier: who it actually fits, and what it adds vs. the previous tier. Cross-reference the cost calculator above for projected annual outlay.

Open Source

$0/mo

Ideal for

Backend engineers, platform teams, and agent builders who are willing to self-host and want the full engine without a license fee.

What this tier adds

Starting tier and the only published tier: $0/mo, covering the full engine, polyglot SDKs, worker registry, unified console, durable state with retries, and self-hosted deployment.

Hidden costs & gotchas

What the public pricing page doesn't put in bold. Captured from pricing-page footnotes, contract terms, and recurring complaints.

  • There is no hosted plan, so the compute, storage, networking, and Kubernetes or Docker hosting bill for running the engine yourself is entirely yours to carry.
  • Because iii is pre-1.0, minor-version upgrades can require code changes — the cost lands as engineering hours, e.g. updating workers after config_override moved to configuration::get and III_CONFIG was retired.
  • Running workers in a browser tab, on a Raspberry Pi, or inside a microVM is a redeploy rather than a rewrite, but each additional target still needs its own build and deployment pipeline work.
  • The shared WebSocket protocol is your control plane, so broker resilience, connection limits, and reconnect handling become production concerns you staff for rather than features you buy.
  • Alpine Linux is unsupported, so teams standardized on Alpine images need to switch base images or run the static musl build and rely on it installing glibc-only workers.
  • Integration and agent-harness token efficiency improves by keeping the agent on the same runtime, but that only pays off after you have actually migrated the surrounding services onto iii.

Where the pricing makes sense

The company stage and team size where Iii's pricing actually pencils out — and where peers do it cheaper.

iii is free and open source: the vendor publishes $0/mo for the full engine, polyglot SDKs, the one-command worker registry, the unified console, durable state with retries and dead-letter handling, and self-hosted deployment to Docker, Kubernetes, edge, browser, Raspberry Pi, or microVM. Your real cost is the infrastructure and engineering time to run it. Against Temporal or Dapr the comparison is not license spend but how much integration and operational scaffolding each one makes you build.

Setup time & first value

How long it actually takes to get something useful out of Iii — broken out by persona, not the marketing-page minute.

Backend engineers with systems experience should reach first value quickly: install the engine via the shell installer, follow the Quickstart, and a Node.js orchestrator calling a Rust transform and a Python predict function is the documented starter path. Platform teams publishing their first installable worker should budget an afternoon. Agent builders need longer, because wiring an agent as a

Switching to or from Iii

How to bring data in from common predecessors and how to get it back out — written for the switcher, not the buyer.

Migrating in
  • →From a hand-rolled queue plus worker setup: replace the queue with a worker that handles retries and dead-letter logic on the shared runtime.
  • →From Temporal or Dapr: move orchestration onto the one shared WebSocket protocol and the worker registry, where capabilities install as workers rather than as separately configured services.
  • →From sidecar or bridge wiring between Node.js, Rust, and Python services: register each service as a worker and call its functions directly over the shared connection.
  • →From a separate agent harness: run the agent as a worker on the same runtime so its tools are functions, its memory is state, and its orchestration is triggers.
Migrating out
  • ↗To a managed cloud platform: iii has no hosted plan, so leaving means standing up a managed queue, scheduler, and stream processor and rewriting the glue iii was handling.
  • ↗To Temporal or Dapr: re-express worker-registered functions and triggers as that platform's workflow and service-invocation contracts.
  • ↗To a single-language framework: collapse the polyglot workers into one runtime and replace the shared-socket discovery with in-process calls.
  • ↗To a no-code integration platform: rebuild capability wiring as GUI-configured flows, giving up the code-level worker contract.

Resources & Guides

Tutorials & Learning

YouTube returned 6 videos for “Iii”, and we withheld 6: 6 could not be judged, because “Iii” is a single word that other videos use for other things. We are showing none, because we could not prove any of them are about Iii.

Tools that pair well with Iii

Common stack mates teams adopt alongside Iii, with the specific reason each pairing earns its keep.

Featured Head-to-Head Comparisons

Alternatives to Iii

View all
Avibe

Avibe

Local-first Agent OS that runs official Claude Code, Codex, and OpenCode CLIs behind one shared Workbench, Harness, and run graph.

FreemiumTry
Nubase

Nubase

Open-source, self-hosted backend that lets AI coding agents ship full-stack apps from chat

FreeTry
Trigger.dev

Trigger.dev

Open-source TypeScript platform for durable AI agents and background jobs that survive redeploys and crashes.

FreemiumTry

Frequently Asked Questions

Used Iii? Help shape our editorial sentiment research.