Workers

Workers

A worker is a service with no port or domain: a background process that consumes a queue, runs scheduled tasks, or processes data continuously.

When to choose a worker

• Consuming a queue (BullMQ, RabbitMQ, or a simple Redis list).
• Recurring tasks (sending emails, syncing, cleanup).
• Long-running processing that shouldn't block your web application (PDF generation, imports).

Creating a worker

1. + New service → type Worker.
2. Connect the repository (or Docker image) containing the code.
3. If needed, define a dedicated start command. It is useful when the worker lives in the same repository as the web application:

node dist/worker.js

Example: consuming a Redis queue

import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL!);

while (true) {
  // BRPOP blocks until a job arrives
  const [, payload] = await redis.brpop("jobs:emails", 0);
  await sendEmail(JSON.parse(payload));
}

The web service pushes jobs (LPUSH jobs:emails …), the worker pops them off: both services share the same project Redis instance, connected via its environment variables.

Best practices

• One worker = one responsibility. Two very different queues deserve two workers: each scales and restarts independently.
• Handle shutdown gracefully. On receiving SIGTERM, finish the current job before exiting. Redeployments replace the process.
• Idempotence: a job may be reprocessed after a restart; make sure duplicate processing has no side effects.

The worker's logs and metrics (CPU/memory) are available like for any service, in the Logs and Observability tabs.