New: Roadmaps ordered paths through our cheat sheets and flashcards, so you always know what to study next.
Explore themSee what's new on GitHubFrom a single Dockerfile to a Kubernetes cluster you can secure and debug.
A 16-step learning path. Follow it in order, or jump to what you need.
This path is for developers or ops engineers who already have Docker or Kubernetes on their resume in name only and want real depth: building images that behave in production, running Kubernetes clusters you can secure and debug, not just kubectl commands copied from a tutorial. Plan on about 8 to 12 weeks at 3 to 5 hours a week, moving from your first Dockerfile to a defensible, debuggable Kubernetes deployment. It stays focused on containers alone: for the wider DevOps toolchain around CI/CD, cloud provisioning, and monitoring, see the DevOps Engineer path instead. By the end you can build and ship a container image through registries and Compose, deploy and scale it on Kubernetes with Helm, defend it with layered security controls, and debug a failing container or pod without guessing.
Expected: comfort with a command-line terminal, Git, and running a basic app locally. Helpful but not required: prior exposure to Linux administration or a cloud provider console.
Open a terminal today and you can package an app plus its dependencies into one image that runs the same everywhere, the works-on-my-machine fix every later step in this path quietly assumes you already have.
Once you can run someone else's image, the next move is writing your own: a Dockerfile turns the ad hoc commands from step 1 into a reproducible build script anyone on the team can rerun.
A single Dockerfile stops being enough the moment your app needs a database sitting next to it, and Compose describes that whole multi-container stack in one file instead of chaining docker run commands from step 1 by hand.
You can build your own Docker image from a Dockerfile and bring up a multi-container app with one Compose command instead of chaining docker run by hand. Next up: getting that image somewhere real and keeping its data and network wired correctly.
Finish this section to unlock.
+100 XP
Images built in step 2 are only useful on your laptop until they live somewhere a teammate or a server can pull them from, and registries are that shared shelf.
Compose in step 3 already touched basic volumes, and here you go deeper on how containers keep data alive across restarts, crashes, and eventually across an entire Kubernetes cluster.
Every container you have run since step 1 has quietly used whatever CPU and memory it wanted, and setting real requests and limits here is what keeps one noisy container from starving the rest on the same host.
DNS and ports have quietly worked by default since step 1, and pulling back that curtain now, bridge networks, service discovery, CNI plugins, is what makes Kubernetes networking in the next step readable instead of magic.
Running one container is easy; keeping hundreds of them healthy across machines needs a mental shift from giving a command to declaring a state and letting the cluster reconcile it, expect this to take a few passes before it clicks.
You can push images to a registry, keep their data and resources under control, and hand all of that to Kubernetes to keep running without babysitting it. A few minutes on chapter one's due flashcards keeps Dockerfile and Compose sharp while you build on them here, and next up is packaging what Kubernetes runs so you stop hand-writing the same YAML twice.
Finish this section to unlock.
+100 XP
Take this if you're weighing whether you truly need Kubernetes's complexity: Swarm gives you real multi-host orchestration using the same docker command you already picked up in step 1.
Hand-writing the same Kubernetes YAML for every environment gets old fast, and Helm packages what step 8 taught you into versioned charts you can install, upgrade, and roll back like real software.
Everything built through step 10 now runs, but running safely is a separate skill: shift-left scanning, secrets, and RBAC are where container security actually clicks, and you will keep circling back to this layer as new tools get added.
You can package Kubernetes apps as versioned Helm charts and see containers the way an attacker does, through unscanned images, leaked secrets, and missing RBAC. Next up: keeping what's declared in Git and what's actually running from quietly drifting apart.
Finish this section to unlock.
+100 XP
Whoever owns hardening a real cluster should not skip this: it goes deeper than step 11's overview into Kubernetes-specific controls like Pod Security Admission, seccomp, and CIS benchmarks.
Manually running kubectl apply against production is how drift creeps in, and GitOps flips that: Git becomes the source of truth step 11's policies enforce, with a tool like ArgoCD pulling changes instead of you pushing them.
Sooner or later a container will crash-loop or a pod will hang in pending, and this is the toolkit for finding out why instead of restarting it and hoping, covering the same ephemeral filesystems and network isolation step 7 introduced.
Debugging in step 14 handles the incident already in front of you; logging and monitoring is what tells you an incident is happening at all, since containers vanish on restart and take their evidence with them.
Every piece from this path, images, networking, storage, orchestration, security, debugging, comes together the moment one service has to call another reliably at scale, which is the actual job most container skills get hired for.
You can debug a stuck container, watch its logs and metrics before a small problem becomes an outage, and wire independent services into one resilient system running on Kubernetes. That's the Docker to Kubernetes badge, earned.
Finish this section to unlock.
+100 XP
Finish every required step, at least 70% of them genuinely done (not skipped), to earn this badge and 500 XP.