Docker for Web Developers: A Practical Guide

Docker Changed Everything

Before Docker, deploying an application meant writing lengthy setup scripts, managing dependency conflicts between environments, and hearing the dreaded phrase "but it works on my machine." Docker solved this by packaging applications with their entire runtime environment into portable, reproducible containers.

For web development teams, Docker is no longer optional knowledge — it is foundational infrastructure. At The Beyond Horizon, every production project runs in containers. Here is our practical guide to using Docker effectively for web applications.

Understanding Docker Concepts

Image: A read-only template containing your application code, runtime, libraries, and OS dependencies. Think of it as a snapshot of a configured machine.

Container: A running instance of an image. Multiple containers can run from the same image simultaneously, each isolated from the others.

Dockerfile: Instructions for building an image. Each instruction creates a layer that is cached — rebuild only changes.

Docker Compose: Defines multi-container applications. Your web app, database, and Redis cache described in one YAML file.

Writing an Efficient Dockerfile for Next.js

The naive approach copies everything and installs everything. The result is a 1.5GB image that takes 5 minutes to build. A production Dockerfile should produce a 200MB image that builds in under 60 seconds on cache hits.

Key principles for an efficient Next.js Dockerfile:

Docker Compose for Local Development

A typical web application needs more than just the app server. You need a database, possibly a cache, maybe a queue. Docker Compose spins up the entire stack with one command.

A practical docker-compose.yml for a Next.js application includes:

Environment variables are loaded from .env files, ports are mapped to localhost, and services declare dependencies to ensure correct startup order.

Docker in CI/CD Pipelines

Docker standardizes your build environment. Whether a developer builds on macOS, the CI runs on Ubuntu, and production runs on Debian — the Dockerfile guarantees identical results.

In our GitHub Actions pipelines:

1. Build the image with build args for environment-specific configuration

2. Run tests inside the container to ensure they pass in the production environment

3. Push to a registry (GitHub Container Registry, Google Artifact Registry, or DockerHub)

4. Deploy by pulling the image on the production server or updating the Kubernetes deployment

Build caching with GitHub Actions cache or Docker layer caching reduces CI build times from 5 minutes to under 1 minute for code-only changes.

Common Docker Mistakes

Mistake 1: Using latest tag in production. If the base image updates with a breaking change, your next deployment breaks. Always pin specific versions like node:20.11-alpine3.19.

Mistake 2: Ignoring .dockerignore. Without it, node_modules, .git, and local env files are copied into the build context — slowing builds and potentially leaking secrets.

Mistake 3: Running as root. A container escape vulnerability with root access gives the attacker root on the host. Always create and use a non-root user.

Mistake 4: Not using health checks. Without health checks, orchestrators cannot detect when your application is unhealthy. Add a HEALTHCHECK instruction that hits your app's health endpoint.

Mistake 5: Fat images. Alpine-based images are 5x smaller than Debian-based ones. A smaller image means faster pulls, faster deployments, and a smaller attack surface.

When to Use Kubernetes

Docker Compose is perfect for single-server deployments and local development. When you need:

That is when Kubernetes enters the picture. But for 90% of web applications, Docker Compose on a single server or a managed container service (Google Cloud Run, AWS ECS, Railway) is sufficient and far simpler.

We help clients choose the right level of infrastructure complexity. Want to containerize your application? Talk to us.