A container packages your application with everything it needs — code, runtime, libraries, settings — into a portable unit that runs identically anywhere Linux runs.
Before containers, "it works on my machine" was a genuine problem. Containers make the environment part of the artifact, so deployments are reproducible.
What a container actually is
Under the hood, containers are regular processes with isolated namespaces and constrained resources. They are not virtual machines.
- Containers share the host kernel (no separate OS per app).
- They boot in milliseconds instead of minutes.
- They use fewer resources and start faster.
The common confusion: a container is not a lightweight VM. It is an isolated process. That is why it is so efficient — and why it cannot run a different OS than the host.
What Docker adds
Docker provides the tooling: a way to describe your container (Dockerfile), build it, run it, and share images via registries like Docker Hub.
- Dockerfile: the recipe.
- Image: the frozen artifact.
- Registry: the storage for sharing images.
- Container: the running instance.
When to use containers
Containers shine when you need consistency across environments, or when you want portability between clouds. If you run a single app on a single server with no scaling, they add little.
# A minimal Node.js container
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["npm", "start"]Containers FAQ
Do containers improve security?
They improve isolation, but running as root inside a container is still a risk. Combine containers with least-privilege users and read-only root filesystems.
Should I containerize my existing app?
If deployments are painful or environments drift, yes. If your app runs fine in one place, the immediate benefit is small.
