Containerisation is the practice of packaging an application together with all its dependencies — code, runtime, libraries, configuration — into a self-contained unit called a container. That container runs the same way regardless of where it’s deployed: a developer’s laptop, a test server, or a production cloud environment.
Docker is the most widely used containerisation platform. Kubernetes is the most widely used system for managing (orchestrating) containers at scale.
You’ll hear this when…
“We containerised it” means the team packaged the application so it can run consistently anywhere. “Running in a container” means the software is isolated from the host system and from other applications.
Containerisation comes up in infrastructure discussions, deployment planning, and cloud migration projects. It’s especially relevant for microservices architectures, where each service runs in its own container.
“Container image” is the blueprint; “container” is a running instance of that image. “Container registry” (Docker Hub, AWS ECR, GitHub Container Registry) is where images are stored and shared.
Containers vs. virtual machines
Both provide isolation, but containers are lighter. A virtual machine runs a full operating system; a container shares the host OS kernel and only packages the application layer. This makes containers faster to start, smaller to store, and more efficient to run at scale.
Source: Docker documentation — containerisation overview