How to Use Docker: A Step-by-Step Tutorial

Docker packages an application and everything it depends on into an image, then runs that image as an isolated process on the host’s kernel. Learning how to use it mostly means learning what you can do with that image once it exists.

It runs on Linux and macOS, and on Windows too. People usually measure it against traditional virtual machines, and startup speed and resource use are where the gap shows up.

Docker donated runc, the runtime it built, to help found the Open Container Initiative in 2015, and runc still executes every container by default (Docker, 2024).

That continuity is why Docker images still run unmodified across systems built by different vendors.

What Is Docker?

Nobody should mistake Docker for an operating system, because it isn’t one. It packs code, dependencies and configuration into a single image, then runs that image with Linux namespaces and cgroups so nothing has to emulate a whole computer.

It sits in the same family as Podman and containerd.

It doesn’t replace Linux, Windows or macOS, since it runs on top of them. No hypervisor is needed, which sets it apart from full virtualization. Spreading containers across several physical servers isn’t its job either. That belongs to an orchestrator.

Docker launched in 2013 from the company then known as dotCloud, later Docker Inc. It took Linux container primitives and wrapped them in a workflow developers could actually use. In 2017 the open-source components moved into the Moby Project, which is now the upstream for Docker’s tooling.

Under the hood, the Docker Engine hands execution to containerd and runc. Those two turn a container image into a running Linux process.

Adoption backs all this up. The 2024 Stack Overflow Developer Survey found 59% of professional developers use Docker, and the community rated it the most admired tool at 78 percent.

Itau Unibanco, Latin America’s largest private bank, now runs more than 12,000 repositories in standardized containers as part of a cloud migration that has moved roughly 65 percent of its infrastructure (Docker, 2025).

If you want to follow Docker’s growth over time, the adoption numbers and usage trends give a fuller picture.

Containerization itself isn’t unique to Docker. The concept of packaging software into isolated units predates the company. Docker just made it accessible.

How Is Docker Different From a Virtual Machine?

A virtual machine emulates hardware through a hypervisor and boots its own full kernel. Docker skips that and isolates applications with Linux namespaces and cgroups, sharing the host kernel instead of running a separate guest operating system.

Shared kernel versus emulated hardware. Nearly every other difference between the two comes back to that.

Docker’s own documentation makes the point bluntly. Spinning up an entire operating system just to isolate one application is a lot of overhead for something a container handles natively.

The catch is kernel sharing. A container gets less isolation than a virtual machine, since a kernel vulnerability could in theory reach every container on that host.

Regulated workloads sometimes pair the two for that reason. Put a Docker container inside a dedicated virtual machine and you get the speed along with a hard security boundary.

What Are Docker Images and Docker Containers?

Everything an application needs, meaning its code, runtime and dependencies, gets frozen into an image, a read-only template built in layers.

Start that image and you get a container, which stacks its own writable layer on top and is disposable by design. The image gets built once, versioned, and reused across environments without changes.

The full breakdown of what a Docker image actually contains goes deeper on build layers and tagging. How a Docker container behaves once it starts is a separate question and worth its own read.

The chain itself is short. A Dockerfile builds an image, and Docker runs that image as a container.

Image Layers Explained

Every instruction in a Dockerfile produces one layer, and Docker stacks them to form the final image.

Layers get cached, so an instruction that hasn’t changed reuses its previous result on the next build. Images with an identical base share layers too, which saves disk space on the host. While a container runs, only the top writable layer changes and the image layers underneath stay untouched.

A container moves through a few defined states: created, running, paused, stopped and removed.

Removing a container deletes its writable layer. The image underneath stays exactly as it was, ready to spin up a fresh container whenever you want one.

How Do You Install Docker?

The installer differs by operating system, but you end up in the same place: a working Docker Engine and daemon, ready to build and run containers.

The way developers work is shifting. Docker’s 2025 State of Application Development Report found that 64% of respondents now primarily develop in non-local environments, while 36 percent mainly work locally. That reverses the 2024 report, where the split ran the other way (Docker, 2025).

The basic sequence looks the same everywhere:

1. Download the correct installer for the operating system in use
2. Run the installer and accept the required system permissions
3. Start Docker Desktop or the Docker daemon, depending on the platform
4. Confirm the installation with a version check
5. Run a test container to verify everything works end to end

Installing on Windows

Docker Desktop for Windows uses WSL 2, the Windows Subsystem for Linux, as its default backend to run Linux containers natively. Hyper-V and Docker VMM are available as backends too.

You need Windows 11 (23H2 or later) or Windows 10 22H2 (build 19045), 64-bit, on the Home, Pro, Enterprise or Education edition. Windows containers specifically require Pro, Enterprise or Education. WSL 2 has to be enabled and set as the default backend, and virtualization needs to be turned on in the system firmware.

Every prompt in the installer, including the WSL 2 setup, is covered in the full Docker installation walkthrough.

Installing on macOS

Docker Desktop for Mac ships as a single application, with separate builds for Apple Silicon and Intel chips.

Installation is mostly drag and drop. Mount the disk image, move the app to Applications, then launch it once to finish setup.

The first launch can take a minute longer than you’d expect, since Docker initializes its virtual machine layer in the background.

Installing on Linux

Linux gets Docker Engine directly, without the desktop wrapper that Windows and macOS need.

Package managers do most of the work. On Ubuntu and Debian you install through apt using the official Docker repository, and on Fedora and RHEL you use dnf pointed at Docker’s own repository.

Once it’s installed, confirm the daemon is active before doing anything else.

A version check and a test container tell you whether the engine, the daemon and network access all work together. If anything looks off, the Docker running status guide is worth a look.

How Do You Write a Dockerfile and Build a Docker Image?

A Dockerfile is a plain text file with the instructions Docker follows to assemble an image, layer by layer. Building from it goes like this:

1. Write the Dockerfile with a base image and the required build steps
2. Run the build command from the directory containing the Dockerfile
3. Docker reads each instruction and creates a new layer for it
4. The finished image is tagged with a name and version
5. The tagged image is ready to run as a container or push to a registry

Since Docker Engine 23.0, BuildKit has been the default build engine, replacing the older and slower builder behind the scenes.

Core Dockerfile Instructions

A handful of instructions cover most real-world Dockerfiles. FROM sets the base image that everything else builds on. RUN executes a command during the build, like installing a package. COPY moves files from the build context into the image, usually alongside WORKDIR to set the working directory. CMD defines the default command the container runs on startup, and that’s about it for the basics.

Instruction order matters more than most people expect.

Docker invalidates the build cache from the first changed instruction onward and rebuilds everything after it. Put the stuff that rarely changes near the top.

Multi-Stage Builds

Multi-stage builds use more than one FROM statement in a single Dockerfile. One stage compiles the application, and a second, leaner stage ships only the finished result.

Build tools, compilers and source code stay behind in the first stage. Only the compiled output gets copied into the final one, so the final image leaves out everything the application doesn’t need at runtime.

Smaller final images mean faster pulls and faster deployments, plus a smaller attack surface for anyone scanning the image afterward.

Keeping a Docker command reference open while you write a Dockerfile saves a lot of back and forth with the documentation.

How Do You Run and Manage Docker Containers?

Running a container starts from an image and moves through a small, repeatable set of commands.

1. Start a new container from a specified image
2. List the containers currently running on the host
3. Send a stop signal to a running container
4. Run an additional command inside a container that’s already running
5. Remove a stopped container permanently

Interactive mode keeps a terminal attached to the container. Detached mode runs it in the background and hands control straight back.

If you’re setting up a container for the first time, the guide on creating a Docker container covers naming, port flags and common startup errors.

Restart Policies

• The default, no, means the container never restarts automatically
• on-failure restarts it only when it exits with a non-zero error code, and it is not restarted when the Docker daemon restarts
• always brings it back whenever it stops, though a container stopped manually only returns when the Docker daemon restarts or you restart it by hand
• unless-stopped behaves much like always, except a manually stopped container stays stopped even after the Docker daemon restarts

Containers don’t tend to live long.

Sysdig’s 2025 Cloud-Native Security and Usage Report found that 60 percent of containers now run for one minute or less, up sharply from a time when half lasted at least five minutes.

With lifespans that short, restart policies earn their keep. A crashed container that never comes back can quietly take a service down with it.

The Warehouse Group, a major New Zealand retail chain, saved more than 52,000 developer hours annually through streamlined processes that include Docker and Backstage (Docker, 2025).

Restarting one container by hand is still necessary sometimes, and the full command sequence is in the guide on restarting a Docker container.

How Does Docker Networking Work?

Containers reach each other, the host and the outside world through one of several driver types. Each driver solves a different connectivity problem, and picking the wrong one is a common reason containers can’t see each other.

The bridge network is what Docker uses by default when you don’t specify another one at container startup.

Containers on the same bridge network can reach each other by name, so nobody has to look up an internal IP address ahead of time.

Publishing a port maps a port on the host to a port inside the container. Without it, a containerized web server wouldn’t be reachable from a browser at all.

The host driver skips that mapping step by handing the container direct access to the host’s own network interface. You trade isolation for raw speed.

Overlay networks start to matter once a single host isn’t enough. A Docker Swarm cluster spans several machines, and overlay networking lets a container on one host talk to a container on another as if they shared a local network.

How Do You Persist Data With Docker Volumes?

A container’s filesystem disappears the moment that container is removed, which is a problem for anything that needs to keep its data.

Docker volumes fix that by storing data outside the container’s own filesystem, in a location Docker manages directly.

Persistent storage isn’t a nice-to-have for most teams. The 2024 CNCF Annual Survey found that 74% of organizations already use containers to run stateful applications such as databases.

Docker tracks exactly where that data physically lives on the host, a detail covered in the guide on where Docker volumes are stored.

Volumes vs Bind Mounts

Named volumes are the recommended default for anything going to production, since Docker handles permissions and location automatically.

A bind mount points straight at a folder on the host machine. That’s convenient during development, but it ties the container to that machine’s exact file layout.

And tmpfs mounts never touch disk at all. Once the container stops, whatever was stored there is gone for good.

How Do You Use Docker Compose for Multi-Container Applications?

Compose defines and runs multi-container applications from a single YAML file, so you don’t type out a separate docker run command for every service.

A typical compose.yml lists services, networks and volumes together, which means the whole application starts or stops as one unit. One command brings the stack up and another takes it down, both reading from that same file.

Compose has been through real version changes worth knowing about. Compose V2 became generally available on April 26, 2022, and Compose V1 stopped receiving updates in July 2023, according to Docker’s own documentation.

If you’re piecing together a first multi-service setup, the deeper mechanics are in the explanation of what Docker Compose actually does.

Compose vs Kubernetes vs Swarm

Compose fits small, single-host setups well. Once an application has to run across multiple machines, the calculation changes.

The appeal of Compose is plain. The YAML is easy to read and version control, there’s no cluster to set up, and it’s fast for local development and small deployments. The downside is that it has no built-in failover across hosts and wasn’t designed for large-scale production traffic.

Kubernetes is nearly the reverse. It restarts failed workloads automatically, scales across many hosts and handles rolling updates. You pay for that with a steeper learning curve and heavier operational overhead, which is overkill for a small app on one server.

The market has already made its choice at scale. The CNCF’s 2025 Annual Cloud Native Survey found that 82 percent of container users now run Kubernetes in production, up from 66% in 2023.

Docker Swarm sits in the middle. It’s simpler than Kubernetes but brings basic multi-host clustering that plain Compose doesn’t have on its own.

Ataccama moved its infrastructure to a container-based architecture built on Docker to get portability across on-prem and cloud environments as it scaled onto AWS and Azure.

For a closer side-by-side of Compose and a full orchestration platform, see the comparison of Kubernetes and Docker.

How Do You Push and Pull Images From a Docker Registry?

A registry stores images so they can be pulled down and run on any machine with Docker installed.

Docker Hub is the default public registry, and it holds official images for popular software like databases, web servers and programming language runtimes.

Pushing starts with tagging the image correctly, since the tag tells Docker which registry and repository it belongs to.

1. Tag the local image with the target registry and repository name
2. Log in to the registry with valid credentials
3. Push the tagged image to that registry
4. Pull the same image on any other machine that needs it

Not every registry is public. A private container registry, hosted on services like Amazon ECR or Azure Container Registry, keeps proprietary images out of public view.

Docker Hub’s 2025 pull limits are 100 pulls per 6 hours for unauthenticated users and 200 pulls per 6 hours for authenticated free accounts. Paid Pro, Team and Business plans get unlimited pulls under fair use.

Docker confirmed these figures directly, after reversing an earlier plan to charge for pulls and delaying storage-based billing indefinitely (Docker, 2025).

CI pipelines are where these limits bite most often. Automated builds can pull the same base image dozens of times an hour without anyone noticing.

When Does Docker Not Work Well?

Docker isn’t the right tool for every workload, and pretending otherwise causes real problems later. The shared kernel that makes it fast is the same thing that limits where it belongs.

An application that needs a different kernel than the host can’t run in a Docker container at all, since containers don’t carry their own kernel the way a virtual machine does. GUI-heavy desktop applications generally resist containerization too, because Docker was built around headless, server-side processes.

Extremely performance-sensitive workloads, like high-frequency trading systems, sometimes still favor bare metal or a dedicated virtual machine. And multi-tenant environments running untrusted code carry real risk, since every container on a host shares that host’s kernel.

That last point isn’t theoretical.

In November 2025, three separate runc vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881) were disclosed by SUSE engineer and OCI board member Aleksa Sarai. Each one lets an attacker escape a container’s isolation and gain root-level access to the host. Fixes shipped in runc 1.2.8, 1.3.3, and 1.4.0-rc.3.

Docker relies on runc, the low-level runtime, to actually start containers, so a flaw there reaches far beyond Docker itself.

None of this makes Docker unsafe to use. It just means the isolation boundary is a process boundary, not the hardware boundary a virtual machine provides.

Workloads that truly need a hardware-level guarantee, such as running fully untrusted third-party code, are usually better served by a virtual machine or a hardened runtime layered on top of the container.

FAQ on How To Use Docker

Which Base Image Should You Choose?

Alpine Linux keeps images small, often under 10MB, which suits production deployments.

Ubuntu or Debian based images give up some size for broader compatibility and easier debugging. The right pick balances image size against how many dependencies the application actually needs at runtime.

What Is the Difference Between docker run and docker exec?

docker run creates a new container from an image and starts it.

docker exec runs a command inside a container that’s already running. Developers reach for exec when they need to debug a live container without restarting it.

Is Docker Free to Use?

Docker Engine and the Docker CLI are open source and free under the Apache 2.0 license.

Docker Desktop stays free for personal use and small businesses, but larger companies need a paid subscription. Pricing depends on team size and features, not on the underlying engine.

How Do You Clean Up Unused Images and Containers?

Stopped containers, dangling images and unused volumes pile up fast, especially during active development.

A single prune command clears that clutter at once and frees disk space right away. Run it regularly and your development machine won’t fill up with old build layers.

How Do You Secure a Docker Container?

Running containers as a non-root user limits what an attacker can do after a compromise.

Keeping base images updated closes known vulnerabilities before they get exploited. Scanning images before deployment and dropping unneeded Linux capabilities shrinks the attack surface further.

What Causes Common Docker Errors Like Permission Denied or Port Conflicts?

A permission denied error usually means the current user isn’t in the docker group.

Port conflicts happen when another process already holds the host port you’re trying to publish. Both are configuration issues rather than bugs in Docker Engine, and both get fixed quickly.

What Comes After You Learn How To Use Docker?

Docker becomes a daily tool once building images and running containers stops feeling like an event and turns into muscle memory, backed by a Compose file for local work and a registry for sharing what you build.

The order matters here, because skipping ahead adds complexity before you need it. Get the Dockerfile producing a lean, working image first. Add a Compose file once more than one service has to run together, and move to an orchestrator only after a workload spans more than one host.

That sequence holds through Docker Engine 29.8, the latest release as of September 2026 (Versio.io, 2026), and a future major engine version that changes default image builds would shift the starting point.

Wiring that registry workflow into an automated continuous integration pipeline is the next practical step once local Docker usage feels routine.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• MySQL Cheat Sheet - September 30, 2026
• How to Remove Duplicate Lines in Notepad++ (Sorted or Unsorted) - September 29, 2026
• Should Your Engineering Team Still Own the Marketing Website? - September 29, 2026