The shortest answer to what is Docker is this: it is a tool that packages your application together with everything it needs to run (code, libraries, runtime, system tools) into a single portable bundle. That bundle runs inside a container, and it behaves the same way on your machine, on a server, on a colleague's laptop, or on a cloud provider. The classic "it worked on my machine but not on the server" problem largely disappears.
What is Docker, and why did it appear?
The traditional way to deploy an application is to install dependencies on the server one by one: the right PHP version, the right Node.js version, the right libraries, the right environment variables. This is slow and error-prone. When two projects need different versions, things get messy fast.
Docker solves this through standardization. You package your application and its dependencies into an image, then start as many containers from that image as you like. Each container runs in its own isolated space, yet they all share the same operating-system kernel. The result is fast startup, low resource usage, and consistency across every environment.
The difference between containers and virtual machines
Both provide isolation, but they work at different layers. A virtual machine (VM) runs a full operating system on top of a hypervisor that emulates hardware. Each VM has its own kernel, so it can take gigabytes of space and minutes to boot.
A container, by contrast, does not run a separate operating system; it shares the host's Linux kernel and isolates only the application layer. The isolation relies on the Linux kernel's namespaces (separating what a process can see) and cgroups (limiting how many resources it can use).
- Size: Containers are usually measured in megabytes, VMs in gigabytes.
- Startup: Containers boot in seconds, often milliseconds; VMs are much slower.
- Isolation: VMs offer stronger, hardware-level isolation; containers are lighter but share the kernel.
In practice they are not rivals: you often run containers inside a VM. On macOS and Windows, Docker already uses a small background Linux VM, because containers need a Linux kernel to run.
Images, containers, and the layer model
It is important not to confuse two concepts. An image is a read-only template: the file system, the dependencies, and the start command are fixed inside it. A container is a running instance of that image. Think of it like a class and an object: from one image you can produce dozens of containers.
Images are built from layers. Each instruction in a Dockerfile adds a new layer, and those layers are cached. Projects that use the same base image share these layers, which saves both disk space and download time. When you change something, only the layers after that point are rebuilt.
Your first Dockerfile: a small Node.js example
Let's see how you define an image. For a simple Node.js app, a Dockerfile might look like this:
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]Line by line: FROM selects the base image (here the lightweight Alpine-based Node 20). WORKDIR sets the working directory. Copying only the package.json files first and running npm ci before the rest is a deliberate technique to exploit the layer cache: even if your code changes, this layer is not rebuilt as long as the dependencies stay the same. EXPOSE documents the port, and CMD is the command that runs when the container starts.
Essential Docker commands
These are the commands you'll reach for most often in daily use:
# Build the image from the Dockerfile in this folder and tag it
docker build -t my-app .
# Start a container from the image, mapping port 3000 to the host
docker run -p 3000:3000 my-app
# List running containers
docker ps
# Stop a container
docker stop <container-id>
# Follow a container's logs
docker logs -f <container-id>When you want to manage several services together (for example an app plus a database), Docker Compose steps in. You define all services in a single compose.yaml file and bring them up with docker compose up.
When should you use Docker?
Docker isn't always necessary, but it pays off in cases like these:
- Consistent environments: when you want everyone on the team and the server to run identical versions.
- Easy deployment: you can ship the same image to test, staging, and production unchanged.
- Microservices: running each service in its own container keeps responsibilities clear.
- Quick experiments: you can spin up a database or tool with one command and throw it away afterwards.
For a single simple static site, Docker can add unnecessary complexity; choose the tool based on the problem it actually solves.
Frequently Asked Questions
Do I need to know Linux to learn Docker?
It isn't required, but it helps a lot. Since containers are built on the Linux kernel, knowing basic terminal commands, file permissions, and environment variables makes your life much easier. On Windows and macOS, Docker Desktop provides a Linux environment in the background, which is enough to get started.
Are containers secure?
When configured correctly they are quite secure, but because they share the kernel, isolation is not as strong as a VM's. When running untrusted code, good habits include using official base images, running the container as a non-root user, and keeping images up to date.
What is the difference between an image and a container?
An image is a read-only template (like a class), while a container is a running instance of that image (like an object). You can start as many containers from one image as you want, and each runs independently.
Want to move your project into containers? To package your app with Docker, automate your deploy process, or tidy up your infrastructure, get in touch with me — let's design a clean, maintainable setup together.