General
The Prehistory of Containers: What Existed Before Docker
Explore the decades-long evolution of containerization, from the 1979 chroot system call and FreeBSD Jails to the Linux kernel features that eventually made Docker possible.
June 2026 · 6 min read · 3 views · 0 hearts
Advertisement
The Prehistory of Containers: What Existed Before Docker
If you think containers started with Docker, you're missing the fascinating story of the decades-long evolution that made Docker possible. The technology that revolutionized software deployment didn't spring fully formed from a GitHub repository in 2013 — it was the culmination of ideas stretching back to the mainframe era.
The Chroot: Unix's First Isolation Trick (1979)
Before there were containers, there was chroot. Introduced in Version 7 Unix, this humble system call let you change the root directory for a process, effectively jailing it inside a subtree of the filesystem. It was primitive — processes could still see each other, network interfaces were shared, and a process with root privileges could easily break out. But it planted the seed: isolation was possible.
FreeBSD Jails (2000): The First Real Containers
FreeBSD developers needed something better. In 2000, they introduced Jails — the first production-ready containerization solution. A jail created a complete virtualized environment with its own filesystem, network stack, and process tree. Unlike chroot, jails were secure by design: even root inside a jail couldn't access the host system.
Jails solved a real problem: hosting providers needed to give customers isolated environments without the overhead of full virtualization. Jails were lightweight, fast to create, and reasonably secure. They're still in use today, though largely overshadowed by Linux alternatives.
Solaris Zones (2004): Containers Go Enterprise
Sun Microsystems took the jail concept and polished it into a commercial product. Solaris Zones (also called Containers) offered a complete application environment with fine-grained resource control. You could allocate CPU shares, memory limits, and network bandwidth per zone — features that Docker wouldn't popularize for another decade.
Solaris Zones were impressive, but they were tied to Solaris. And Solaris was losing the server market to Linux.
Linux-VServer and OpenVZ (2001-2005): Patching the Kernel
The Linux community wanted the same capabilities. Linux-VServer (2001) and OpenVZ (2005) both used kernel patches to add process-level virtualization. They worked well — hosting companies used OpenVZ extensively — but they required custom kernels. You couldn't just install OpenVZ on a standard Linux distribution. This was a dealbreaker for many sysadmins.
cgroups: The Game-Changer That Almost No One Noticed (2007)
In 2006, Google engineers Paul Menage and Rohit Seth started work on process containers for the Linux kernel. The name was changed to "control groups" (cgroups) after some trademark concerns. By 2007, cgroups were merged into the mainline Linux kernel — no patches required.
Cgroups let you limit, account for, and isolate resource usage (CPU, memory, disk I/O, network) for groups of processes. Combined with Linux namespaces (which had been gradually added to the kernel since 2002), the kernel now had all the pieces for containers: namespace isolation for process IDs, network, mounts, and UTS (hostname), plus cgroups for resource control.
The problem? These features were raw. There were no user-friendly tools, no standard way to create or manage them. You had to write C code or script against /proc and /sys filesystems. It was powerful, but only kernel developers and a few DevOps pioneers were using it.
LXC: The Missing Link (2008)
LXC (Linux Containers) was the first project to package cgroups and namespaces into a usable tool. Released by IBM's Daniel Lezcano and others, LXC gave you a command-line interface (lxc-create, lxc-start) to spin up containers. It was close to what we think of as containers today — lightweight, fast, and using only kernel features.
LXC gained adoption in some circles, but it had problems. It wasn't easy to use consistently across distributions. More critically, there was no standardized packaging format. Each container was a snowflake, set up differently by different admins. You couldn't just download and run a container image.
Warden: Cloud Foundry Gets Creative (2011)
VMware's Cloud Foundry platform needed process isolation for running apps. They looked at LXC but found it too restrictive and inconsistent. So they built Warden — an abstraction layer that could use LXC, or fall back to simpler methods like BSD jails, or even run on Windows.
Warden introduced a client-server architecture for managing containers. It had a REST API for creating, destroying, and monitoring containers. This was a significant architectural improvement over raw LXC. But Warden was designed specifically for Cloud Foundry; it wasn't intended as a general-purpose container tool.
Docker: The Right Time, The Right Abstraction
When Solomon Hykes and the dotCloud team started working on Docker in 2012, they weren't inventing containment — they were packaging the best existing ideas into a developer-friendly tool.
What Docker did differently:
- Standardized packaging: The Dockerfile and image layers let you define and share containers consistently
- Image registries: Docker Hub made container images as easy to distribute as npm packages
- Developer-first tooling:
docker build,docker push,docker run— simple commands that worked - Union filesystems: AUFS and later overlayfs made image layering practical and efficient
Docker didn't invent containers. It made them usable.
The Verdict
The container revolution was decades in the making. From chroot to jails to zones to cgroups to LXC to Docker — each step added a piece of the puzzle. Docker's genius wasn't technical innovation but design simplification. It took a powerful but arcane kernel feature and turned it into a tool that a junior developer could understand in an afternoon.
Today's Kubernetes clusters are built on the same foundations. The kernel features are the same (though more mature). The isolation model is the same. But the tooling, the distribution, and the ecosystem are unrecognizable from the pre-Docker era.
So next time someone says "containers started with Docker," you can smile knowingly. Containers started with Ken Thompson in 1979 — it just took 34 years for the rest of us to catch up.
Advertisement
Comments
Questions, corrections, and tips stay visible for everyone reading this page.
Join the discussion
No comments yet
Be the first to leave a note — it helps the next reader.