Container
A container is a way to package an application and its runtime dependencies into an isolated execution unit. It looks like a small server from the outside, but internally it runs as isolated processes that share the host kernel.
βΆArchitecture Diagram
π StructureDashed line animations indicate the flow direction of data or requests
The same application often behaves differently across laptops and servers because OS packages, library versions, and environment variables drift. Once teams start configuring servers by hand, those differences accumulate and deployments become harder to reason about. The more often you ship, the more painful environment mismatch becomes.
Traditional server deployment installed packages directly onto machines. Virtual machines improved reproducibility, but they also copied entire guest operating systems and paid a startup and size penalty. Containers became attractive because teams wanted strong application boundaries without carrying a full OS per workload.
A container starts from an image's read-only layers and adds a thin writable layer at runtime. Namespaces keep processes, mounts, and network views separated, while cgroups limit resource usage. That is why a container feels like its own machine even though it is really a set of isolated processes on one kernel.
Containers and Linux namespaces or cgroups are related but not identical. A container is the operational unit developers and operators work with. Namespaces and cgroups are the kernel mechanisms that make that unit look isolated.
In practice, containers are most useful for workloads with a clear deployment boundary, such as web APIs, background workers, and batch jobs. Logs and short-lived caches can stay inside the container, but uploads, database files, and other state that must survive replacement need to live in volumes or external storage. The real operational skill is deciding what can be rebuilt from the image and what must remain outside the container lifecycle.