Meet the private Docker Engine

What you will build

An engine inventory and a harmless container demonstration. This chapter separates the Docker CLI, its daemon endpoint and the objects that daemon manages.

Read the mechanism

A Docker client sends requests to an Engine. The client binary is not the security boundary: the endpoint it can reach determines which containers, images and volumes it can control. Mounting a host Docker socket into an otherwise constrained environment can give that environment extensive host authority.

A Docker Sandbox supplies its own Engine inside the microVM. A build can create guest images and containers without being handed the host socket. Each sandbox’s workload state is independent; an image present in one guest is not automatically a warm cache in another.

There is also template-image storage used to create sandboxes. Do not conflate that runtime cache with the private Engine’s build cache. This matters when explaining disk growth, cold starts and why a host image is not visible in the guest.

Worked lab · inspect the destination

Run from the host against the named teaching sandbox:

sbx exec handbook-first docker version
sbx exec handbook-first docker context show
sbx exec handbook-first docker image ls
sbx exec handbook-first docker ps -a

Record the client and server sections. If a server section is absent, the client exists but cannot reach its Engine. Do not “fix” this by mounting the host socket.

For an optional network-dependent demonstration, use Docker’s small official hello-world image:

sbx exec handbook-first docker run --rm hello-world
sbx exec handbook-first docker image ls hello-world

This may download an image and requires appropriate registry access. The --rm here applies to the demonstration container, not the sandbox. Stop if policy rejects the pull; chapter 9 explains diagnosis. Record the resulting image digest because an unpinned tag may resolve differently in a future run.

Expected observations

A functioning guest Engine reports server metadata. After a permitted pull, the guest has an image even though the short-lived container has exited and been removed. The image remains available in that sandbox until removed or the sandbox is deleted.

These observations show which inventory the commands inspected. They are not measured proof of host-engine isolation; the topology and the absence of a host socket are separate pieces of evidence.

Troubleshooting

An authorization or proxy error during a pull concerns registry access. “Cannot connect to the Docker daemon” concerns the client-to-engine path. A missing image in a second sandbox can be normal cache isolation. Treat those as distinct failure classes.

For build performance, record whether you measured template preparation, image pulling or the actual build. Combining them into one number makes later comparisons misleading.

Interview practice

Completion check

Explain the difference between client, private Engine, template store, image and container. Identify which one each command touched and document any registry access you needed.

Sources and version notes

Checked 6 October 2026; current baseline: sbx v0.46.0. Develop and test locally · Isolation layers