iii binary and the iii worker and iii console runtimes it dispatches to. Running iii with no subcommand starts the engine. The same information is available from the binaries themselves via iii --help and iii <subcommand> --help. For a guided overview, see CLI.
iii
Process communication engine
Subcommands:
iii project
Manage iii projects (init, generate-docker)
iii project generate-docker
Generate Docker assets (Dockerfile, docker-compose.yml, .env) for an existing iii project
iii project init
Initialize a new iii project in the current directory
iii trigger
Invoke a function on a running iii engine
iii trigger <function> --help additionally queries a running engine for the function’s description and request schema. That output depends on which workers are registered and is not part of this page; see Creating Workers / Functions.iii update
Update iii and managed binaries to their latest versions
iii worker
iii managed worker runtime
The iii binary dispatches iii worker ... to the separately installed iii-worker runtime; this section documents that runtime’s full tree.
iii worker add
Install a worker from the iii registry, a path to a local worker directory (ex. ./myWorker with a iii.worker.yaml file within it) or by OCI image reference. To create a NEW worker from scratch, use iii worker init. By default add waits up to 120s for the worker to report ready. After which the worker will continue to boot but the command will return to the shell. See iii worker status to continue observing a booting worker and iii worker logs for logs
iii worker clear
Clear downloaded worker artifacts from ~/.iii/ (local-only, no engine connection needed). Does not affect a worker’s own build artifacts or dependencies (e.g. node_modules, Cargo.lock)
iii worker exec
Run a command inside a running worker’s VM. Pipes stdin/stdout/ stderr through and returns the child’s exit code. Pass -t for an interactive PTY
iii worker init
Scaffold a NEW standalone worker repo from scratch. To install an EXISTING worker, use iii worker add
iii worker list
List all workers and their status
iii worker logs
Show logs from a managed worker container
iii worker reinstall
Re-download a worker (equivalent to add --force; pass --reset-config to also reset its config.yaml entry to registry defaults)
iii worker remove
Remove one or more workers from config.yaml. The engine’s file watcher tears down any running sandbox. Artifacts under ~/.iii/managed/{name}/ remain; use iii worker clear {name} to delete them
iii worker restart
Restart a managed worker: stop if running, then start. By default waits up to 120s for the worker to report ready (same as start)
iii worker sandbox
Manage ephemeral sandboxes (create/exec/stop short-lived VMs)
iii worker sandbox create
Create a long-lived sandbox and print its id to stdout. Pair with iii worker sandbox exec <id> and iii worker sandbox stop <id>.
Pipe-friendly: the sandbox id is the only thing on stdout, so you can do SB=$(iii worker sandbox create python) in a shell.
iii worker sandbox download
Copy a file out of a running sandbox to a local path.
Streams bytes through an iii data channel. Writes to LOCAL_PATH on disk (or stdout when LOCAL_PATH is -).
Examples: iii worker sandbox download <SB> /workspace/output.json ./output.json iii worker sandbox download <SB> /workspace/build.tar - | tar -tf -
iii worker sandbox exec
Run a command inside an already-running sandbox.
Pipe-mode only. Pair with iii worker sandbox create for the sandbox id. For interactive TTY sessions, use iii worker exec against a managed worker instead.
iii worker sandbox list
List every sandbox the daemon knows about.
The daemon’s list RPC is owner-scoped for multi-tenant SDK callers, but iii worker sandbox is a local admin tool with no authenticated identity, so the CLI always requests the unscoped view. The --all flag is a silent no-op, kept so scripts that pass it from earlier releases keep working.
iii worker sandbox run
Create a one-shot sandbox, run a command inside it, and stop it. For multi-step workflows (agent loops, REPLs) use create + exec + stop instead
iii worker sandbox stop
Stop a sandbox by id, waiting for the reaper to finish
iii worker sandbox upload
Copy a local file into a running sandbox.
Streams bytes through an iii data channel; no JSON-envelope size cap. Reads LOCAL_PATH from disk (or stdin when LOCAL_PATH is -) and writes atomically (temp file + fsync + rename) to REMOTE_PATH inside the sandbox.
Examples: iii worker sandbox upload <SB> ./script.js /workspace/script.js tar -cf - ./srcdir | iii worker sandbox upload <SB> - /workspace/src.tar
iii worker start
Start a previously stopped managed worker container. By default waits up to 120s for the worker to report ready before returning. Workers will continue to start after 120s, see iii worker status and iii worker logs for tracking workers
iii worker status
Show detailed status of one worker (config, sandbox, process, logs). By default refreshes live in place until the worker reaches a success or failure state
iii worker stop
Stop a managed worker container. Stop is treated as a routine, reversible action; running iii worker start <name> brings the worker back up
iii worker sync
Install registry-managed workers exactly from iii.lock
iii worker update
Update workers in iii.lock to their latest allowed version
iii worker verify
Verify the worker’s manifest (iii.worker.yaml) is valid
iii console
Developer console for the iii engine
The iii binary dispatches iii console ... to the separately installed iii-console binary (downloaded on first use); the same binary can also be invoked directly as iii-console.