Orchestrator workers
Environment and deployment for BullMQ worker processes (integration refresh and notification email).
Overview
When backend/config/orchestratorFlows.ts sets transport: “bullmq” for a flow, the API only enqueues work to Redis / BullMQ. Long-running worker processes in the orchestrator/ package execute those jobs by importing backend services and repositories in the same Node process (they do not call your HTTP API to run business logic).
Deploy workers on an always-on host (for example Railway). Serverless-only platforms are a poor fit because workers loop until SIGTERM. Railway describes persistent containers under Services → persistent services.
What to configure
- Redis — Same REDIS_* (and optional REDIS_BULLMQ_DB) as the API. See Redis cache.
- Supabase — PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY for server-side tables.
- Per worker — Provider OAuth secrets for integration refresh; email provider keys when the notification-email worker should send mail. A short template lives in the repo at orchestrator/.env.worker.example.
Minimal secret surface
Monorepo scripts (reference)
From the repository root (after install):
| Goal | Command |
|---|---|
| Build common + backend + orchestrator | pnpm railway:orchestrator:build (alias of pnpm orchestrator:build:deps) |
| Production start — integration refresh | pnpm railway:orchestrator:start:integration-refresh |
| Production start — notification email | pnpm railway:orchestrator:start:notification-email |
| Local dev (tsx) | pnpm orchestrator:worker:integration-refresh-bullmq / pnpm orchestrator:worker:notification-email-bullmq |
Repo-root railway.toml sets a shared build command for Railway; start command is set per service in Railway (two workers ⇒ two start commands). See Railway (orchestrator workers).