# Workers

Source : https://webgune.cloud/en-us/docs/workers · Mis à jour le 2026-10-27

# 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](/docs/db-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](/docs/commande-demarrage). It is useful when the worker lives in the same repository as the web application:

```bash
node dist/worker.js
```

## Example: consuming a Redis queue

```typescript
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.