Configuration

You may configure Workerless using CLI options/flags or Docker container environment variables. Here's the list of all configuration variables & options:

Required Input

--name / WORKERLESS_NAME

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

--license / WORKERLESS_LICENSE_KEY

A valid license key. You can get one from your dashboard (opens new window).

WORKERLESS_LICENSE_KEY=eyJpdiI6IjkyYj...NjIifQ==

--function / WORKERLESS_FUNCTION

Name of the Lambda function that Workerless should invoke. You can define a function qualifier to invoke a specific version or alias.

WORKERLESS_FUNCTION=vapor-myapp-production-queue:production

In the example above, Workerless will invoke the production alias of the vapor-myapp-production-queue function.

--queues / WORKERLESS_QUEUES

The list of queues to check for jobs. You can use a strictly sorted list or weighted list to configure prioritization.

WORKERLESS_QUEUES=high,default,low

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.

WARNING

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:

WORKERLESS_QUEUES=high:3,default:2,low:1

With this setup, the high queue will be checked 50% of the time, the default queue ~33%, and the low queue ~16%.

Optional Input

--poll-for / WORKERLESS_POLL_FOR

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 (high, default, 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.

WORKERLESS_POLL_FOR=20

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.

WARNING

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.

--sleep / WORKERLESS_SLEEP

The number of seconds to sleep when long polling returns no jobs. Default is 2 seconds.

WORKERLESS_SLEEP=0

In this example, workers won't sleep and will start a new iteration as soon as long polling ends.

--concurrency / WORKERLESS_CONCURRENCY

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.

WORKERLESS_CONCURRENCY=100

This example starts 100 workers to consume jobs from the queue.

WARNING

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.

--metrics / WORKERLESS_ENABLE_METRICS

This enables metrics collection. It is disabled by default.

WORKERLESS_ENABLE_METRICS=true

With metrics enabled, workers will send metrics to the main Workerless process until its time to push to CloudWatch metrics.

--metrics-interval / WORKERLESS_METRICS_INTERVAL

The number of seconds to wait between sending metrics to CloudWatch. Default is 60 seconds.

WORKERLESS_METRICS_INTERVAL=60

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 PutMetricData operation.