Before Docker: The Hidden Ecosystem That Invented Containers

Most developers today assume containers began with Docker’s 2013 launch. They couldn’t be more wrong. Docker didn’t invent containers — it gave them a slick UI and a marketing team. The real story of containers stretches back decades, involving engineers who solved problems most people didn’t know existed yet.

The 1970s: chroot Plants the Seed

The first container-like isolation appeared in 1979 with Version 7 Unix’s chroot system call. chroot let you change the root directory for a process, effectively creating a filesystem jail. A process running inside a chroot couldn’t see the real filesystem outside it.

Practical use cases were humble — testing software safely, running FTP servers without exposing the whole OS. But the principle was radical: one kernel could host multiple isolated environments. The idea sat dormant for over twenty years.

FreeBSD Jails (2000): The Real Breakthrough

The first true container implementation came from FreeBSD developer Poul-Henning Kamp. His 2000 paper “The FreeBSD Jails” described something revolutionary: an environment with its own filesystem, network stack, process table, and user accounts — all sharing a single kernel.

Jails weren’t just filesystem isolation. They gave each environment its own IP address, its ownhostname, and independent root access. A jail administrator could do anything inside their jail, but couldn’t touch the host or other jails. This was containerization years before Linux caught up.

Why didn’t jails take over the world? Licensing. BSD’s permissive license made jails available but didn’t create the ecosystem Docker later built. And Linux was already winning the server OS war.

Linux VServer and OpenVZ (2001–2005)

Linux developers independently reinvented containers. Linux VServer (2001) added security labels and process isolation. OpenVZ (2005) went further — it created templates and allowed live migration of containers between hosts. Both required custom kernel patches.

These were production-ready tools. Hosting companies used OpenVZ to sell “virtual private servers” that were essentially containers. You could upgrade RAM and disk without reinstalling. But the patched kernel requirement was a deal-breaker. Enterprise sysadmins refused to run non-standard kernels in production.

Solaris Zones (2005): The Forgotten Gold Standard

Sun Microsystems shipped Solaris Zones in 2005, and it was arguably more complete than anything we have today. Zones offered:

• Full filesystem isolation with ZFS snapshots
• Network isolation with virtual NICs
• Resource limits per zone (CPU, memory, disk)
• Branded zones — run Linux binaries inside a Solaris zone without modification

Solaris Zones had global and local zone administrators, delegated administration, and live migration. They solved problems Docker struggles with today. But Solaris lost the server war. No one cared about a perfect container system on a dying platform.

Control Groups (cgroups): The Missing Piece

By 2006, Google engineer Paul Menage contributed the first version of cgroups to the Linux kernel. Finally, Linux could limit, account for, and isolate CPU, memory, and I/O per process group — without custom kernel patches.

cgroups arrived in the 2.6.24 kernel (2008) and changed everything. Suddenly, any Linux distribution could do resource-constrained isolation. But without a user-friendly interface, cgroups remained a command-line curiosity.

LXC (2008): Docker’s Direct Ancestor

LXC (Linux Containers) combined cgroups with namespace isolation to create the first native Linux container system. It didn’t need kernel patches. You could create a container that felt like a lightweight VM, sharing the host kernel.

LXC had everything: templates to create root filesystems, networking bridges, and snapshot support. But it lacked portability. Containers tied to specific kernel versions. Dependencies tangled. And the only way to share containers was through source control patches or tarballs.

The DotCloud Era (2010–2013)

Here’s where Docker’s origin story gets complicated. DotCloud was a platform-as-a-service startup founded by Solomon Hykes. Like Heroku, it ran customer applications in isolated environments. DotCloud used cgroups and namespaces directly, building their own internal container management system.

By 2010, DotCloud had multiple Python, Ruby, and PHP customers running in isolated containers. They also wrote libcontainer — a library for interacting with kernel container features. But DotCloud was failing. Heroku dominated the PaaS market. DotCloud needed a new direction.

Docker: Not The Invention, But The Innovation

Docker’s 2013 release didn’t invent container technology. It solved three critical problems the earlier systems never addressed:

1. Image layering — Docker didn’t invent union filesystems (AUFS existed since 2006), but it was the first system to combine layered images with container lifecycle management. You built a Dockerfile, and it produced a shareable artifact.

2. Registry and distribution — Docker Hub launched with the Docker Engine. No other container system had a centralized registry. LXC required ftp servers. Jails required NFS mounts. Docker made docker pull as easy as git clone.

3. Standardized container format — Docker defined how containers should be built, transported, and run. Before Docker, every hosting provider had their own template format. Docker broke that fragmentation.

What Docker Really Contributed

The kernel features were all there. The technology was mature. But Docker contributed ecosystem, tooling, and — most importantly — developer experience.

Docker’s docker-compose (2014) let developers define multi-container applications in YAML. The Docker API became an industry standard. Kubernetes (2014) built on Docker’s container runtime, and later CRI-O and containerd (Docker’s own runtime) continued the evolution.

The Containers You Use Today Aren’t Docker

Here’s the secret the industry has forgotten: Docker’s own runtime, containerd, has been the standard since 2015. Docker Inc. donated containerd to the CNCF in 2017. When you run containers on Kubernetes with CRI-O or containerd, you’re not running “Docker containers” — you’re running OCI-compliant containers that just happen to use the same image format Docker popularized.

The underlying technology traces back to chroot (1979), jails (2000), cgroups (2006), and LXC (2008). Docker gave it packaging, distribution, and hype.

The Takeaway

The history of containers isn’t a story of one company’s genius invention. It’s the story of decades of incremental innovation by engineers solving real problems — BSD jail builders, Solaris architects, Linux kernel developers — whose work Docker finally made accessible.

The next time someone says “containers are a Docker invention,” remind them that containers were running in production before half the engineers on your team learned to write code. Docker didn’t start the fire — it just doused it in gasoline and gave it a logo.