Container operations and verification

The container catalog in scripts/docker/container-catalog.json covers all 24 Dockerfiles. The inventory check also validates all nine Compose files against the build contexts that CI actually uses. Historical demos remain available; their checks state whether they prove an HTTP service, a command-line entry point, or only the packaged integration dependencies.

Choose the appropriate stack

Stack	Command / purpose	Required setup
Offline One-Box	`docker compose -f demo/One-Box/docker-compose.yaml up --build`	No wallet or production credentials. Browser UI on `http://localhost:4173`.
Connected One-Box	Follow One-Box, then enable `--profile connected`	Local contracts, relayer configuration and browser-reachable API URL.
Root deployment stack	`docker compose --env-file deployment-config/oneclick.env up --build`	Reviewed deployment addresses, a commissioned keystore, unique API tokens, and the matching token metadata.
Rehearsal adapters	Add `--profile rehearsal` to the root stack command	Bundler, paymaster supervisor and attester in this stack are mocks. They do not provide live settlement.
CULTURE	Follow CULTURE	Local chain/bootstrap, database, IPFS and authenticated orchestrator configuration.
Registry agent	`docker compose -f deployment-config/agent-node.compose.yaml up --build`	Reachable `AGENT_REGISTRY_URL`, owner token and unique heartbeat secret. This is a registry/heartbeat agent, not a commissioned computer-use worker.

The root stack binds published ports to loopback. Its gateway listens on port 8090, and the orchestrator runs the One-Box HTTP server on port 8080. The gateway stores its compiled-runtime state in the gateway_storage volume; validation commitments must survive container recreation. Back up this volume before upgrades. Older deployments that wrote state into an unmounted container directory require a deliberate state migration before replacement; do not discard those containers or their reveal secrets.

The gateway runs as the unprivileged node user. Installed dependencies, package manifests and the telemetry helper stay root-owned and read-only to that user. The compiled runtime remains owned by node because its validation anchor, generated agent configuration, training records and telemetry write beneath that tree. Image construction assigns ownership when copying the compiled runtime and only adjusts the writable storage/log directories; it does not rewrite the entire dependency tree into another image layer. The gateway image probe checks these permissions and performs actual state writes.

The generated environment supplies both JOB_REGISTRY and JOB_REGISTRY_ADDRESS. The gateway accepts the validated nonzero AGIALPHA_TOKEN deployment address and still checks the token's name, symbol and decimals against its configuration on chain. Set KEYSTORE_URL and KEYSTORE_TOKEN for the real internal keystore; the template intentionally does not contain a working production credential. Deployed addresses alone do not commission wallets, workers or independent reviewers.

Browser configuration

NEXT_PUBLIC_* values are built into Next.js browser assets. The validator and enterprise Dockerfiles take their public settings as build arguments, and root Compose passes the corresponding environment values into the build. Run the command with --env-file deployment-config/oneclick.env; editing a service's runtime environment alone will not change an existing browser bundle.

The validator server uses the internal GATEWAY_URL=http://agent-gateway:8090 for its read-only same-origin jobs proxy. This private service URL is separate from browser RPC settings.

Use URLs reachable from the browser, such as http://localhost:8545 and http://localhost:8090, rather than Docker-internal hostnames. Rebuild the UI image after changing an address or public URL. Never put private keys, keystore tokens or API secrets in NEXT_PUBLIC_* variables. Token and contract metadata must match the selected network.

What CI proves

The five published images retain the required containers / build (image) check names. Each required check depends on successful native AMD64 and native ARM64 builds, runtime probes, OS vulnerability scans and application-library vulnerability scans. Both scans fail on high or critical findings; no vulnerability suppressions are currently approved. ARM64 runs on GitHub's ubuntu-24.04-arm runner, avoiding the observed QEMU illegal-instruction failure during the webapp dependency installation. A failed, cancelled or skipped native job makes the required checks fail. The same required checks also require the complete inventory and auxiliary image matrix to pass, so an unbuilt historical image cannot silently disappear from coverage.

On main and release tags, CI publishes architecture-specific candidates with provenance and SBOMs, verifies their image identity against the executed images, and combines their digests. Main's latest tag advances only after these checks succeed. Release digest artifact names remain unchanged.

Probe	Evidence produced
Gateway	Positive boot against isolated local Hardhat token/registry/validation fixtures and an ephemeral local keystore; token metadata check, wallet load, HTTP and gRPC listeners, non-root process, protected dependency permissions and writable runtime state, a durable validation record across container recreation, and graceful shutdown. No external worker or paid settlement is implied.
Node runner / One-Box	HTTP health and rejection of an unauthenticated API request. Contract lifecycle behavior is covered separately by the end-to-end tests.
Enterprise / validator UIs	Production Next.js server boots and serves the application. Browser voting and wallet integration have their own tests.
Owner console / CULTURE studio	Nginx configuration and a served application/health endpoint.
Notification service	HTTP boot plus write/read of a stored notification.
Alpha bridge / meta API	Listening gRPC service with packaged protocol definition / Python readiness check against a real isolated Anvil RPC. Upstream integrations require separate commissioning.
Historical and configured integrations	Every Dockerfile builds; the corresponding CLI, entry point or graph dependency probe runs. An entry-point check is explicitly not evidence of a commissioned chain, database, oracle or external agent.

The four primary Node runtime images remove unused global npm/npx after dependency installation; their application dependencies remain installed. The webapp launches Next.js directly with Node. Application dependencies also remain subject to the separate release dependency gate. Container success does not waive that gate, an independent security review, deployment signing requirements, or the live commissioning work in production readiness.

To reproduce an image probe locally after building its catalog tag:

python3 -m pip install PyYAML==6.0.3
python3 scripts/docker/validate-catalog.py
bash scripts/docker/container-smoke.sh webapp agi-smoke:webapp

The gateway probe additionally needs the pinned root Node/npm toolchain, installed locked dependencies, and npx hardhat compile --config scripts/docker/hardhat.fixtures.config.cjs --concurrency 1. This compiles the three repository gateway fixture contracts and their imports into a separate artifact directory, keeping solcjs input bounded. Full production contract compilation remains a separate required gate. The probe launches an isolated chain itself and does not use production keys.

The October 8 checks observed a compiler limitation with the pinned Solidity 0.8.25: compiling the full project through its WASM/solcjs fallback failed with memory access out of bounds on the native ARM64 runner and when forced locally on AMD64. A single sequential compilation with a 4096 MB Node heap reproduced the failure. Use the native AMD64 Solidity compiler for the full production build, as the contract CI does; increasing Node's heap is not an established fix. This observation concerns that compiler and source input, not all ARM64 compilation. Native ARM64 container execution and the bounded gateway fixture compilation are verified separately.