Containers and Isolation: How One Machine Keeps Many Apps Apart

When you run a container, it really does feel like a tiny, self-contained computer. It has its own files, its own processes, its own network address, its own idea of what’s installed. Look inside and you’d swear you were on a separate machine. But you’re not — you’re sharing the same physical computer, and the same operating system kernel, with every other container running next to you. That trick is called isolation, and it’s the single idea that makes containers worth using.

The whole reason a container can be small, fast, and disposable is that it doesn’t carry a full operating system around. Instead, it borrows the host’s kernel and just asks it to draw some walls. This article is about those walls: what they’re made of, what they actually keep separate, and — just as important — where they’re thinner than people assume.

What “isolation” actually means

Isolation is the property that lets several programs run on one machine while behaving as if each one had the machine to itself. A well-isolated container believes its filesystem is the only filesystem, its processes are the only processes, and its slice of CPU and memory is the whole pie. None of that is true — it’s all an illusion the kernel maintains on purpose.

Picture an apartment building. Everyone shares the same foundation, the same plumbing, the same power grid coming in from the street. But each apartment has its own locked door, its own rooms, its own mailbox. You can live your whole life inside your unit without ever bumping into your neighbors, even though you’re all in one structure. A container is an apartment. The kernel is the building.

This is the heart of the difference between a container and a virtual machine. A VM brings its own entire operating system and pretends to be its own building. A container shares the host’s kernel and is just a sealed-off apartment inside it. If that distinction is still fuzzy, it’s worth reading containers vs virtual machines first — this article picks up right where that one leaves off and goes a level deeper into how the apartment walls get built.

The kernel features that do the work

Containers aren’t a single feature you install. They’re a combination of plain Linux kernel capabilities that have existed for years, packaged together so they’re easy to use. The two that matter most are namespaces and cgroups.

Namespaces — controlling what a process can see

A namespace changes what a process is allowed to perceive. Normally every process on a machine sees the same global list of processes, the same network interfaces, the same mount points. A namespace gives a process its own private version of one of those lists.

There are several kinds, and each one isolates a different dimension:

• PID namespace — its own process tree. Inside, the container’s first process is PID 1, and it can’t even see processes outside its namespace. To the container, the rest of the machine simply doesn’t exist.
• Mount namespace — its own view of the filesystem. The container sees its own root directory and its own mounts, not the host’s.
• Network namespace — its own network stack: its own interfaces, IP addresses, and routing table. This is why a container can listen on port 80 internally without colliding with the host or another container.
• UTS namespace — its own hostname.
• User namespace — its own mapping of user IDs, so “root inside the container” can be a harmless, unprivileged user on the host.
• IPC namespace — its own channel for inter-process communication, so containers can’t message each other’s processes through shared memory.

Stack those together and a process genuinely believes it’s alone. It can’t list outside processes, can’t see outside files, can’t touch outside network interfaces — not because it’s politely choosing not to, but because the kernel never shows them to it.

        ONE LINUX KERNEL  (shared by all)
 ┌──────────────────────────────────────────────┐
 │  Container A          Container B             │
 │  ┌──────────────┐     ┌──────────────┐        │
 │  │ PID ns: 1,2  │     │ PID ns: 1,2  │  ← each thinks
 │  │ mount ns: /  │     │ mount ns: /  │    it owns PID 1
 │  │ net ns: eth0 │     │ net ns: eth0 │    and the root /
 │  └──────────────┘     └──────────────┘        │
 │        ▲                     ▲                │
 │        └────── same kernel ──┘                │
 └──────────────────────────────────────────────┘

Cgroups — controlling what a process can use

Namespaces decide what a process can see. Control groups (cgroups) decide what it can consume. A namespace stops Container A from looking at Container B; a cgroup stops Container A from eating all the CPU and starving Container B.

A cgroup lets the host put hard limits on a group of processes:

• CPU — “this container may use at most half of one core.”
• Memory — “this container gets 512 MB; if it asks for more, it gets killed instead of dragging the whole machine down.”
• I/O — caps on how much disk read/write bandwidth a container can hog.
• Process count — a ceiling on how many processes it can spawn, which blocks a runaway loop from forking until the machine falls over.

Without cgroups, one badly behaved container could consume every resource and take down everything else on the box. Cgroups are what make it safe to pack dozens of containers onto a single server and trust that no single one can ruin the party. If the words “process” and “limit” feel shaky, the article on processes and services lays that groundwork.

The filesystem — its own private root

The last big piece is the filesystem. Through the mount namespace plus a feature called chroot-style root changing, each container is handed its own root directory. What looks like / inside the container is actually just a folder on the host, presented as if it were the top of the world.

That private root is built from the container’s image — the read-only template the container starts from. The image supplies a minimal set of files (a shell, some libraries, your app), and the container runs as if that’s the entire system. Because the image is read-only, the container adds a thin writable layer on top for any changes it makes, and that layer vanishes when the container is destroyed. This is why containers are disposable: nothing inside survives unless you deliberately store it outside.

What isolation does — and does not — protect you from

Here’s where a lot of beginner intuition goes wrong. Containers feel like sealed boxes, so people assume they’re as separate as two different physical machines. They’re not, and the gap matters.

What isolation handles well:

• Two apps that need conflicting versions of the same library can run side by side, each with its own files, never aware of the other.
• A crash, a memory leak, or a runaway process in one container stays inside that container’s limits and doesn’t take down its neighbors.
• Each container gets its own network identity, so port clashes and naming collisions mostly disappear.
• Wiping a container is clean and complete — when its writable layer is deleted, it leaves nothing behind on the host.

Where the walls are thinner than they look:

• The kernel is shared. Every container talks to the same kernel. A serious flaw in the kernel could, in theory, let a process in one container affect the host or another container. A VM doesn’t share its kernel, which is why VMs are still considered a stronger security boundary.
• “Root” inside isn’t nothing. Unless you use a user namespace to remap it, the root user inside a container can be uncomfortably close to root on the host. Running containers as a non-root user is one of the simplest, most effective hardening steps.
• Isolation is configurable, and defaults vary. You can deliberately poke holes — share the host’s network, mount a host directory, grant extra privileges. Each of those trades isolation for convenience, and it’s easy to give away more than you meant to.

The honest takeaway: containers give you excellent operational isolation — apps don’t trip over each other, and resources stay fenced. As a security boundary they’re good but not airtight, because everyone shares one kernel. For untrusted or hostile workloads, people add extra layers (stricter sandboxes, or full VMs underneath) precisely because of that shared kernel.

  ISOLATION STRENGTH (rough mental model)

  separate machines   ████████████████  strongest
  virtual machines    ██████████████
  containers          █████████          good, shared kernel
  same process        ██                 weakest

A mental model you can keep

When you’re reasoning about a container, ask three questions, one per mechanism:

1. What can it see? That’s namespaces. Its own processes, its own filesystem, its own network — separate views onto one machine.
2. What can it use? That’s cgroups. A capped slice of CPU, memory, and I/O, so no single container can starve the rest.
3. What is it built from? That’s the image and its read-only root, plus a throwaway writable layer that makes the container disposable.

Get those three straight and almost every container behavior stops being mysterious. Why is a container so much lighter than a VM? Because it skips the second operating system and just borrows the host’s kernel. Why does data disappear when a container restarts? Because the writable layer is temporary by design. Why isn’t a container a perfect security wall? Because the kernel underneath is shared.

Wrapping up

Here’s the whole picture in one place:

• Isolation is the illusion that each container has the machine to itself, maintained by the kernel on purpose. It’s the core idea that makes containers useful.
• It isn’t one wall but many independent mechanisms working together — see, use, and build-from.
• Namespaces control what a process can see: its own processes, filesystem, network, hostname, and user IDs.
• Cgroups control what a process can use: hard caps on CPU, memory, I/O, and process count.
• Each container gets its own private root filesystem from a read-only image, plus a disposable writable layer — which is why containers are lightweight and throwaway.
• Isolation is great for keeping apps from stepping on each other, but because the kernel is shared, it’s a weaker security boundary than a full virtual machine — something to respect when running untrusted code.

Next, it helps to see how these isolated little worlds actually talk to each other and to the outside, which is exactly what container networking is about — how separate network namespaces get wired together into something that works as a system.