Queue Workers

API vs worker processes

The HTTP API (Next.js routes) validates workflows, persists runs, and enqueues BullMQ jobs when REDIS_URL is set and WORKFLOW_EXECUTOR_MODE is not inline.

Workflow execution (graph walking, task retries, proofs) runs in npm run worker (or another Node process consuming the same queue).

• ENV_TIER=local: Without Redis, the API may fall back to inline execution for developer convenience (warned in logs).
• ENV_TIER=staging or production: Inline execution from the API is disabled. Without Redis + a worker, POST /api/workflows/run returns 503 and logs Execution engine unavailable — workflows will not run.

Cascades separates workflow design from workflow execution.

Teams build workflows in the dashboard, while background workers process tasks asynchronously behind the platform.

This allows workflows to scale without blocking user activity.

Why queue workers exist

Some workflows complete in seconds.

Others may involve:

• API calls
• long-running jobs
• approvals
• external systems
• delayed responses

Queue workers allow these workflows to run in the background while teams continue using the platform.

How execution works

A workflow is submitted.

Cascades then:

Validate workflow
→ Queue tasks
→ Execute tasks
→ Track progress
→ Handle retries
→ Complete workflow
→ Generate proof records