Astrixion Docs

Deploy Sonar worker capacity

Deploy standard or service-detection Sonar workers on a Docker host.

The VPS deployment script starts standard or service-detection workers on a Docker host. Workers bootstrap their runtime credentials from Sonar, advertise routing tags, consume RabbitMQ tasks, and store file output in MinIO.

Prerequisites

You need:

  1. a full checkout of Astrixion/BBM — a local image fallback needs worker source and Dockerfiles;
  2. Docker with a reachable daemon, plus curl;
  3. the Sonar backend URL reachable from the host; and
  4. the operator-managed WORKER_BOOTSTRAP_SECRET from the team credential channel.

Never expose the bootstrap secret

Do not paste the bootstrap secret into docs, chat, source control, or a generated image. The backend requires it to be at least 32 characters.

Download the deployment sources

The human guide does not embed the scripts. Download the exact published artifacts into the checkout's worker-script directory, or compare them with the files already present there:

git clone [email protected]:Astrixion/BBM.git
cd BBM/scripts/vps-workers
 
curl -fsSLo deploy.sh \
  https://docs.astrixion.ai/artifacts/sonar/workers/deploy.sh
curl -fsSLo docker-compose.deploy.yml \
  https://docs.astrixion.ai/artifacts/sonar/workers/docker-compose.deploy.yml
chmod +x deploy.sh

Dry-run first

Read the secret without putting its value in shell history, then resolve the deployment plan:

read -rsp "Worker bootstrap secret: " WORKER_BOOTSTRAP_SECRET; echo
 
./deploy.sh \
  --backend-url https://sonar.astrixion.ai \
  --secret "$WORKER_BOOTSTRAP_SECRET" \
  --type standard \
  --scale 4 \
  --dry-run

The dry run authenticates to the bootstrap endpoint and probes image availability, but it does not build or pull an image and does not start containers. Review host architecture, worker type, scale, image source, backend, registry, environment-file path, and Compose command.

Launch

Repeat the reviewed command without --dry-run:

./deploy.sh \
  --backend-url https://sonar.astrixion.ai \
  --secret "$WORKER_BOOTSTRAP_SECRET" \
  --type standard \
  --scale 4
 
unset WORKER_BOOTSTRAP_SECRET

The script pulls a matching registry image when available and falls back to a native local build. It writes a per-type mode-600 environment file containing bootstrap and routing inputs; the worker fetches RabbitMQ and MinIO credentials from Sonar when the container starts.

FlagDefaultPurpose
--backend-urlrequiredSonar backend origin.
--secretrequiredWorker bootstrap bearer secret.
--typestandardstandard or service-detection.
--scale1Number of worker replicas.
--tagsemptyExtra comma-separated tags in addition to vps.standard or vps.sd.
--rebuildoffSkip registry selection and build locally.
--dry-runoffResolve and print the plan without launching.

Verify

docker compose -f docker-compose.deploy.yml -p bbmw-standard ps
docker compose -f docker-compose.deploy.yml -p bbmw-standard logs -f

Verify that:

  • every expected replica remains running;
  • bootstrap succeeds without exposing credentials;
  • worker pulses appear in Sonar;
  • the worker advertises the expected canonical and extra tags; and
  • pending tasks for those tags can move to Published and Running.

Use bbmw-service-detection instead of bbmw-standard for that worker type.

Manage and troubleshoot

Scale by rerunning deploy.sh with the same type and a new --scale. Remove one set with:

docker compose -f docker-compose.deploy.yml -p bbmw-standard down
  • Bootstrap 401: verify the secret through the credential channel; do not generate a new client-only value.
  • Bootstrap/network error: check the backend URL, TLS, firewall, and host reachability.
  • Registry pull failure: configure the registry as required by Docker or rerun with --rebuild.
  • Local build failure: confirm the full repository and submodules are present.
  • Workers pulse but tasks remain pending: compare the step's target tags with worker-advertised tags and check routing capacity.

On this page