Docker Worker Overview
Supported Platforms
Docker-compatible hosts, including Docker Desktop on macOS and Windows (64-bit; x86-64, arm64)
Deployment Model
The Docker Worker is distributed as a pre-built container image (distributivenetwork/dcp-worker) and can be deployed on individual hosts using Docker or at scale using container orchestration platforms such as Kubernetes or OpenShift. For orchestrated deployments, Workers are typically launched via declarative configuration (e.g., YAML manifests or generated deployment templates) and managed using standard container lifecycle and scheduling mechanisms. A YAML manifest generator is available to simplify creating deployment templates for large-scale or private compute group deployments.
Execution Model
The Docker Worker executes inside a Linux container managed by the host’s container runtime. The container packages the same dcp-worker and sandboxed evaluator binaries used by Standalone Workers, providing a consistent and reproducible runtime environment across hosts.
Docker provides packaging, dependency isolation, and deployment portability. It does not alter the DCP Worker execution or sandbox security model; it adds an additional isolation boundary enforced by the container runtime.
Docker Worker Quickstart
Pull the latest DCP Docker Worker image from Docker Hub:
bash docker pull distributivenetwork/dcp-worker:latest
Start the container. Naming it dcp-worker makes it easy to reference in the commands below. Run it detached (-d) to keep it running in the background:
bash docker run -d --name dcp-worker distributivenetwork/dcp-worker:latest
Or run it attached to your terminal in the foreground (drop -d) to watch it start up live — Ctrl+C stops the container:
bash docker run --name dcp-worker distributivenetwork/dcp-worker:latest
The container starts a Worker immediately, depositing earnings into a temporary unclaimed account until it's registered. To view all supported command-line options and defaults:
bash docker exec -it dcp-worker /usr/bin/sudo -u dcp /usr/bin/env /usr/bin/node \ /opt/dcp/bin/dcp-supervisor/node_modules/dcp-worker/bin/dcp-worker --help
Register the Worker
Registering links this Worker to your DCP account, so its earnings and configuration are managed from the DCP Portal at dcp.cloud. Get a registration key from your account, then run:
bash docker exec -it dcp-worker /usr/bin/sudo -u dcp /usr/bin/env /usr/bin/node \ /opt/dcp/bin/dcp-supervisor/node_modules/dcp-worker/bin/dcp-worker \ --register=<registration-key>,"<worker-label>"
Registration performs a single action and exits — it doesn't leave a Worker running — so restart the container afterward to bring the registered Worker online:
bash docker restart dcp-worker
Confirm registration, or check status, at any time:
bash docker exec -it dcp-worker /usr/bin/sudo -u dcp /usr/bin/env /usr/bin/node \ /opt/dcp/bin/dcp-supervisor/node_modules/dcp-worker/bin/dcp-worker --show=worker-id
Note: the Worker's identity lives inside the container. Removing the container (docker rm) rather than stopping/restarting it will require registering again.
Configuring the Worker
Once registered, configure the Worker — payment address, compute group membership, utilization limits, minimum wage, and more — from the DCP Portal at dcp.cloud. The Worker checks in with the scheduler and picks up its configuration automatically; nothing further needs to be set locally.
A small set of launch-level actions are available locally the same way as registration above, using flags discovered via --help:
- --register=key,label — link the Worker to a DCP account
- --show=type — inspect the Worker's id, earnings account, or configuration
- --claim-earnings=account — transfer unclaimed earnings to a specified account
These override the Worker's defaults for a single action and exit; day-to-day operation of a registered Worker is driven from the Portal rather than from launch flags.
Monitoring the Worker
For a Worker running detached, follow its live activity — sandbox slices starting and completing, payments received — with:
bash docker logs -f dcp-worker
The Worker also runs a local management service with a web dashboard for status and resource metrics. It's bound to the container's loopback interface by default, so publish the port when starting the container to reach it from your host:
bash docker run -d --name dcp-worker -p 9080:9080 distributivenetwork/dcp-worker:latest
Once the Worker is registered, visit http://localhost:9080/admin/ to view it.
Process and Isolation Model
All evaluator processes run inside the container under an unprivileged user and inherit no elevated privileges. Evaluators communicate exclusively with the Worker over container-local networking (loopback).
All sandbox security guarantees described in the Core DCP Worker Security Model apply unchanged. Docker adds an additional isolation boundary enforced by the container runtime (Linux namespaces and cgroups) but does not modify the Worker’s execution or sandbox security model. Filesystem access is limited to explicitly mounted volumes, if any, and evaluator sandboxes operate entirely within the container boundary.
Resource Scheduling
CPU, memory, and GPU resource allocation are governed by the container runtime and host operating system.
- CPU and memory limits may be enforced via container runtime configuration.
- GPU access is mediated through the host’s GPU drivers and container runtime (e.g., NVIDIA Container Toolkit).
- The DCP Worker does not install kernel modules or modify host system configuration.
By default, the Worker will make all container-visible CPU cores and GPUs available for computation unless constrained by runtime configuration or Worker flags.
Operational Characteristics
Docker Workers are typically used for:
- Cloud and data-center deployments
- Ephemeral or auto-scaled compute pools
- Environments favoring immutable infrastructure and declarative orchestration
They preserve the same core sandboxing and security properties as other DCP Worker variants, with containerization providing standardized packaging and deployment rather than altering the execution or security model.