You may configure Workerless using CLI options/flags or Docker container environment variables. Here's the list of all configuration variables & options:
# Required Input
This is a unique name for your Workerless program. Metrics sent to CloudWatch will be grouped under a namespace with this name.
WORKERLESS_NAME=myapp-production # OR WORKERLESS_NAME=myapp-staging
A valid license key. You can get one from your dashboard (opens new window).
Name of the Lambda function that Workerless should invoke. You can define a function qualifier to invoke a specific version or alias.
In the example above, Workerless will invoke the
production alias of the
The list of queues to check for jobs. You can use a strictly sorted list or weighted list to configure prioritization.
With this strictly sorted list, all workers will check the
high queue first and only check the other queues when the
high queue is completely empty.
Strictly sorted lists may lead to starvation. In the example above, if the
high queue is always full of jobs, the other queues may not receive any attention from Workerless, and jobs will continue to pile up.
It's recommended to use weighted lists instead:
With this setup, the
high queue will be checked 50% of the time, the
default queue ~33%, and the
low queue ~16%.
# Optional Input
The number of seconds to wait for jobs when all queues are empty. Default is 2 seconds.
Let's say a worker loops over all three queues (
low) and finds no jobs. Instead of looping over and over and increase the number of
EmptyReceives, it will pick a random queue and use long polling to wait for messages to arrive.
In this example, any worker that can't find jobs to process will pick a random queue and wait for 20 seconds until a job arrives.
The maximum wait time is 20 seconds.
With each worker picking a random queue, there's a high chance different workers will be long polling from a different queue so messages are processed as soon as they arrive.
The number of seconds to sleep when long polling returns no jobs. Default is 2 seconds.
In this example, workers won't sleep and will start a new iteration as soon as long polling ends.
This is the maximum number of concurrent function invocations that you want to allow. Default is 5.
This variable defines the number of workers/coroutines Workerless starts. Each worker will be able to perform a single function invocation at any given time, hence why the maximum concurrent invocation is dictated by it.
This example starts 100 workers to consume jobs from the queue.
The more workers there are, the more CPU power is consumed. Specially when the queue is really busy and no long polling or sleeping occurs.
This enables metrics collection. It is disabled by default.
With metrics enabled, workers will send metrics to the main Workerless process until its time to push to CloudWatch metrics.
The number of seconds to wait between sending metrics to CloudWatch. Default is 60 seconds.
Not sending metrics too often increases the performance of workers since storing in memory is way more performant than sending to CloudWatch. It also reduces the expenses since you're charged for every