Most of the Docker courses I come across seem to have been written back in 2020 ...and never updated.
It's important to understand that the ecosystem has moved on - BuildKit is the default build engine, Docker Compose is no longer a separate or "advanced" topic, and vitally, supply chain security went from nice-to-have to legally required in many cases. Moreover, the adoption of ARM architecture CPUs on developer machines and servers are increasing.
If you're investing time and money in Docker training, it should reflect how containers are actually used today.
We redesigned our Docker training course from scratch for 2026. Here's what changed, what we added, and why.
The fundamentals still matter - but the context has shifted
Naturally, we still start with the basics. What containers are; how they differ from VMs; understanding the container lifecycle.
However, the framing of these topics has changed ...Docker isn't the only container game in town anymore.
Podman has seen growth in enterprise adoption thanks to RedHat's backing and also becoming a CNCF project.
containerd runs under the hood of every major cloud platform.
The OCI standards - Runtime, Image, Distribution - are what make containers portable across all of these tools.
A modern course needs to teach Containers, not just Docker, even if Docker is the primary tool you'll use.
We also teach Docker Engine v29's architecture from day one: the CLI talks to the Docker daemon, which delegates to containerd, which delegates to runC. Understanding this stack pays off immediately when something goes wrong and you're reading error messages that reference containerd rather than Docker itself.
BuildKit isn't optional anymore - it's how you write Dockerfiles
BuildKit has been Docker's default build engine since Engine 23.0. Yet many folks who learnt Docker before that don't use its features or courses that were not updated still teach Dockerfile syntax without mentioning it. That means many developers never learn cache mounts, secret mounts, COPY --link, or parallel stage execution - the features that make the difference between a 10-minute build and a 90-second one.
We teach Dockerfiles with BuildKit as the assumed context from the start. Multi-stage builds aren't introduced as an "advanced technique" in a later module - they're how you build images, full stop. By the end of day one, students have taken a naïve 800 MB Node.js image and optimised it down to under 100 MB using multi-stage builds, cache mounts, minimal base images, and properly ordered layers.
The stretch goal: rebuild onto a distroless base and get that image under 30 MB.
Docker Compose shouldn't just live in a separate course
Docker Compose is no longer as it now comes by default with Docker Desktop / Docker Engine. It made sense in 2018 when Compose was a separate Python binary with its own versioning but it is a core component for a good Docker course now.
Docker Compose v2 is a CLI plugin built into Docker Desktop. It's how developers define and run multi-container applications locally. If your students leave a Docker course unable to write a compose.yaml that spins up an API, a database, and a cache - they can't do their jobs on Monday morning.
Our day two covers the full Compose workflow: service definitions, health checks with depends_on conditions (because a database container being "running" doesn't mean it's accepting connections), environment management, profiles, the include directive for modular configs, and Compose Watch for hot-reload during development. The capstone lab builds a four-service application stack from scratch.
Security isn't a nice-to-have - it's regulated
This is where the gap between legacy courses and the realities of using Docker in 2026 is widest. Most Docker training courses contain zero security content. Not a module, not a mention.
Meanwhile, the UK Cyber Security and Resilience (Network and Information Systems) Bill 2024-26 and EU Cyber Resilience Act now requires Software Bills of Materials in standardised formats. Docker Scout can generate SBOMs and scan images against CVE databases in a single command. Sigstore and cosign enable keyless image signing. SLSA attestations provide cryptographic proof of how an image was built. Distroless and Chainguard base images reduce attack surfaces by up to 96% compared to full Ubuntu images.
Our optional day 4 opens with a full security module. Students start with a deliberately insecure Dockerfile (runs as root, uses an unpinned latest tag, contains a hardcoded API key, installs unnecessary packages). They'll scan it with Docker Scout, and fix every issue step by step. They'll watch the vulnerability count drop from dozens to near-zero. I reckon it's the most satisfying lab in the course.
CI/CD pipelines: because nobody pushes images manually
A container that only exists on your laptop isn't useful. Every code push should produce a tested, scanned, signed, and deployable image automatically. Our CI/CD module walks through building a complete GitHub Actions pipeline: BuildKit setup, multi-platform builds for amd64 and arm64, test execution inside containers, vulnerability scanning gates that fail the build on critical CVEs, meaningful image tagging, and registry caching.
The multi-architecture piece is particularly important now. Apple Silicon is prevalent in developer machines. AWS Graviton powers a growing share of cloud workloads. If you're only building for amd64, you're either excluding developers or paying for emulation overhead in production. A single --platform linux/amd64,linux/arm64 flag in your pipeline solves it.
The ecosystem orientation that makes our course unique
The final module is a practical tour of the tools surrounding Docker that students should know exist, even if they're not ready to adopt them immediately. DevContainers for reproducible development environments (new developer on-boarding in minutes, not days). Docker Init for scaffolding Dockerfiles and Compose files from existing projects. Docker Debug for interactive container troubleshooting. The container orchestration landscape - Kubernetes for production deployments, kind for learning Kubernetes locally. Emerging technologies like WebAssembly containers and Docker's AI toolchain.
The goal isn't mastery of all of these. It's orientation. Students should know what exists so they can make informed decisions about what to learn next.
The three (plus one) day structure
Here's a quick rundown of our updated Docker training course:
Days 1 - 3 goes from "what is a container" to building optimised, multi-stage images with BuildKit. Containers, images, layers, registries, Dockerfiles, and build optimisation; also networking, persistent storage, an overview of key security considerations, and Docker Compose. Students finish up with a working multi-service application and a modern development workflow using Compose Watch.
Day 4 (Optional) tackles Docker security in depth (scanning, SBOMs, signing, hardening), CI/CD pipelines, and the broader ecosystem. Students leave with a working pipeline template and a security checklist they can apply immediately.
Every module balances theory and hands-on labs roughly 50/50. Students get all lab code, solution files, cheat sheets, and CI/CD templates to take away.
The bottom line
Docker hasn't been standing still since 2020 and neither should a good training course. If you're evaluating Docker training - for yourself or your team - check whether the syllabus mentions BuildKit, Docker Scout, multi-architecture builds, and SBOMs. If it doesn't, you're learning yesterday's tools.