workers
Defines the list of worker names, which are alternate copies of the application to run as background processes.
Optional in single-runtime and composable images.
Using workers in your project requires a Medium plan or larger to ensure adequate resource allocation.
Workers are exact copies of the code and compilation output as a web instance after a build hook.
They use the same container image.
Workers can’t accept public requests and so are suitable only for background tasks. If they exit, they’re automatically restarted.
The keys of the workers definition are the names of the workers.
You can then define how each worker differs from the web instance using
the top-level properties.
Each worker can differ from the web instance in all properties except for:
buildanddependenciesproperties, which must be the samecronsas cron jobs don’t run on workershooksas thebuildhook must be the same and thedeployandpost_deployhooks don’t run on workers.
A worker named queue that was small and had a different start command could look like this:
applications:
APP_NAME:
type: 'python:3.13'
source:
root: "/"
workers:
queue:
size: S
commands:
start: |
./worker.sh The keys of the workers definition are the names of the workers.
You can then define how each worker differs from the web instance using
the top-level properties.
Each worker can differ from the web instance in all properties except for:
cronsas cron jobs don’t run on workershooksas thebuildhook must be the same and thedeployandpost_deployhooks don’t run on workers.
A worker named queue that was small and had a different start command could look like this:
applications:
APP_NAME:
type: "composable:25.05"
source:
root: "/"
stack:
runtimes: [ "[email protected]" ]
workers:
queue:
size: S
commands:
start: |
./worker.sh