What a container is
A container is an ordinary process that the operating system kernel isolates from the rest of the machine. It gets its own view of the filesystem, process list, network and users, plus limits on how much CPU and memory it can use. Docker is a set of tools for building container images and running containers from them.
On Linux, the isolation comes from two kernel features. Namespaces control what a process can see, and cgroups (control groups) control how much it can use. Nothing is emulated, so a container starts about as fast as the program inside it.
Linux containers need a Linux kernel. On macOS and Windows, Docker Desktop runs them inside a small Linux virtual machine.
Containers vs virtual machines
A virtual machine (VM) emulates a whole computer. A hypervisor gives each VM virtual hardware, and the VM boots its own operating system with its own kernel. Containers on one host all share the host's kernel, which leads to three practical differences.
- A VM image includes a full operating system, while a container image holds only the program and the files it depends on. Containers are smaller and start faster.
- A VM can run a different operating system from its host, such as Windows on a Linux server. A container can only use the kernel the host already runs.
- A VM is the stronger security boundary. Containers share the host kernel, so one kernel flaw can expose the host and every container on it. Platforms that run code from many customers often wrap containers in VMs for that reason.
Images, layers and containers
An image is a read-only template: a stack of filesystem layers plus settings such as the default command, environment variables and the user to run as. A container is a running instance of an image, with a thin writable layer on top.
Each Dockerfile instruction that changes files, such as RUN, COPY or ADD, adds a layer. Layers are identified by a hash of their content, so images built on the same base image share those layers on disk and in the registry.
Docker caches layers during builds. When an instruction or the files it copies change, that layer and every layer after it rebuild. Put the steps that change least, like installing dependencies, before the steps that change most, like copying your source code.
Anything a container writes to its writable layer disappears when the container is removed. Data that must survive belongs in a volume.
A small Dockerfile for a Node.js service
This Dockerfile uses a multi-stage build. The first stage installs every dependency and compiles the app. The second starts again from a clean base image, installs only the production dependencies and copies in the built output.
Copying package.json and the lockfile before the source code means the npm ci layer comes from the cache until dependencies change. USER node switches to the unprivileged user that the official Node.js images include. EXPOSE only documents the port, so you still publish it at run time, for example with docker run -p 3000:3000.
The build stage copies the whole build context, so add a .dockerignore file that excludes .git, node_modules and any .env files.
# Build stage: install all dependencies and compile
FROM node:24-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
# Runtime stage: production dependencies and built output only
FROM node:24-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]Image hygiene for production
These habits keep images smaller, easier to patch and harder to misuse.
- Start from a small base image, such as an Alpine, slim or distroless variant. Fewer packages mean fewer known vulnerabilities to patch and faster pulls. Alpine uses musl instead of glibc, which breaks some native modules, so test before you switch.
- Pin versions. Use a base image tag with at least a major version, never latest, and pin by digest when a build has to be exactly repeatable. Install dependencies from a lockfile.
- Rebuild regularly. A pinned image gets no security fixes until you update the pin and rebuild, so schedule rebuilds and scan images for known vulnerabilities in CI.
- Keep secrets out of the image. Anything written to a layer stays in the image even if a later step deletes it, and anyone who can pull the image can extract it. Build arguments and ENV values persist in the image too.
- Pass build-time secrets with a secret mount (RUN --mount=type=secret), and runtime secrets as environment variables or mounted files when the container starts.
- Run as a non-root user with the USER instruction. Unless the host uses rootless mode or user namespace remapping, root inside a container is user ID 0 on the host kernel. That makes any escape far more serious.