Skip to main content
HybridCloudWorks

Docker · Sandboxes

A coding agent that runs commands needs somewhere safe to run them. Docker Sandboxes give it an isolated microVM on your own machine, and the sbx command line and local sandboxes are free to use, including for commercial work. This is the recipe for pointing one at a landing zone you build on this site.

Run an agent in a sandbox

Run a coding agent inside an isolated Docker microVM—either free on your workstation with a mounted landing-zone folder or remotely with sbx run --cloud and the published hybridcloudworks/hcw-lab:latest image—so it can inspect and validate Terraform without touching host credentials.

Docker Sandbox Agentic Flow — Workstation & Cloud MicroVM Isolation
sbx secret storehybridcloudworks/hcw-lab:latestAGENTS.md guardrails
Workstation CLI (sbx): sbx login & sbx secret set

How it works

  1. Install Docker Desktop (with the sbx CLI) and store your model key via sbx secret set anthropic.
  2. For local runs, unzip a Landing Zone Builder bundle and run sbx run --name hcw-lz --template hcw-lz-sandbox:v1 claude . so only that directory is mounted inside the microVM.
  3. For cloud runs, authenticate with sbx login and run sbx run --cloud claude --name hcw-lz -t hybridcloudworks/hcw-lab:latest, then clone and validate inside the remote environment.
Walk the flow

Key services

  • Docker Sandboxes (sbx): MicroVM isolation for coding agents locally or in Docker Cloud
  • hybridcloudworks/hcw-lab:latest: Published container image bundling Terraform, Ansible, and cloud CLIs
  • AGENTS.md Guardrails: Instructs the agent to explain, format-check, and validate without planning or applying
Inspect services

Security and best practices

  • Store model provider keys with sbx secret set (-g for cloud) rather than passing environment variables on the command line or committing .env files.
  • Keep validation offline with terraform init -backend=false and terraform validate so no cloud credentials enter the sandbox.
  • Remove cloud sandboxes with sbx rm hcw-lz as soon as you finish to avoid idle consumption prior to the one-hour expiry.
Open security deep dive

Outcome

A reproducible local or cloud microVM workflow that lets an agent explain and validate Terraform landing zones with zero access to your host filesystem or cloud subscriptions.

Open implementation & cost

Run an agent against your landing zone

Docker Sandboxes run a coding agent in a microVM on your own machine, with the folder you name mounted inside and nothing else. The recipe linked below builds a template with Claude Code, terraform and the Azure CLI already installed, and an AGENTS.md that tells the agent the folder is a landing zone generated for learning: validate and explain it, never plan or apply it. Build and load the template once from the recipe README, store your Anthropic key with sbx secret set anthropic, then:

  1. Build a landing zone in the Landing Zone Builder and download the zip.
  2. Unzip it and change into the folder it made, so the Terraform files are in the current directory.
  3. Create the sandbox from that folder and open the agent in it. Pick the line for the shell you are in; the folder is mounted at the same path inside the sandbox.
PowerShell
sbx run --name hcw-lz --template hcw-lz-sandbox:v1 claude .
bash
sbx run --name hcw-lz --template hcw-lz-sandbox:v1 claude .

When Claude Code opens, paste this first: Explain what this landing zone deploys, then run terraform init -backend=false, terraform fmt -check and terraform validate and tell me what each printed.

Local sandboxes are free. Cloud sandboxes (sbx --cloud) bill your own Docker subscription, cannot mount this folder, and expire after one hour by default.

The recipe on GitHub: lab-image/sandbox-template (Dockerfile, AGENTS.md, and the README with the build, load and cloud commands; opens in a new tab)

Run it in a Docker cloud sandbox (--cloud)

When you want to run the same workflow without local microVM virtualization, pass --cloud to run inside Docker’s remote Agentic Platform using the published hybridcloudworks/hcw-lab:latest image. Because cloud sandboxes cannot mount a folder from your workstation, you clone the repository inside the remote sandbox and validate there.

  1. 1. Sign in to Docker from the sbx CLI

    Authenticate the sbx command line with your Docker account so it can provision a remote cloud microVM.

    PowerShell
    sbx login
    bash
    sbx login

  2. 2. Store your model provider key in the cloud secret store

    Pass --cloud so your Anthropic key is stored in the cloud secret store (account-wide by default) without writing it into an image or workspace file.

    PowerShell
    sbx --cloud secret set anthropic
    bash
    sbx --cloud secret set anthropic

  3. 3. Launch the cloud sandbox from the published lab image

    Remove any existing cloud sandbox with the same name first (resuming an existing sandbox rejects --cpus, --memory, and --image-ref), then pass --cloud with --image-ref and explicit CPU and memory values to launch from hybridcloudworks/hcw-lab:latest.

    PowerShell
    sbx --cloud rm hcw-lz 2>$null; sbx run --cloud claude --name hcw-lz --image-ref hybridcloudworks/hcw-lab:latest --cpus 2 --memory 4g
    bash
    sbx --cloud rm hcw-lz 2>/dev/null || true; sbx run --cloud claude --name hcw-lz --image-ref hybridcloudworks/hcw-lab:latest --cpus 2 --memory 4g

  4. 4. Clone the repository and validate the Terraform configuration inside the sandbox

    Because a cloud sandbox does not mount a local host folder, clone the repository inside the remote Linux environment and run offline Terraform validation.

    bash
    git clone https://github.com/saulpatinojr/HCW-HybridCloudWorks.git && cd HCW-HybridCloudWorks/lab-image/smoke/providers-only && terraform init -backend=false && terraform validate

  5. 5. Run one-off commands and inspect forwarded ports from your workstation

    Use sbx --cloud exec to run non-interactive verification checks inside the running cloud sandbox and sbx --cloud ports to inspect exposed ports.

    PowerShell
    sbx --cloud exec hcw-lz -- terraform -version && sbx --cloud ports hcw-lz
    bash
    sbx --cloud exec hcw-lz -- terraform -version && sbx --cloud ports hcw-lz

  6. 6. Remove the sandbox when finished (one-hour default idle expiry)

    Cloud sandboxes automatically pause or expire after one hour of inactivity by default. Remove the named cloud sandbox explicitly when your session is complete.

    PowerShell
    sbx --cloud rm hcw-lz
    bash
    sbx --cloud rm hcw-lz

  7. 7. Subscription and billing boundary

    Local sandboxes (sbx run without --cloud) are free on your workstation. Cloud sandboxes (sbx run --cloud) require a Docker Agentic Platform subscription and bill your own Docker account directly on a pay-as-you-go basis.

The sbx command line changes often, so these commands are checked against Docker’s documentation. They were last checked on .