Technology · Platform

Docker

Containers are how my agents are sandboxed, how GPU consumers are provisioned on local, LAN and cloud hosts, and how release images are proven.

Sandboxes, GPU nodes, releasesDocker Engine API from RustHardened by default
An agent container, guard inside guard
egress allowlist
CPU, memory, process and runtime caps
read-only root · not root · no capabilities · no new privileges
agent code
the launcher's default profile
  • 10image definitions for native workers, coding-CLI seats and infrastructure services
  • 4loader modes on one generic image: job, capability, agent, infrastructure
  • 2per-GPU images, one for each NVIDIA Blackwell GPU

A sandbox an agent cannot loosen

In Agent Swarm, agents that run code need a sandbox they cannot loosen. The launcher drives the Docker Engine API from Rust to create, inspect, pause and kill agent containers.

Hardening is the default profile, and an agent has no switch to turn it off.

A launch
pulled by digest
private registry
frozen image
no credentials
binaries
bind-mounted
hardened launch
A launch that fails · illustrative
stage 1
stage 2
fail
undo 2
rolled back
undo 1
in stages
Images stay frozen, so a rebuild never changes what was tested.

AgentOS needed seats isolated from each other, so every managed seat is its own container started through that launcher, with provider state copied into a private per-seat directory. See A coding agent that never holds the keys.

A function's location as configuration

In FAFO Core and Function Forge I wanted a function's location to be configuration, so Core injects its runtime into generic containers. One image, a bind-mounted runtime binary and a loader script let any function run anywhere the image runs, with no image rebuild, and agent mode applies the same hardening.

Local machine
LAN host, mTLS
Cloud GPU
the same generic image
the function, a mounted runtime binary
fail-closed budget gate

One GPU, one container, one engine

In the Inference Fabric I wanted a broken GPU node fixed by replacing its container, so each node is one GPU, one container and one engine, with a fast exit on any fatal error. The per-GPU images sit on a TensorRT-LLM base.

GPU node
serving
GPU node
fatal error: exit at once, replace the container
Onboarding a LAN host reconfigures its Docker daemon for TLS with per-host certificates.

Proving a release from inside the image

In ActiveKV, a kernel patch built against the wrong toolchain breaks the ABI vLLM loads, so I rebuild patches inside a container of the exact vendor image. A release counts as promoted only after its hashes are read back from inside that image.

clean clone
build in the exact vendor image
CPU-only
hashes read back
engine and kernel, from inside the image

Containers with nothing to escalate with

In Helix, a server that acts as a digital employee in meetings should have nothing to escalate with. In FAFOHive, agents ask for GPU renders, and an agent-supplied Docker option is an escape hatch. In the Auth and access plane I wanted the weather MCP server to install like a product.

Helix meeting-action server
Writable root
none
Capabilities
none
New privileges
none
Helix's headless desktop runs its display, browser, terminal and encoder in a separate container. FAFOHive's media controller is CPU-only, one per host, and starts GPU renders only from approved profiles. The access plane's weather MCP server, and the Prometheus and Grafana stack, ship as versioned images.