Goal: add a stateful feature — mark a movie as a favorite, persisted in Redis — and, in doing so, use a pillar we've only mentioned so far: the sandbox's own Docker daemon.
Back in Step 0: each sandbox gets "its own Docker daemon, filesystem, and network." That means the agent can run real backing services — Redis, Postgres, Kafka — as containers inside the sandbox, right next to the app, without touching your host's Docker. That's how we'll get a Redis for favorites.
Tell the agent to run one — the sandbox's own Docker daemon runs it right next to the app:
Run a Redis instance with Docker (redis:7-alpine is fine) and wire it up to the
app for storing favorites.
The image pulls from Docker Hub, which the Balanced policy already allows (container registries are in its baseline) — no new network rule needed. Redis and the app both live in the sandbox, so the agent wires them together internally; there's nothing to publish or open for Redis.
As the product owner, implement the "Mark as Favorite" backlog item: a star on
each movie card that toggles a favorite. Favorites persist in the Redis you just
wired up and survive a reload. If Redis is down, the grid still renders —
favorites are a nice-to-have, not a hard dependency.
Refresh http://localhost:3001: each card now has a star. Click one to favorite it; the star fills. Reload the page — it stays filled, because the state lives in Redis, not in the browser. Stop and restart the app and it's still there. That's real persistence, from a real database, running in the sandbox.
Favorite a movie in the browser (on your host, http://localhost:3001) and reload — the star stays filled. Then go and look at the data yourself, rather than taking the agent's word for it. On your host:
sbx --app-name workshop exec now-showing docker ps # the Redis container
sbx --app-name workshop exec now-showing \
docker exec <redis-container> redis-cli KEYS '*'
sbx --app-name workshop exec now-showing \
docker exec <redis-container> redis-cli TYPE <the-key>Nothing in the prompt dictated a data structure, so read the TYPE first and use the
command that matches it — SMEMBERS for a set, GET for a string, HGETALL for a
hash. Whichever it is, you should find the TMDB ids you starred.
That's the proof: the state lives in Redis, on the sandbox's own Docker daemon, not in
your browser — and docker ps there is a different daemon from your host's (compare
docker version on each; the versions may not even match).
Prev ← Step 10 — Attach a Fetch MCP · Next → Step 12 — Reliable Integration Tests with Testcontainers