Principal Engineer, Developer Success · Docker
Works on Docker’s developer experience and education.
Find out why changing one line of code can make docker build reinstall every dependency. See the layers your Dockerfile creates, then reorder it so the build cache skips the slow steps.
Explore →A container's files disappear when you remove it. Keep a to-do app's database in a named volume so it survives a new container, bind-mount a directory so you can see the database on your own disk, and learn which one to reach for.
Explore →Connect a to-do app to a MySQL database by hand on a Docker network, feel how many flags that takes, then describe the same app in one compose.yaml and run it with a single command.
Explore →Run a real to-do app in a container, reach it from your browser, run a second copy beside it, configure it with an environment variable, look inside it, and see what happens to its data when you remove it.
Explore →Name your image for a registry, sign in, and push it to Docker Hub with a version tag and latest, then pull it back and run it the way anyone else would.
Explore →Split a Node.js Dockerfile into build stages and a slim final stage, so the image ships the built frontend and production dependencies but leaves the compilers and dev tools behind. Then measure the difference.
Explore →Learn what containers and images are, how a container differs from a virtual machine, and where images come from, using registries, repositories, tags, and the trusted content on Docker Hub.
Explore →Write a Dockerfile for a real Node.js app, build it into an image, run it, and call its API, while learning what each instruction does and what the build context is.
Explore →Write a GitHub Actions release workflow that builds an image with SBOM and provenance attestations, gates it on Docker Scout policy, signs it by digest with keyless Cosign, and only then publishes the release tag.
Explore →Move a Node.js image from node:22 to a multi-stage Docker Hardened Images build, then measure what changed: size, packages, CVEs, and the signed attestations the new base ships with.
Explore →Write an OpenVEX statement for a CVE your application can't reach, check it against Docker Scout, and attach it to the image so the assessment travels with every pull.
Explore →Turn your team's image rules into checks that run on every build: a Buildx build policy that refuses unapproved base images before the build starts, and Docker Scout policies that fail an image that doesn't meet the bar.
Explore →Scan an image with the Docker Scout CLI, separate the findings you can act on from the ones you can't, fix them by updating dependencies and refreshing the base image, and prove the fix with a side-by-side comparison.
Explore →Install Kyverno and write an admission policy that admits an image to the production namespace only when it is signed by your release workflow and carries a signed SBOM, then watch the cluster refuse everything else.
Explore →Sign your image by digest with a Cosign key pair, verify the signature, and watch verification catch an image pushed over a trusted tag.
Explore →Package a language runtime as a Docker Sandbox kit. Install it at build time with a Dockerfile, then use lifecycle hooks and config files to prepare each sandbox before the agent starts.
Explore →Write a small v3 mixin kit from scratch, validate it with Buildx, run it in a sandbox from a local directory, and see how a kit carries its files, network rules, and agent instructions in one image.
Explore →Write a kit that teaches the sandbox proxy about your own internal API, so an agent can call it with a real token that never enters the sandbox.
Explore →Package your team's workflow as an agent skill in a Docker Sandbox kit, add standing guidance beside it, and see an agent find and use both in a fresh sandbox.
Explore →Turn a kit with hardcoded values into one that serves every team and project. Declare arguments with defaults and constraints, template them into network policy and generated files, and supply values from the CLI, an environment file, or a kit set.
Explore →Turn a kit that works on your machine into a versioned, multi-platform, signed image on Docker Hub, and let GitHub Actions publish every release for you.
Explore →Change what's in your sandbox without building anything. Add a published kit to give the agent a browser to test with, then swap the agent itself and keep the browser.
Explore →Capture your sandbox setup in an sbxenv.yaml file, so anyone on your team gets the same sandbox with one command and nobody has to learn every flag you did.
Explore →A friendly, picture-first look at how a Docker Sandbox keeps an AI agent helpful and your computer safe — the box, the door guard, the pretend key, and the kits you pack inside.
Explore →Wire Claude Desktop and ChatGPT Desktop to a Docker Sandbox over SSH, so the AI app you already use drives an agent that never touches your host.
Explore →Configure the credentials an agent needs — built-in services, a kit-declared service, and a private registry — and see why none of them ever reach the sandbox.
Explore →Give Claude Code its credentials, start it on a real project inside a sandbox, and test its isolation yourself — the filesystem, the credentials, and the network — before you clean up.
Explore →