5 Projects That Will Actually Make You Better at Docker

As a Docker Captain and Co-Founder of a Docker hosting company, I've seen a lot of people struggle and make mistakes with Docker. Most developers "learn" Docker by copy-pasting a Dockerfile from Stack Overflow and calling it a day. But if you want to really understand containers, their limits, their quirks, and how to bend them to your will, you need to play. Here are 5 hands-on projects that will help you level up your Docker skills fast. Are they something you will use day-to-day? No. Are they something that will save your butt in a very weird situation in 5 years time? Maybe, or at least thats what I hope for :D 1. Make the Smallest Docker Image You Can Without Breaking Everything You already have a project. Maybe it is a Next.js frontend or a Flask API. Here is your challenge: strip the image down as far as it can possibly go. Do not just change the base image. Actually remove files and layers until the container stops working. Then figure out why it broke. Try to work around it. Try again. Go smaller. You will learn what your app truly needs, how layering works, and how dependencies silently sneak in. You should look into tools like docker history or dive to see what is really inside. 2. Try to Dockerize Something That Should Not Be Dockerized Pick something that feels wrong. Spotify. A graphical IDE. Your full Linux desktop environment. Even Windows. Try to containerize it anyway. Most of it will fail. That is the point. When it breaks, ask yourself why. Is it a Docker limitation? A kernel problem? A hardware dependency? An assumption about graphical output? You do not fully understand Docker until you have tried something ridiculous and watched it collapse. 3. Build a Base Image From Scratch Most people write Dockerfiles like this: FROM node FROM ubuntu Now do it differently. Use this instead: FROM scratch And build your own base image that runs your app. You will find out how files get into a container. You will learn what a working binary actually needs. You will see why some people use Alpine and others do not. You will discover what glibc is. You will understand how CMD and ENTRYPOINT really behave. This is not practical for production but incredibly useful for understanding how containers work. (Please for the love of all that is holy, just use a normal image in production.) 4. Parameterize Your Docker Builds Open source projects often publish many variations of Docker images. One is based on Debian. Another on Alpine. One is optimized for size. Another is made for debugging. Some support multiple CPU architectures. Try building something similar. Learn how to use build arguments. Learn how to write conditional logic in Dockerfiles. Learn how to generate multiple outputs from a single pipeline. Most importantly, figure out how to avoid writing the same lame logic over and over again. 5. Play the "What If I Ran Untrusted Code" Game Imagine you want to run untrusted code inside Docker containers. A user uploads a script and your backend executes it. What would you need to do to make that secure? Try it. Actually run untrusted code in a container and then start locking things down. Explore seccomp profiles. Set containers to read-only. Use user namespaces. Drop capabilities. Attempt privilege escalation. Try to escape your own sandbox. This is the edge where Docker ends and real sandboxing begins. Bonus Project: Skip the Docker CLI Entirely Docker is just a frontend. Behind it are other tools like BuildKit, containerd, and image specifications. Try skipping Docker altogether. Use buildctl directly. Create an OCI image manually. Push it to a registry without using docker push. Read the OCI image spec and try to replicate what Docker does. Doing this will break your mental model of Docker and replace it with something much more accurate. This is the final boss of container learning. Is this list complete? Definitely not. There's always more to learn, but I hope this motivates you to go deeper :) Cheers, Jonas, Co-Founder of Sliplane

May 6, 2025 - 12:12

5 Projects That Will Actually Make You Better at Docker

As a Docker Captain and Co-Founder of a Docker hosting company, I've seen a lot of people struggle and make mistakes with Docker.

Most developers "learn" Docker by copy-pasting a Dockerfile from Stack Overflow and calling it a day. But if you want to really understand containers, their limits, their quirks, and how to bend them to your will, you need to play. Here are 5 hands-on projects that will help you level up your Docker skills fast.

Are they something you will use day-to-day? No. Are they something that will save your butt in a very weird situation in 5 years time? Maybe, or at least thats what I hope for :D

1. Make the Smallest Docker Image You Can Without Breaking Everything

You already have a project. Maybe it is a Next.js frontend or a Flask API. Here is your challenge: strip the image down as far as it can possibly go. Do not just change the base image. Actually remove files and layers until the container stops working.

Then figure out why it broke. Try to work around it. Try again. Go smaller.

You will learn what your app truly needs, how layering works, and how dependencies silently sneak in.

You should look into tools like docker history or dive to see what is really inside.

2. Try to Dockerize Something That Should Not Be Dockerized

Pick something that feels wrong. Spotify. A graphical IDE. Your full Linux desktop environment. Even Windows.

Try to containerize it anyway. Most of it will fail.

That is the point. When it breaks, ask yourself why. Is it a Docker limitation? A kernel problem? A hardware dependency? An assumption about graphical output?

You do not fully understand Docker until you have tried something ridiculous and watched it collapse.

3. Build a Base Image From Scratch

Most people write Dockerfiles like this:

FROM node

FROM ubuntu

Now do it differently. Use this instead:

FROM scratch

And build your own base image that runs your app.

You will find out how files get into a container. You will learn what a working binary actually needs. You will see why some people use Alpine and others do not. You will discover what glibc is. You will understand how CMD and ENTRYPOINT really behave.

This is not practical for production but incredibly useful for understanding how containers work. (Please for the love of all that is holy, just use a normal image in production.)

4. Parameterize Your Docker Builds

Open source projects often publish many variations of Docker images. One is based on Debian. Another on Alpine. One is optimized for size. Another is made for debugging. Some support multiple CPU architectures.

Try building something similar. Learn how to use build arguments. Learn how to write conditional logic in Dockerfiles. Learn how to generate multiple outputs from a single pipeline.

Most importantly, figure out how to avoid writing the same lame logic over and over again.

5. Play the "What If I Ran Untrusted Code" Game

Imagine you want to run untrusted code inside Docker containers. A user uploads a script and your backend executes it. What would you need to do to make that secure?

Try it. Actually run untrusted code in a container and then start locking things down.

Explore seccomp profiles. Set containers to read-only. Use user namespaces. Drop capabilities. Attempt privilege escalation. Try to escape your own sandbox.

This is the edge where Docker ends and real sandboxing begins.

Bonus Project: Skip the Docker CLI Entirely

Docker is just a frontend. Behind it are other tools like BuildKit, containerd, and image specifications.

Try skipping Docker altogether.

Use buildctl directly. Create an OCI image manually. Push it to a registry without using docker push. Read the OCI image spec and try to replicate what Docker does.

Doing this will break your mental model of Docker and replace it with something much more accurate.

This is the final boss of container learning.

Is this list complete? Definitely not. There's always more to learn, but I hope this motivates you to go deeper :)

Cheers,
Jonas, Co-Founder of Sliplane