Workers

Background processes that run your web service's code.

A worker is a process that runs all the time in the background, without a public address. Use one for queue consumers such as Celery, Sidekiq, BullMQ or Feather's job worker, or for anything that should keep running outside a web request.

A worker runs the code of one of your web services. It runs the version that web service is running, with its own command.

Create a worker

You need a web service in the project that has deployed at least once.

  1. On the project's Services page, click Add next to Background Workers.
  2. Fill in the form:
    • Name
    • Attach to service: the web service whose code the worker runs.
    • Command: what the worker runs, for example node worker.js or celery -A app worker. It must keep running, not exit.
    • Machine: which of the project's machines it runs on. It must be in the same zone as its web service.
    • Guaranteed memory per instance: see Memory and sizing.
    • Number of instances, under Advanced options: from 1 to 5. The default is 1.
    • Price: what the worker costs a month.
  3. Click Create worker.

The command runs directly, not through a shell. To use shell features such as &&, wrap it: sh -c "…".

For a Feather app, the web service's create form can add a worker that runs feather worker --fork for you. See Feather.

Status

StatusMeaning
RunningEvery instance is up.
Creating, UpdatingThe worker is being set up, or is starting with a change or a new version.
StoppedYou stopped the worker.
CrashedAn instance keeps exiting or can't start.
FailedThe worker couldn't be set up or updated.

A worker's command must keep running. If it exits, even without an error, it's started again, and if that keeps happening the status becomes Crashed. The Events page shows the reason, and so does the bell if Resource failures is on in notifications. Check the worker's Logs to see what went wrong. When it stays up again, its status goes back to Running by itself.

Updates from the web service

When the attached web service deploys, its workers update to the new version automatically: a crashed one too, in case the new version fixes it, and a stopped one, so it runs the new version when you start it.

Variables

A worker gets the same variables as its web service, plus any you set for the worker itself. See Environment variables.

Instances

Each instance is a separate copy of the worker running the same command, and each one holds its full guaranteed memory on the machine. Three instances at 512 MB each use 1.5 GB. The worker pays one service fee whatever its number of instances.

To change them, open the worker's Settings, change Guaranteed memory per instance or Number of instances under Scaling, and click Update. The Use idle memory switch under the slider saves straight away. See Use idle memory.

Change the command or web service

In the worker's Settings, under General, change Name, Command or Attached service, then click Update. The worker redeploys with the new settings.

Move it to another machine

A worker runs its web service's code, so it runs on a machine in that web service's zone. When the project has another machine there, the worker's Settings have a Machine section. Pick a machine under Move to and click Move. It redeploys on the other machine with its current code, which takes a minute or two. See Machines.

Stop and start

In the worker's Settings, under Worker control:

  • Stop takes every instance offline.
  • Start runs the worker again with its number of instances.

A stopped worker still holds its memory on the machine and still pays its service fee. Delete the worker to stop paying for it.

The worker pages

A worker has Overview, Events, Logs and Settings pages. The Overview shows its status, command, attached service, instances, and memory, CPU and disk per instance.

Delete a worker

In the worker's Settings, click Delete worker in the Danger Zone and confirm. It can't be undone. Deleting the web service a worker is attached to also deletes the worker.