Workers and identity
Task queues, the default single worker, shared worker pools, and how cori status shows what's online.
v1: one worker, your machine
By default, cori run runs an ephemeral in-process worker on your machine. All steps go to your machine's task queue, derived from your identity. This is the "solo flow" — no configuration needed.
cori work — keep a machine online
cori run spawns a worker just for that run. If you want a machine to stay available between runs (so other machines can dispatch work to it), run:
cori workThis starts a long-lived worker process that listens on your identity-derived task queue. While it's running, any cori run command that targets your task queue can dispatch to it.
cori work --shared — service workers
cori work --shared notion-poolThis registers your machine as a worker on the named shared pool's task queue. Workflows can declare that a step should run on a named pool, and any machine running cori work --shared <pool> will pick it up.
Example: you have a machine with Notion credentials configured. You run cori work --shared notion-pool on it. A workflow on another machine declares a step with task_queue: notion-pool. Cori dispatches that step to your Notion machine.
Cross-user dispatch is not possible by construction. Task queues are identity-derived. A step dispatched to notion-pool only reaches machines that have opted in with cori work --shared notion-pool and share the same identity context.
Inspecting workers
cori statuscori status shows the current Temporal endpoint, your identity, and any workers that are currently online.
There is no cori workers command. Use cori status.
Not in v1
There are no Cori cloud workers. All workers are self-hosted on machines you control. See Set up worker pools for the how-to.