Skip to lesson
supraj.dev THE ENGINEERING HANDBOOKS
LEARN / BUILD / VERIFY2026 edition · checked 06 Oct

A PRACTICAL FIELD GUIDE FOR AI ENGINEERING

Give your agents
room to build.
Know the boundaries.

Docker Sandboxes, from your first isolated workspace to a defensible engineering workflow. Thirty chapters. Clear mechanisms. Useful experiments.

Start the handbookExplore the chapters
FOLLOW THE BOUNDARYWhere does the work happen?
YOUR HOSTShared project folderRead + write access
MICROVM ISOLATION BOUNDARY
AI agentRuns commands
Private EngineBuilds containers

Guest-private files and container state

CONTROLLED NETWORK PATHPolicy + credential proxyPermitted destination → response

Direct mode: changes in the shared folder reach your host files.

1 / 4 · Choose what the sandbox can read and change.

Conceptual local workflow. A boundary limits authority; it does not make shared files or permitted actions harmless.

30structured chapters
60+interview questions
5learning stages
sbxcurrent CLI, v0.47.0 baseline
Learn by observing. Keep claims tied to evidence.Labs are proposed exercises with expected observations, not completed experiments. Local examples use disposable workspaces. Cloud compute and model use can incur charges; enterprise governance and the experimental API have separate prerequisites.

A path from curiosity to confidence.

Read in order, or open the chapter you need.

STAGE 01 · 8 CHAPTERS

Foundations

  1. 01Your first sandbox
  2. 02Draw the isolation boundary
  3. 03Meet the private Docker Engine
  4. 04Create, run, stop and reuse
  5. 05Understand direct workspace risk
  6. 06Work in a private clone
  7. 07Start with no host workspace
  8. 08Trace DNS, localhost and ports
STAGE 02 · 7 CHAPTERS

Capabilities

  1. 09Network policy you can verify
  2. 10Keep secrets behind the proxy
  3. 11Git and GitHub without hidden authority
  4. 12Run Codex with a clear boundary
  5. 13Compare agent integrations fairly
  6. 14Install packages with a trust decision
  7. 15Build a Compose stack inside the boundary
STAGE 03 · 6 CHAPTERS

Operations

  1. 16Parallelize work without shared-file races
  2. 17Budget persistence and resources
  3. 18Locate every MCP tool
  4. 19Govern dangerous tool calls
  5. 20Collect evidence with known coverage
  6. 21Roll out organization policy deliberately
STAGE 04 · 4 CHAPTERS

Automation

  1. 22Treat cloud as a separate backend
  2. 23Read the experimental API and SDK
  3. 24Orchestrate create, exec, files and cleanup
  4. 25Design the Rithru Sandbox Controller
STAGE 05 · 5 CHAPTERS

Evidence

  1. 26Test the boundaries with harmless canaries
  2. 27Separate control and execution planes
  3. 28Deliver an isolated engineering task
  4. 29Measure before making a performance claim
  5. 30Write the evidence-backed enterprise article

BEFORE YOU START

A small lab. A clear contract.

Begin with shell exercises and synthetic files. You need basic terminal and Git familiarity. Follow Docker’s current installation requirements, record your version and use a patched release.

The standalone sbx CLI does not require Docker Desktop for ordinary local sandbox work. Optional host integrations can have their own requirements.

Keep these distinctions close

  • Isolation is different from permission.
  • Read-only is different from confidential.
  • A policy decision is different from a network result.
  • An agent’s report is different from verified evidence.
  • Local and cloud are separate operating models.

PUT THE PIECES TOGETHER

The scenario interview

Reason through real trade-offs, failure paths and evidence requirements.

Open the interview →

REUSABLE FIELD NOTES

Start an honest results ledger

Blank templates for reproducible trials. No benchmark numbers are prefilled.

Download CSV ↓

Version and editorial notes

This edition was checked on 6 October 2026 against current official Docker documentation and sbx v0.47.0 release notes. Commands use the standalone sbx interface. Check the installed version before adapting older docker sandbox tutorials.

Current documentation has inconsistencies around the shared-skills default and Gemini OAuth. The lessons set skills explicitly when it matters and flag the Gemini uncertainty. Cloud limitations, experimental features and paid governance are labelled at the point of use.

Your reading progress stays in this browser. It is a personal checklist, not proof of lab execution, and no account is required to read the handbook.