Container Execution Guide¶
This guide walks you through setting up the container runtime, building the agent runner image, and configuring mount security before running agents in containers.
Step 1: Install a Container Runtime¶
Backend.AI GO supports two container runtimes:
- Apple Container — preferred on Apple Silicon Macs, lighter-weight than Docker
- Docker — supported on all platforms (macOS, Windows, Linux)
Apple Container (macOS Apple Silicon only)¶
-
Download the Apple Container installer from the Apple Container GitHub releases page.
-
Open the downloaded
.pkgfile and follow the installation wizard. -
After installation, verify it works:
-
Start the container system service:
Platform Support
Backend.AI GO supports Apple Silicon Macs from macOS 15 (Sequoia). Apple Container itself requires macOS 26 (Tahoe). Use Docker on macOS 15 through 25. Intel Macs are not supported by the macOS app.
Docker¶
-
Download Docker Desktop for Mac and install it.
-
Start Docker Desktop from your Applications folder.
-
Verify Docker is running:
-
Download Docker Desktop for Windows and install it.
-
During installation, choose WSL 2 as the backend.
-
Start Docker Desktop from the Start menu.
-
Verify Docker is running in PowerShell:
Step 2: Verify Runtime Detection¶
Backend.AI GO automatically detects the best available container runtime on startup.
-
Open Squad > Teams.
-
Check the container-runtime badge in the page header. It shows whether a supported runtime is available. Use the Management API below when you need the detected backend and version.
You can also query the Management API directly:
Example response:
{
"available": true,
"backend": "apple_container",
"version": "0.2.0",
"networking": {
"hostGateway": "192.168.64.1",
"extraRunArgs": []
},
"message": "Apple Container runtime detected"
}
Step 3: Build the Agent Runner Image¶
The agent runner image (aigo-agent-runner:latest) is a pre-configured container image that includes the Claude Code SDK and supporting tools needed by squad agents.
Build from the App¶
-
Go to Squad > Settings.
-
Click Build Agent Image.
-
The build process runs in the background. Progress is shown in the build log panel.
-
When the status shows Image ready, the build is complete.
Build via Management API¶
curl -X POST http://localhost:8001/api/v1/container/image/build \
-H "Content-Type: application/json" \
-d '{"tag": "aigo-agent-runner:latest"}'
Check Image Status¶
Response:
Custom Images
You can specify a custom image tag for specialized agents. The default tag is aigo-agent-runner:latest. Custom images must be pre-built and available locally.
Step 4: Configure the Mount Allowlist¶
The mount allowlist controls which host directories containers are permitted to access. Only paths under an allowed root can be mounted — all other paths are rejected.
Default Blocked Patterns¶
The following path component patterns are always blocked, regardless of allowlist settings:
| Pattern | Reason |
|---|---|
.ssh | SSH keys |
.gnupg | GPG keys |
.env | Environment files |
.aws | AWS credentials |
.azure | Azure credentials |
.gcloud | Google Cloud credentials |
.docker | Docker credentials |
.kube | Kubernetes config |
Adding Allowed Roots¶
-
Open Chat, select Cowork mode, and open the Cowork settings drawer.
-
Select Mount Security, then click Add Allowed Root.
-
Select a host directory (e.g.,
/Users/you/projects). -
Click Save.
Only subdirectories of the added roots can be mounted into containers.
Via Management API¶
# Get current allowlist
curl http://localhost:8001/api/v1/container/mount/allowlist
# Set allowlist
curl -X PUT http://localhost:8001/api/v1/container/mount/allowlist \
-H "Content-Type: application/json" \
-d '{
"allowedRoots": ["/Users/you/projects", "/Users/you/data"],
"blockedPatterns": [".ssh", ".gnupg", ".env", ".aws", ".azure", ".gcloud", ".docker", ".kube"]
}'
Validate a Mount Path¶
Before running containers, you can validate whether a specific path would be allowed:
curl -X POST http://localhost:8001/api/v1/container/mount/validate \
-H "Content-Type: application/json" \
-d '{"hostPath": "/Users/you/projects/myapp", "containerPath": "/workspace/extra/myapp", "readOnly": true}'
Step 5: Configure the Credential Proxy¶
The credential proxy ensures API keys never enter containers. Containers receive a placeholder token and communicate with the proxy at http://host-gateway:3001, which substitutes real credentials before forwarding requests to the upstream API.
The current navigation does not expose a Credential Proxy settings tab. Configure it through the Management API:
Keep the credential out of shell history
Do not paste a real credential into a command argument or a saved request body. The example below reads it without echoing and sends the generated JSON through standard input. Run it from Bash or Zsh.
# Start the proxy on its configured port (default: 3001)
curl -X POST http://localhost:8001/api/v1/container/credential-proxy/start
# Read the credential into a shell variable without echoing it.
printf "Credential: "
IFS= read -rs CREDENTIAL
printf '\n'
# Add an in-memory mapping without placing the credential in process arguments.
printf '%s' "$CREDENTIAL" \
| python3 -c 'import json,sys; print(json.dumps({"id":"anthropic","upstreamUrl":"https://api.anthropic.com","authMode":"api_key","credential":sys.stdin.read()}))' \
| curl -X POST http://localhost:8001/api/v1/container/credential-proxy/mappings \
-H "Content-Type: application/json" \
--data-binary @-
unset CREDENTIAL
Use oauth_bearer instead of api_key when the upstream expects an OAuth bearer token. Mappings live in the running process and are not returned in status responses.
Containers see only the placeholder string CREDENTIAL_PROXY_PLACEHOLDER; the proxy injects the real credential when forwarding the request.
Next Steps¶
- Squad Container Mode — Enable container execution for squad agents
- Task Scheduling — Schedule container tasks to run automatically
- Security Model: How each security layer works