Supervisor Management

vortos:worker:install writes managed worker blocks to the configured supervisor file. By default, the path is:

docker/worker/supervisord.conf

List Workers

php bin/console vortos:worker:list

The command shows the worker name, command, and description for every worker contributed by installed packages.

Install Workers

Install all registered workers:

php bin/console vortos:worker:install

Install selected workers:

php bin/console vortos:worker:install --worker=aws-ses-outbox-relay
php bin/console vortos:worker:install --worker=aws-ses-outbox-relay --worker=object-store-outbox-relay

Write to a non-default supervisor path:

php bin/console vortos:worker:install --path=docker/worker/programs/vortos.conf

Preview:

php bin/console vortos:worker:install --dry-run

Remove Workers

php bin/console vortos:worker:remove aws-ses-outbox-relay
php bin/console vortos:worker:remove aws-ses-outbox-relay object-store-outbox-relay
php bin/console vortos:worker:remove aws-ses-outbox-relay --dry-run

Managed Block Model

The command owns only Vortos-managed worker blocks. Existing supervisor daemon settings, custom programs, and non-Vortos sections are preserved.

This means teams can keep hand-written custom workers next to generated package workers without losing local config.

Example Generated Program

[program:aws-ses-outbox-relay]
command=php /var/www/html/bin/console vortos:ses:outbox:relay
autostart=true
autorestart=true
startsecs=3
stopwaitsecs=30
stdout_logfile=/var/log/supervisor/aws-ses-outbox-relay.out.log
stderr_logfile=/var/log/supervisor/aws-ses-outbox-relay.err.log

Deployment Pattern

1. Install or update workers in source-controlled supervisor config.
2. Review the diff.
3. Deploy code and config.
4. Reload supervisor or restart the worker container.
5. Verify the process is running.
6. Watch package-specific lag metrics.

For Docker Compose:

docker compose restart worker

Inside a running supervisor container:

supervisorctl reread
supervisorctl update
supervisorctl status

Rootless supervisor in the deploy-in-image model

In the deploy-in-image (RideColor) model one image serves every role and runs as the image's non-root user. supervisord must therefore be configured rootless — a [supervisord] user=root directive, or a pidfile/socket/log under a root-owned directory (/var/run, /var/log/supervisor), makes it try to drop privileges as a non-root user and crash-loop with Error: Can't drop privilege as nonroot user.

A rootless config has no user=, keeps its pidfile and admin socket under /tmp, and logs to stdout. A canonical template ships with vortos-deploy at Resources/worker/supervisord.rootless.conf — copy it into your image or base your own on it.