Final Challenge & Recap

Table of Contents

1. The challenge
2. Hints, not a solution
3. Recap

---

1. The challenge

Do the whole course again, from scratch, on your own — in a brand-new sandbox, not sbx-crash-course. This is the real test of whether the workflow stuck, and it proves the sandbox is genuinely disposable:

1. Create a new, separate sandbox.
2. Run a small web application inside it.
3. Start a database container inside the same sandbox.
4. Connect the web application to the database.
5. Access the web application from your host machine.
6. Clean up: remove the sandbox when you're done.

Give yourself 10–15 minutes before looking at the hints below.

2. Hints, not a solution

• Naming the sandbox something new (sbx run --name sbx-challenge shell) keeps it completely separate from everything you built in Parts 2–6.
• You already have two working patterns for "app talks to database": the Node + Postgres + Redis stack from Part 6 reaches its dependencies over localhost, using ports published by docker run -p.
• To reach the web app from your host, you need a second layer of publishing on top of that — sbx ports <sandbox> --publish HOST:SANDBOX — exactly like in Part 4.
• If anything doesn't come up the way you expect, this is a good moment to actually use Part 7 instead of just rereading it: docker ps -a, docker logs, sbx policy log.
• When you're satisfied it works, tear it down:

  sbx stop sbx-challenge
  sbx rm sbx-challenge
  

  Copy

3. Recap

• What is Docker Sandboxes — an isolated microVM, with its own filesystem, network, and Docker daemon, managed by the sbx CLI. Built primarily for running AI coding agents safely; usable in shell mode as a disposable Docker environment for everything else. (Part 1)
• How to create one — sbx run --name <name> shell, picking a network policy on first run. (Part 2)
• How to enter and exit — reattach any time with sbx run --name <name>; sbx stop pauses without deleting, sbx rm deletes everything. (Part 2)
• How to run applications — build normally inside the sandbox, bind servers to 0.0.0.0, and publish ports out to your host with sbx ports. (Part 4)
• How to run Docker containers — the sandbox's own Docker daemon works exactly like a dedicated Docker host; containers never leak into your host's docker ps. (Part 5)
• How networking works — localhost inside the sandbox reaches the sandbox's own containers; host.docker.internal reaches your host; sbx ports is the only door back out to your host machine. (Part 3, Part 6)
• How to debug problems — sbx diagnose, docker logs/ps -a, sbx policy log, and sbx prune to clean up. (Part 7)

That's the whole loop: create, build, connect, debug, remove — repeatable in minutes, with zero cleanup left on your host machine.

There's one more thing worth 5 minutes of your time: what Docker Sandboxes was actually designed for. Part 9 is a short bonus showing that off, using the same sbx CLI you now know well.