Skip to main content

Worker Jobs

Worker jobs are separate processes which use the same image as the application, but with a different entry point. The worker has access to the same environment and binaries as the app runtime. One common use-case is to start a task scheduler which executes tasks on a regular base. It can either be specified on creation of the app or later when updating the app.

Specifying a worker job on app creation​

You can specify a worker job when creating an application by using various worker job related flags on the nctl create app command.

--worker-job-command="bundle exec sidekiq"   Command to execute to start the worker.
--worker-job-name=sidekiq                    Name of the worker job to add.
--worker-job-size=micro                      Size of the worker (defaults to "micro").
$ nctl create app --worker-job-name=sidekiq --worker-job-command="bundle exec sidekiq"

During creation, it's just possible to define a single worker job. You can add up to 3 worker jobs using the nctl update app command.

The worker job will run together with the main app process. It will be restarted in the following cases:

  • A new build is available
  • The configuration of the application changed (new environment variables, size change, etc)

The system ensures that only one instance of each worker job runs at the same time.

Specifying a worker job on other configuration layers​

As worker jobs are part of the configuration of a Deploio application, you can also specify them on other configuration layers. For example, you can specify a worker job via the git configuration source file .deploio.yaml:

workerJobs:
  - name: sidekiq
    command: "bundle exec sidekiq"
    size: mini

Viewing the status of a worker job​

The simplest way to view the status of a worker job with nctl is to use the -o stats command.

Additionally, the logs of the worker jobs can be accessed by viewing the app logs.