Yoke.sh
Deployment

Scaling

Horizontal runtime workers — YOKE_WORKER_ID, instance ownership, and queue partitioning.

Multiple Yoke runtime workers can share one Postgres database. Each worker drains queues only for actor instances it owns — partitioning compute without partitioning the append stream.

Worker model

                    GLOBAL STREAM (shared)
                           │
              async fan-out (all workers)
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                 ▼
    Worker A           Worker B           Worker C
    instances 1,2      instances 3,4      instances 5,6
    drain loops        drain loops        drain loops
PropertyBehavior
Stream appendShared — any worker or external client can append
Fan-outAll workers share fan-out index; enqueue is global
Queue drainPartitioned — only owning worker dispatches process()

Configuration

export YOKE_WORKER_ID=worker-us-east-1a

Default: {hostname}-{uuid} — unique per process.

Instance assignment

Eventworker_id
ctx.instances.create() on worker ASet to A's YOKE_WORKER_ID
Boot with worker_id IS NULL rowsClaimed by starting worker
Portal/HTTP createCreating executor's worker id

Worker registry

Workers register in runtime_workers and heartbeat every 15 seconds.

Stale workers (no heartbeat for 60s) are excluded from yoke_runtime_workers gauge. Instance ownership is not automatically migrated yet — orphan instances (worker_id pointing to dead worker) idle until manually reassigned or a worker claims NULL rows.

Scaling guidelines

ConcernGuidance
CPU-bound actorsAdd workers; create instances across workers
Single hot instanceIncrease queue.concurrency, not workers
Stream throughputPostgres write scaling; fan-out is async
Stateful actorsSQLite stays with instance on owning worker

Multi-tenant vs horizontal

PatternScope
Horizontal workersMultiple processes, same tenant, shared Postgres
Multi-tenant sandboxesOne executor per hot tenant, scheduler-managed

They compose: each tenant executor can run multiple workers or a single worker, depending on your deployment.

Worker partitioning

Workers partition actor instances, not the append stream. All workers for a tenant share the same global stream; each worker owns a subset of actor instances and drains their queues.

Metrics

MetricPurpose
yoke_runtime_workersActive workers with recent heartbeat
yoke_queue_depthPer-instance backlog — detect hot spots

On this page