Docker for Developers: From Core Concepts to VPS Deployment

If you've been in software development for more than five minutes, you've heard someone say "but it works on my machine." Docker exists specifically to make that sentence obsolete. It's one of those tools that, once you understand it properly, you'll wonder how you ever shipped software without it.

This guide covers everything: what Docker actually is under the hood, how it compares to virtual machines, every core concept you need to know, real-world use cases, best practices that separate production-grade setups from hobby projects, and a step-by-step walkthrough for getting Docker running on a VPS.

Quick Answer

Docker packages an application and its runtime environment into a container image, then runs that image consistently on your laptop, CI server, staging box, or VPS. Learn it in this order: images, containers, Dockerfiles, volumes, networks, Compose, registries, and production deployment. If you are deploying to a VPS, treat Docker as the packaging layer; you still need updates, backups, secrets management, monitoring, and a reverse proxy.

The fastest practical path is to containerize one small app, run it locally, add docker compose, then deploy the same image to a server.

Table of Contents

1. Quick Answer
2. What Is Docker?
3. Why Docker Matters, The Problem It Solves
4. How Containers Actually Work
5. Docker vs Virtual Machines
6. Core Concepts
7. Common Use Cases
8. Best Practices
9. Step-by-Step: Setting Up Docker on a VPS
10. What's Next

What Is Docker?

Docker is an open-source platform that lets you package, distribute, and run applications inside isolated environments called containers. A container bundles your application code together with everything it needs to run: the runtime, system libraries, configuration files, and dependencies, and nothing more.

Launched in 2013 by Solomon Hykes at dotCloud, Docker didn't invent containerization (Linux has had namespace and cgroup-based isolation for years), but it made it practical. It gave developers a standardized, approachable toolchain to build, share, and run containers across any environment, local machine, CI pipeline, staging server, cloud, without modification.

Today Docker is the backbone of modern DevOps. It's how microservices get deployed, how CI/CD pipelines stay consistent, and how teams scale applications without environment problems.

Why Docker Matters, The Problem It Solves

Before Docker, shipping software looked something like this:

• Dev writes code on macOS with Python 3.9, Node 18, and a specific version of libssl.
• The staging server runs Ubuntu 20.04 with Python 3.8 and a different OpenSSL version.
• Production is CentOS 7, a completely different ecosystem.
• The app breaks in staging. It breaks differently in production. Nobody is sure why.

This is the environment parity problem, and it's expensive. Teams burn hours debugging issues that only exist because of infrastructure differences.

Docker solves this by making the environment part of the artifact. Instead of shipping code and hoping the target system matches your assumptions, you ship a container that is the environment. The same image runs identically everywhere Docker is installed, a promise Docker calls build once, run anywhere.

Beyond environment parity, Docker delivers:

• Dependency isolation, Two apps on the same host can run different versions of Python, Node, or any library with zero conflict, because each container has its own filesystem.
• Fast startup, Containers start in milliseconds, not the minutes a VM boot requires.
• Reproducibility, A Dockerfile is an exact, version-controlled recipe for your environment. Anyone on the team can rebuild it identically.
• Portability, Push an image to a registry and pull it on any machine, any cloud, any region.
• Resource efficiency, Containers share the host OS kernel, so you can run dozens on hardware that would strain to run five VMs.

How Containers Actually Work

To understand Docker properly, you need to understand what a container is at the OS level, because it's not magic, it's clever use of Linux kernel features.

Linux Namespaces

A namespace wraps a global system resource and makes it appear to processes inside the namespace as if they have their own isolated instance of that resource. Docker uses several namespaces:

This is why a process running in a container thinks it's the only thing on the machine, from its perspective, it is.

Control Groups (cgroups)

cgroups are a Linux kernel feature that limits and accounts for the resource usage of a collection of processes. Docker uses cgroups to enforce:

• CPU limits (--cpus=0.5, use at most half a CPU core)
• Memory limits (--memory=512m)
• Block I/O throttling
• Network bandwidth limits

Without cgroups, a single runaway container could consume all host resources and take down everything else. With cgroups, each container is a tenant with a defined resource budget.

Union Filesystems

Docker images are built in layers, and union filesystems (like OverlayFS, which most modern Linux installations use) make this efficient. Each layer is a set of filesystem changes (files added, modified, or deleted) stacked on top of the previous one. When a container reads a file, the union filesystem assembles the view from all layers transparently.

This means:

• Multiple containers sharing the same base image don't duplicate it on disk, they reference the same layers.
• When you rebuild an image after changing one line of code, Docker only rebuilds the layers after the change. Everything before is cached.

Containers add a thin read-write layer on top of the image layers. The image itself is read-only. When a container modifies a file, it copies that file into the writable layer first (copy-on-write). When the container is deleted, that writable layer disappears with it, the image is untouched.

Docker vs Virtual Machines

This comparison comes up constantly, and the distinction matters for choosing the right tool.

The key distinction: A VM virtualizes hardware, it runs a full OS on top of a hypervisor (VMware, KVM, Hyper-V). A container virtualizes the operating system, it runs as an isolated process on the host's own kernel.

This means containers can't run a Windows container on a Linux host kernel (without emulation), but it also means they're dramatically lighter and faster.

They're not mutually exclusive. In production, it's common to run Docker containers inside VMs, you get the infrastructure isolation of VMs with the application portability of containers.

Core Concepts

Images

A Docker image is a read-only template that defines what your container will contain: the OS base, installed software, environment variables, file system contents, and the command to run when the container starts.

Think of an image as a class in object-oriented programming. A container is an instance of that class.

Images are layered. Every instruction in a Dockerfile creates a new layer. Layers are cached, content-addressed (identified by a SHA256 hash of their contents), and shareable across images.

# Pull an image from Docker Hub
docker pull nginx:1.25

# List images on your machine
docker images

# Remove an image
docker rmi nginx:1.25

Images are tagged using the format repository:tag. If you omit the tag, Docker defaults to latest, though using latest in production is a bad practice (more on that in the Best Practices section).

Containers

A container is a running instance of an image. It has its own isolated filesystem (the image layers plus a writable layer), its own network namespace, and its own process space.

# Run a container from an image
docker run nginx:1.25

# Run in detached mode (background), name it, and map port 80
docker run -d --name my-nginx -p 8080:80 nginx:1.25

# List running containers
docker ps

# List all containers (including stopped)
docker ps -a

# Stop a container
docker stop my-nginx

# Remove a container
docker rm my-nginx

# Execute a command inside a running container
docker exec -it my-nginx bash

Important flags to know:

Dockerfiles

A Dockerfile is a text file containing a sequence of instructions that Docker uses to build an image. It's your environment as code, version-controlled, reviewable, and reproducible.

Here's a realistic Dockerfile for a Node.js application:

# Start from an official, slim Node.js base image
FROM node:20-alpine

# Set the working directory inside the container
WORKDIR /app

# Copy dependency files first (for better layer caching)
COPY package.json package-lock.json ./

# Install dependencies
RUN npm ci --only=production

# Copy the rest of the application code
COPY . .

# Expose the port the app listens on (documentation only, doesn't publish the port)
EXPOSE 3000

# Create a non-root user and switch to it
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

# The command to run when the container starts
CMD ["node", "src/index.js"]

Key Dockerfile instructions:

Build an image from a Dockerfile:

# Build and tag an image
docker build -t my-app:1.0 .

# Build with a specific Dockerfile
docker build -f Dockerfile.prod -t my-app:prod .

# Build with a build argument
docker build --build-arg NODE_ENV=production -t my-app:prod .

Registries

A registry is a storage and distribution system for Docker images. When you docker push an image, it goes to a registry. When you docker pull, it comes from one.

Docker Hub (hub.docker.com) is the default public registry. It hosts official images maintained by Docker and publishers (nginx, postgres, node, python, redis, etc.) and community images.

Other registries you'll encounter:

# Log in to Docker Hub
docker login

# Tag an image for a registry
docker tag my-app:1.0 yourusername/my-app:1.0

# Push to Docker Hub
docker push yourusername/my-app:1.0

# Pull from Docker Hub
docker pull yourusername/my-app:1.0

# Pull from a private registry
docker pull ghcr.io/yourorg/my-app:1.0

Docker Compose

Docker Compose is a tool for defining and running multi-container applications. Instead of managing several docker run commands with complex flags, you define your entire stack in a single docker-compose.yml file and manage it with one command.

This is where Docker goes from "useful for running one app" to "practical for running real systems."

Here's a docker-compose.yml for a web application with a Node.js backend, PostgreSQL database, and Redis cache:

"code-token-key">version: "3.9"
"code-token-key">
services:
"code-token-key">  app:
"code-token-key">    build:
"code-token-key">      context: .
"code-token-key">      dockerfile: Dockerfile
"code-token-key">    container_name: my-app
"code-token-key">    restart: unless-stopped
"code-token-key">    ports:
      - "3000:3000"
"code-token-key">    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://appuser:secret@db:5432/mydb
      - REDIS_URL=redis://cache:6379
"code-token-key">    depends_on:
"code-token-key">      db:
"code-token-key">        condition: service_healthy
"code-token-key">      cache:
"code-token-key">        condition: service_started
"code-token-key">    networks:
      - app-network
"code-token-key">
  db:
"code-token-key">    image: postgres:16-alpine
"code-token-key">    container_name: my-postgres
"code-token-key">    restart: unless-stopped
"code-token-key">    environment:
      - POSTGRES_USER=appuser
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=mydb
"code-token-key">    volumes:
      - postgres-data:/var/lib/postgresql/data
"code-token-key">    healthcheck:
"code-token-key">      test: ["CMD-SHELL", "pg_isready -U appuser -d mydb"]
"code-token-key">      interval: 10s
"code-token-key">      timeout: 5s
"code-token-key">      retries: 5
"code-token-key">    networks:
      - app-network
"code-token-key">
  cache:
"code-token-key">    image: redis:7-alpine
"code-token-key">    container_name: my-redis
"code-token-key">    restart: unless-stopped
"code-token-key">    volumes:
      - redis-data:/data
"code-token-key">    networks:
      - app-network
"code-token-key">
volumes:
"code-token-key">  postgres-data:
"code-token-key">  redis-data:
"code-token-key">
networks:
"code-token-key">  app-network:
"code-token-key">    driver: bridge

Core Compose commands:

# Start all services (build if needed)
docker compose up -d

# Stop all services
docker compose down

# Stop and remove volumes (destroys data, use carefully)
docker compose down -v

# View logs for all services
docker compose logs -f

# View logs for a specific service
docker compose logs -f app

# Rebuild images and restart
docker compose up -d --build

# Scale a service to multiple instances
docker compose up -d --scale app=3

# Execute a command in a running service
docker compose exec app sh

Common Use Cases

1. Local Development Environments

Instead of installing PostgreSQL, Redis, Elasticsearch, and RabbitMQ on your laptop and fighting version conflicts, spin them up in containers:

docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=dev postgres:16
docker run -d -p 6379:6379 redis:7
docker run -d -p 9200:9200 -e "discovery.type=single-node" elasticsearch:8.11.0

When you're done: docker stop $(docker ps -q). No cleanup, no leftover processes, no version conflicts.

2. CI/CD Pipelines

Every step of a CI/CD pipeline runs in a container, the test runner, the build tools, the linter. This guarantees that the test environment matches the production environment, which eliminates "it passed in CI but broke in prod."

3. Microservices Architecture

Each microservice gets its own container, its own image, and its own release cycle. Teams deploy independently, scale independently, and fail independently.

4. Running Multiple Versions of a Language/Runtime

Need to test your library against Node 18 and Node 20? Python 3.10 and 3.12?

docker run --rm -v $(pwd):/app -w /app node:18 npm test
docker run --rm -v $(pwd):/app -w /app node:20 npm test

5. Isolating Untrusted or Legacy Applications

Legacy apps with unusual dependencies, third-party tools you don't fully trust, or software with difficult installation requirements all become manageable inside containers.

6. One-Click Self-Hosted Tools

The Docker ecosystem has made self-hosting powerful tools trivially easy. Plausible Analytics, Ghost, n8n, Gitea, Vaultwarden, Nextcloud, all available as a single docker compose up.

Best Practices

Use Specific Tags, Never latest in Production

# Bad
FROM node:latest

# Good
FROM node:20.14.0-alpine3.20

latest is a moving target. What works today may break when the maintainer pushes a new major version. Pin to a specific version so your builds are reproducible.

Use Minimal Base Images

Alpine Linux-based images (node:20-alpine, python:3.12-slim) are dramatically smaller than full Debian-based images, which reduces attack surface and speeds up pulls.

node:20        -> ~1.1 GB
node:20-alpine -> ~135 MB

If Alpine doesn't work for your use case (it uses musl libc instead of glibc, which can cause compatibility issues), use slim variants instead.

Optimize Layer Caching

Docker caches layers. If a layer's contents haven't changed, Docker reuses the cache and skips re-running that instruction. Structure your Dockerfile so frequently-changing content comes last.

# Bad, changes to code invalidate the npm install layer
COPY . .
RUN npm ci

# Good, npm install only re-runs when package.json changes
COPY package.json package-lock.json ./
RUN npm ci
COPY . .

Never Run Containers as Root

Running as root inside a container is a security risk, if the container is compromised, the attacker may be able to escalate to host root.

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

Use .dockerignore

Just like .gitignore, a .dockerignore file prevents unnecessary files from being sent to the Docker build context, speeding up builds and preventing secrets from ending up in images.

# .dockerignore
node_modules
.git
.env
*.log
coverage
dist
README.md

Use Multi-Stage Builds to Keep Production Images Small

Multi-stage builds let you use a large build image to compile your app and then copy only the compiled output into a minimal production image.

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:20-alpine AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
USER node
CMD ["node", "dist/index.js"]

The final image contains only the runtime output, not your source code, build tools, or dev dependencies.

Store Secrets Outside the Image

Never bake secrets (API keys, database passwords, tokens) into a Dockerfile or commit them in an image layer. Use:

• Environment variables at runtime (docker run -e SECRET=...)
• Docker secrets (for Docker Swarm)
• A secrets manager (AWS Secrets Manager, HashiCorp Vault) at startup

Set Resource Limits

Always set memory and CPU limits in production to prevent one container from starving others:

# In docker-compose.yml
"code-token-key">services:
"code-token-key">  app:
"code-token-key">    deploy:
"code-token-key">      resources:
"code-token-key">        limits:
"code-token-key">          cpus: "0.50"
"code-token-key">          memory: 512M

Use Health Checks

Define a health check so Docker knows when your container is actually ready to serve traffic, not just started:

HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

Persist Data with Named Volumes

Container filesystems are ephemeral, they disappear when the container is removed. For databases and any stateful data, always use named volumes:

"code-token-key">volumes:
"code-token-key">  postgres-data:
"code-token-key">
services:
"code-token-key">  db:
"code-token-key">    volumes:
      - postgres-data:/var/lib/postgresql/data

Step-by-Step: Setting Up Docker on a VPS

This walkthrough uses Ubuntu 22.04 or 24.04 LTS, the most common VPS OS. Adapt the package commands for other distributions as needed.

Prerequisites

• A VPS with at least 1 vCPU and 1 GB RAM (2 GB recommended)
• Ubuntu 22.04 or 24.04 LTS
• A non-root user with sudo privileges
• SSH access to your server

Step 1: Update the System

sudo apt update && sudo apt upgrade -y

Always start with a fully updated system before installing new software.

Step 2: Install Required Dependencies

sudo apt install -y ca-certificates curl gnupg lsb-release

These packages are needed to securely add Docker's official apt repository.

Step 3: Add Docker's Official GPG Key and Repository

# Create the directory for apt keyrings
sudo install -m 0755 -d /etc/apt/keyrings

# Download and store Docker's GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Make the key readable
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

You're adding Docker's official repository, not the potentially outdated version in Ubuntu's default repos. This ensures you get the current, stable release.

Step 4: Install Docker Engine and Docker Compose

sudo apt update

sudo apt install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

This installs:

• docker-ce, the Docker Engine daemon
• docker-ce-cli, the docker command-line client
• containerd.io, the container runtime Docker uses under the hood
• docker-buildx-plugin, extended build capabilities
• docker-compose-plugin, the modern docker compose (v2) plugin

Step 5: Verify the Installation

sudo docker run hello-world

You should see a message starting with "Hello from Docker!" confirming the engine is working.

# Check the Docker version
docker --version

# Check Docker Compose version
docker compose version

Step 6: Add Your User to the Docker Group

By default, running docker requires sudo. Add your user to the docker group to run Docker commands without sudo:

sudo usermod -aG docker $USER

Log out and back in (or run newgrp docker) for the group change to take effect.

# Verify, this should work without sudo
docker ps

Security note: Users in the docker group can effectively gain root access to the host through Docker. Only add trusted users to this group.

Step 7: Configure Docker to Start on Boot

sudo systemctl enable docker
sudo systemctl enable containerd

This ensures Docker starts automatically when the VPS reboots.

# Verify both services are running
sudo systemctl status docker
sudo systemctl status containerd

Step 8: Configure the Docker Daemon (Optional but Recommended)

Create or edit /etc/docker/daemon.json to configure logging limits and other sensible defaults:

sudo nano /etc/docker/daemon.json

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true
}

• log-driver + log-opts, Caps container log files at 10 MB with a maximum of 3 rotated files. Without this, logs can fill your disk.
• live-restore, Keeps containers running if the Docker daemon crashes or is restarted during an update.

Apply the changes:

sudo systemctl daemon-reload
sudo systemctl restart docker

Step 9: Deploy a Test Application with Docker Compose

Let's put it all together. Create a directory for a test Nginx deployment:

mkdir ~/test-app && cd ~/test-app

Create a docker-compose.yml:

nano docker-compose.yml

"code-token-key">version: "3.9"
"code-token-key">
services:
"code-token-key">  web:
"code-token-key">    image: nginx:1.25-alpine
"code-token-key">    container_name: nginx-test
"code-token-key">    restart: unless-stopped
"code-token-key">    ports:
      - "80:80"
"code-token-key">    volumes:
      - ./html:/usr/share/nginx/html:ro

Create a simple HTML page:

mkdir html
echo "<h1>Docker is working on my VPS!</h1>" > html/index.html

Start it:

docker compose up -d

Visit your VPS's IP address in a browser. You should see your HTML page served by Nginx running in a container.

Step 10: Useful Maintenance Commands

# View all running containers
docker ps

# View resource usage
docker stats

# View disk usage by Docker objects
docker system df

# Clean up stopped containers, unused networks, dangling images, and build cache
docker system prune

# Clean up everything including unused volumes (destructive, use carefully)
docker system prune -a --volumes

# View logs for a container
docker logs nginx-test -f

# Inspect a container's configuration
docker inspect nginx-test

What's Next

You now have Docker installed, understand the core concepts, and know the best practices that separate production setups from tutorial demos. Here's where to go from here:

Deepen your Compose skills, Learn how to use .env files for environment variable management, override files (docker-compose.override.yml) for dev vs prod differences, and profiles for optional services. If you document Compose files in a team guide, a quick pass through BuildQuill's YAML Validator can catch indentation mistakes before they reach a server.

Set up a reverse proxy, For running multiple apps on one VPS, use Nginx Proxy Manager or Traefik as a reverse proxy container that routes traffic to your other containers by domain name and handles SSL automatically.

Explore Docker networking, Understand bridge, host, and overlay networks. Learn how containers communicate by service name (DNS-based discovery) within a Compose network.

Learn about container orchestration, For larger deployments, look into Docker Swarm (simpler, built-in) or Kubernetes (industry standard for large-scale production).

Scan your images for vulnerabilities, Use docker scout cves my-image:tag or integrate Trivy into your CI pipeline to catch security issues before they reach production.

Set up a private registry, If you're building proprietary software, consider hosting your own registry or using a private repository on GitHub Container Registry or a cloud provider.

Docker is one of the highest-leverage tools in a developer's kit. The learning curve is real but short, a few hours of hands-on practice with the concepts in this guide and you'll be building multi-service applications with confidence. The investment pays for itself the first time you onboard a new developer with docker compose up and have them running the full stack in under two minutes.