The "container" in Docker is the shipping container in the photo above. Same idea: ship your app inside a sealed unit that runs identically wherever it lands.
Docker for Beginners: Complete Step-by-Step Guide
Most beginner Docker tutorials start with a definition, get philosophical about kernels and namespaces, and lose you before you've typed a single command. Docker for beginners, as taught here, starts the other way around: install it, run something useful in 30 seconds, then learn what just happened. This guide walks through Docker exactly the way I teach it to junior engineers joining our team in Gurugram: a working example first, then the concepts that make the example make sense, then the small set of patterns you'll actually use on real projects in 2026.
What Docker actually does, in one paragraph
Docker packs your app, its dependencies, and a slim layer of operating system into a single file called an image. You can run that image anywhere (your laptop, a server, the cloud) and it behaves identically every time. The unit you run is a "container", which is just a live instance of an image. Docker fixes "it works on my machine" by shipping the machine with the code.
That single sentence is honestly enough to get started. The kernels-and-namespaces explanation comes later when you need it. For now, hold this picture: an image is a frozen template, a container is a running copy of that template, and the same image runs the same way on any computer that has Docker installed.
Install Docker (3 minutes)
On Mac: download Docker Desktop from docker.com, install, run it, agree to the privacy bits. On Windows 11: same, but enable WSL2 first if it's not already on (Settings, Apps, Optional Features). On Linux: curl -fsSL https://get.docker.com | sh in your terminal. After install, open a terminal and run:
If you see something like "Docker version 27.3.x", you're done. If you see "command not found", your shell hasn't picked up the new PATH yet; close the terminal and reopen it.
Your first container: run nginx in 10 seconds
This is the moment that hooked me on Docker back in 2019, and it still works in 2026. Type this:
Open your browser to http://localhost:8080. You're looking at a working nginx web server. No installing nginx, no fighting with brew or apt, no editing config files. Hit Ctrl+C in the terminal and the server goes away as cleanly as it appeared. That's the whole pitch of Docker in one demo.
What just happened: Docker downloaded the official nginx image from Docker Hub (an online library of images), created a new container from it, mapped your computer's port 8080 to the container's port 80, and ran it. The image cache stays on your machine, so the next docker run nginx starts instantly.
The five commands you'll use every day
Out of Docker's roughly 40 commands, five do 90 percent of the work for a typical developer:
Memorise these. The rest you can look up. Most days, you'll spend 90 percent of your Docker time inside this five-command vocabulary.
Building your own image with a Dockerfile
Running other people's images is fine for learning. Building your own is where Docker starts paying back on real projects. The recipe lives in a file called Dockerfile at the root of your project. Here's a complete one for a Node.js app:
Six lines. Line by line: start from the official Node 22 image on Alpine Linux (a small Linux variant), set the working directory inside the container to /app, copy package.json files first (this layer caches and speeds up rebuilds), install dependencies, copy the rest of the code, declare port 3000, then run server.js when the container starts.
Build it with docker build -t my-app . (the dot means "use the current directory"). Run it with docker run -p 3000:3000 my-app. Your Node app is now a portable, reproducible artifact you can hand to anyone with Docker installed.
Volumes: keeping data alive between runs
By default, anything you write inside a container disappears when the container stops. That's the point: containers are disposable. But you don't want your database to be disposable. The fix is volumes: persistent storage that lives on the host machine and gets mounted into the container.
This runs Postgres with the container's /var/lib/postgresql/data folder mapped to a ./data folder on your machine. Stop the container, restart it tomorrow, and your tables are still there. For database containers, file uploads, generated reports, anything you don't want to lose, use a volume.
docker-compose: when you have more than one container
Most real applications need more than one process. A typical setup is: your app, plus Postgres, plus Redis. Running three separate docker run commands and remembering all the flags gets old fast. Compose lets you describe the whole setup in a single YAML file:
Save this as docker-compose.yml in your project root, then docker compose up. All three services start in the right order, talk to each other over an automatically-created network, and stop together when you Ctrl+C. For local development, Compose is the single most valuable thing in the Docker world.
The biggest gotchas, learned the hard way
Three things will trip you up early. First, port conflicts. If you map -p 8080:80 and another process on your machine is already on 8080, Docker fails with a cryptic message. Fix: pick a different port or kill the other process. lsof -i :8080 tells you what's holding it.
Second, the dreaded "works locally, fails on Linux" problem. Docker Desktop on Mac is actually a tiny Linux VM running Docker; your filesystem is mounted into it. File permissions and line endings can drift between your Mac host and the Linux container. If you see "permission denied" errors that don't appear for your Linux teammates, you've hit this.
Third, image size. A naive Node image weighs 1.2 GB. The same image on Alpine plus a multi-stage build (build dependencies separate from runtime) weighs 150 MB. Small images push faster, pull faster, and cost less to host. Always start from an Alpine or slim variant.
docker run, docker ps, docker logs, how to write a basic Dockerfile, and how to use docker-compose for local development, you have 80 percent of what real engineering teams use Docker for daily. Everything else (Swarm, complex networking, custom registries) you can pick up when a specific job demands it.
When to use Docker, and when to skip it
Docker isn't free. The Docker Desktop install on a Mac eats roughly 4 GB of disk and noticeable battery. Builds take time. A docker-compose.yml file is one more thing in your repo to maintain. For a solo Node project running on Vercel or a Python script on a single laptop, you don't need Docker.
You start needing Docker when: you're sharing a project with teammates who run different OSes; you have multiple services that talk to each other; you're deploying to production servers (or any CI pipeline); your local environment is drifting from production and bugs are showing up only on the server. At that point, Docker pays back its setup cost in days. For hosting comparisons that touch on container support, see our Vercel vs Netlify vs Railway guide.
Closing: get to "hello world" first, learn the rest from there
The fastest way to actually learn Docker is to install it, run nginx, then refactor one of your existing projects into a Dockerfile. The reading-without-doing approach is what makes Docker feel intimidating; doing-first makes the concepts land. Once docker compose up is a thing you type without thinking, you're past the beginner stage and into the genuinely useful tool that's powered most of the production internet for the last decade.
References
- Docker official documentation, get started guide and Dockerfile reference, 2026.
- Docker Compose specification documentation, 2026.
- Docker Hub registry of official images for popular languages and databases.
