Railway (workers)

Deploy BullMQ workers as always-on Railway services—build/start scripts, CLI deploy, and stopping a worker safely.

2 min read

Connect your agent today

Draft from chat, review in your calendar, and publish only what you approve.

Overview

Orchestrator workers are long-running processes and should run on an always-on host (for example Railway). See Railway → persistent services.

Workers must share the same Supabase and Redis credentials as the API:

PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_PUBLISHABLE_KEY, and SUPABASE_SECRET_KEY . Legacy JWT keys are not accepted; see Supabase.
REDIS_*, REDIS_TLS, REDIS_TLS_REJECT_UNAUTHORIZED, and (optionally) REDIS_BULLMQ_DB

Queue inspection and destructive Redis operations belong on Redis & queues.

Monorepo scripts (reference)

From the repository root (after install):

# Build common + backend + orchestrator (recommended before deploy)
pnpm railway:orchestrator:build

# Start workers (one always-on service per worker)
pnpm railway:orchestrator:start:integration-refresh
pnpm railway:orchestrator:start:notification-email
pnpm railway:orchestrator:start:scheduled-social-post

Note

Repo-root railway.toml sets build, health check, region (us-west2), and limits for integration-refresh / notification-email (1 vCPU, 1 GiB). Scheduled social post uses railway.scheduled-social-post.toml (1 vCPU, 2 GiB) — point that service’s Railway Config File at /railway.scheduled-social-post.toml.

Stopping a worker service (Railway CLI)

If you need to stop a worker that is currently consuming BullMQ jobs, you can delete the latest deployment for that service. Service names match the Railway setup scripts (openquok-worker-*):

railway down --service "openquok-worker-integration-refresh" --environment production --yes
railway down --service "openquok-worker-notification-email" --environment production --yes
railway down --service "openquok-worker-scheduled-social-post" --environment production --yes

Confirm it is no longer running by checking the service instance list:

railway status --json

Deploying a worker (Railway CLI)

CLI deploy from the monorepo root — make sure the Railway CLI is targeting the worker service you want to deploy. Run railway service again before each deploy so railway up targets the correct service:

railway login
railway link

# Select the worker service (run again before each deploy)
railway service

Each script sets RAILPACK_CONFIG_FILE and runs the deploy; see Railway (workers) → Railway CLI for the full flow.

pnpm railway:deploy:integration-refresh
pnpm railway:deploy:notification-email
pnpm railway:deploy:scheduled-social-post

Next steps

Docker (local Redis)

Local Compose Redis and worker dev commands

Redis & queues

redis-cli for BullMQ locally and in production

Railway (installation)

Service definitions and monorepo Railway patterns