docker concepts

October 31, 2026

One month ago, I had purchased a (one month) trial of a virtual machine that I needed for running some personal projects using Dokploy. My one month trial was successful and today I needed to move my setup to a virtual machine I have bought for a 1-year period. In doing so, I was surprised by how it was less daunting for me to setup my projects, and I am happy that I know a little bit more than I did before. I thought now would be a good time to record these learnings.

Firstly, what's difference between VM (virtual machine) vs Container vs Dokploy?

VM runs separate operating system (OS) and kernel. I got a KVM (kernel based virtual machine).
Containers share a host's kernel with other containers - are quicker to load (there is no OS to boot) but worse for isolation. If the host kernel is compromised which could happen through processes escaping out of containers (container escape), all containers linked are also compromised. However, it is good to run trusted services on, like mine.
Dokploy is something I run on top of Docker. It's a self hosted dashboard that tells Docker what to run/adds domains/HTTPS and is a nice UI to manage all your Docker projects.

Here are some foundational terms:

Dockerfile = describes how to build image
Build recipe i.e. each Dockerfile line adds on to the recipe of the image
Layer order is important. Good Dockerfiles should have expensive/resource intensive steps at the top and frequently-changed steps afterwards. This is because of caching and reducing build time with Dockerfile. If steps are unchanged, their associated build items are cached. This means less time is needed for the overall build.
However this is also important because you need to stay aware of packages/file versions and update when you can. A great example of why is because a couple days ago, the world was faced with this PHP and Node.js vulnerabilities.

I had some applications using Node.js package in their images in my Dockerfile and I realized that I needed to wait for the maintainers to publish an update and then force a version update. My Dockerfile did not automatically update even after the version change was added because all the Dockerfile cache key sees are instructions/local inputs but not anything else i.e. version updates. After doing that, then I needed to redeploy.
Image = immutable file system involving the dependencies, OS files, libraries and code, built by Dockerfile
Immutable because the layers are read-only, and when the Dockerfile is updated - a new image is made but the old is not modified. Each layer is identified by a separate content-hash.
Registry = shared place to hold all images so it can be sent to other places i.e. production, someone else's computer
There are some open-source projects I was using that were stored in registries that I pulled images from to create my own container
Container = image being run
The app running inside a container is what you as an end-user actually use.
Persistent data lives inside volumes. I had stored my settings inside the volumes so it was easy to migrate across VPS changes.
Shares the kernel of it's host so if it ever needs a separate kernel/host, then the host has to change.
Orchestration (i.e. ECS/Kubernetes/Docker Swarm) can be useful for scheduling, removing failed containers, spreading work, scaling processes.