Docker Inside the Sandbox

Table of Contents

1. The sandbox's own Docker daemon
2. Pull and run an image
3. List, inspect, and view logs
4. Publish its port
5. Stop and remove the container
6. Why this matters: nested Docker workflows
7. Beginner Pitfalls

1. The sandbox's own Docker daemon

Every sandbox ships with its own Docker daemon — not a connection back to your host's. Inside the sandbox (sbx run --name sbx-crash-course to reattach):

docker version
docker info --format '{{.ID}}'

Now, from your host, in a separate terminal:

docker info --format '{{.ID}}'

Two different daemon IDs. That's the whole point of Part 5 — everything below runs exactly like normal Docker, but scoped entirely to this sandbox.

2. Pull and run an image

Still inside the sandbox:

docker pull nginx
docker run -d --name web -p 8080:80 nginx

3. List, inspect, and view logs

docker ps
docker inspect web --format '{{.State.Status}}'
docker logs web

Ordinary Docker commands — nothing sandbox-specific here. That's deliberate: once you're inside a sandbox, day-to-day Docker usage doesn't change at all.

4. Publish its port

-p 8080:80 above only maps port 80 to port 8080 inside the sandbox's own network — it doesn't reach your host yet. Publish the sandbox's port 8080 out to your host the same way you did in Part 4:

# from your host
sbx ports sbx-crash-course --publish 8080:8080
curl -I http://localhost:8080

You should get nginx's default 200 OK welcome page, served by a container running two layers deep: nginx's container, inside the sandbox's Docker daemon, inside the sandbox's microVM, reached through your host.

5. Stop and remove the container

docker stop web
docker rm web

This only removes the container — the sandbox itself, and the nginx image you already pulled, are untouched. Pull it again later and it's already cached.

6. Why this matters: nested Docker workflows

Compare docker ps on your host right now against docker ps inside the sandbox (if you still have anything running there). They never overlap. Containers you run inside a sandbox:

• Never appear in your host's docker ps, docker images, or docker system df.
• Are deleted entirely when you sbx rm the sandbox — no leftover images, volumes, or dangling containers on your host to clean up afterward.
• Can pull, build, and run exactly like a dedicated Docker host, because that's effectively what the sandbox is.

This is what makes the sandbox a genuinely disposable Docker playground: you can pull questionable images, run containers with unusual flags, or misconfigure something badly, and the cleanup is one command — sbx rm — back on your host.

7. Beginner Pitfalls

• Two ports are in play here: the -p 8080:80 in docker run (host-port- inside-the-sandbox to container-port) and sbx ports ... --publish 8080:8080 (your real host to the sandbox). Missing either one means you can't reach the container from your browser.
• docker system df and docker ps -a inside the sandbox only ever show the sandbox's own containers and images — never your host's, and never another sandbox's.
• If docker pull hangs or fails, it's almost always the sandbox's network policy blocking the registry, not Docker itself. Part 7 covers the fix.