Containers as standard packaging. Why "works on my machine" is no longer an argument.
Category · DevOps & Infra
What Docker is.
Docker packages an application along with all its dependencies — runtime, libraries, configuration — into a self-contained image. That image runs identically on any host, whether it's a laptop, a CI runner or a production server.
Unlike a virtual machine, a container doesn't carry its own operating system but shares the host's kernel. That makes it lightweight: seconds rather than minutes to start, megabytes rather than gigabytes.
Why we containerise consistently.
Every product we build and operate runs in a container. That makes the environment part of the code — "works on my machine" is no longer an argument, because the environment is the same everywhere.
It cuts the onboarding effort for new developers down to a "docker compose up" and makes deployments reproducible. That's exactly what we need for traceable, auditable operational chains.
Where the limit lies.
Docker solves packaging, not orchestration. Once several containers have to scale across machines, run with failover and be replaced automatically, you need a layer above — usually Kubernetes.
For a single server with a handful of services, Docker Compose is enough. Only the load and the availability requirement decide whether more is needed.
