The short version
The oldest problem in software: "it works on my machine." Your laptop has specific versions of languages, libraries, and tools installed. The server has different ones. Things break. Containers solve this by packaging the app, its dependencies, and its configuration into a single unit that runs the same way everywhere.
Docker is the most common container tool. When someone says "we'll containerise it," they usually mean wrapping it in a Docker image.
How it works
A container starts with a Dockerfile, a text file that describes how to build the environment:
FROM node:20
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["node", "server.js"]
This says: start with Node.js 20, copy the project files, install dependencies, and run the server. When you build this Dockerfile, it creates an image, a snapshot of that environment. When you run the image, it creates a container, a live instance of the app.
Key concepts:
- Image: the blueprint. Built once, stored in a registry (like Docker Hub).
- Container: a running instance of an image. You can run many containers from the same image.
- Registry: where images are stored and shared. Docker Hub is the most common public one.
- Layers: each instruction in a Dockerfile creates a layer. Layers are cached, so rebuilds are fast when only your code changes (not your dependencies).
Containers are lighter than virtual machines. A VM emulates an entire operating system. A container shares the host's OS kernel and only isolates the app layer. This makes containers faster to start and cheaper to run.
Why it matters
If you deploy anything to Railway, Render, or most cloud platforms, your app is probably running in a container already. Understanding what a Dockerfile does means you can debug deployment failures, optimise build times, and reduce costs by making your images smaller.