@multiplayer-app/sandbox 3.0.0-wip-yjs-state-changes.0 → 5.0.0-sandbox-docker-image.0

package/README.md

@@ -42,6 +42,54 @@ sandbox start --token <token> --worker-id worker-eu-01 \
   --sandbox-url http://localhost:3011 --max-vms 5
 ```
 
+## Run as a Docker container
+
+Build the worker image from the repository:
+
+```sh
+pnpm --filter @multiplayer-app/sandbox run docker:build
+```
+
+The image starts `sandbox start` by default and needs no inbound port:
+
+```sh
+docker run --rm \
+  -e WORKER_TOKEN=<token> \
+  -e WORKER_ID=worker-docker-01 \
+  multiplayer-sandbox-worker:local
+```
+
+To let the worker launch ordinary Docker executors, mount the host daemon:
+
+```sh
+docker run --rm \
+  -e WORKER_TOKEN=<token> \
+  --network host \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  multiplayer-sandbox-worker:local
+```
+
+Host networking is required for the Docker executor because it publishes guest
+ports on the host daemon's loopback interface and the worker proxies to those
+ports. The per-stack guest images must also already exist in that daemon.
+
+For QEMU/KVM, also mount the downloaded base images and expose KVM:
+
+```sh
+docker run --rm \
+  -e WORKER_TOKEN=<token> \
+  -e VM_IMAGES_DIR=/vm-images \
+  --device /dev/kvm \
+  -v "$HOME/.multiplayer/vm-images/$(uname -m):/vm-images:ro" \
+  multiplayer-sandbox-worker:local
+```
+
+The container includes the Docker and QEMU CLIs. Docker Sandboxes still require
+an `sbx` installation and daemon connection supplied by the operator;
+Firecracker requires a compatible Linux host, `/dev/kvm`, and the Firecracker
+binary. Cloud runners use the normal AWS environment variables or workload
+credentials.
+
 For the `qemu` engine, the host needs QEMU (`qemu-system-*`) installed; for
 `firecracker`, a Linux host with `/dev/kvm`; for `docker`, just a running Docker
 daemon (Docker Desktop/OrbStack) plus local images from
@@ -114,12 +162,15 @@ Architecture-specific tags use `<version>-<arch>` so a separate publishing
 workflow can push them and optionally create a multi-architecture `<version>`
 manifest. The build script never uploads files or pushes images.
 
-Tags matching `sandbox-v*` run three release jobs: npm package publication and
-the two architecture-specific base-image publishers start after lint in
-parallel; once both architectures are available, a final job creates the
-multi-architecture Docker tags. The publisher expects the repository variable
-`SANDBOX_BASE_IMAGES_S3_BUCKET`, the existing `DOCKERHUB_ORGANIZATION` variable,
-and the existing `AWS_ROLE_ARN` and `DOCKERHUB_OIDC_ID` secrets.
+Tags matching `sandbox-v*` run npm package publication alongside base-image
+publishers for every combination of `test`, `staging`, `production`, and `demo`
+with `x86_64` and `aarch64`; these jobs publish only QEMU, Firecracker, and
+Lambda artifacts to each environment's S3 bucket. Each S3 publisher enters its
+GitHub environment and expects `ARTIFACTS_S3_BUCKET` plus `AWS_ROLE_ARN` there.
+Container images are published globally exactly once per architecture by a
+separate job, followed by one global multi-architecture manifest job. Those jobs
+use the repository-level `DOCKERHUB_ORGANIZATION` variable and
+`DOCKERHUB_OIDC_ID` secret and do not enter a GitHub environment.
 
 The runner-specific paths intentionally duplicate shared artifacts. That keeps
 each S3 prefix self-contained and allows runner formats to evolve independently.

package/dist/cli.js

@@ -28,7 +28,7 @@ var import_config5 = require("dotenv/config");
 var import_commander = require("commander");
 
 // package.json
-var version = "3.0.0-wip-yjs-state-changes.0";
+var version = "5.0.0-sandbox-docker-image.0";
 
 // src/config.ts
 var import_os2 = __toESM(require("os"));