Why Docker Isn’t the Only Way: Uncovering Simple Linux Container Alternatives

1. Docker containers aren’t mysterious

Linux containers rely on two kernel features—namespaces and cgroups. By creating a new namespace instance and assigning a process to a cgroup, you obtain an isolated environment that functions like a container. The manual pages man 7 namespaces and man 7 cgroups provide clear explanations, and tools such as nsenter and unshare serve as minimal wrappers for the required system calls.

2. Building containers with Docker is redundant

Docker’s image‑building step merely assembles a filesystem tree from a Linux distribution, a process that has been performed for decades with package managers. The same result can be achieved with commands like:

debootstrap focal /srv/trees/ubuntu

debootstrap stable /srv/trees/debian

dnf -y --releasever=33 --installroot=/var/lib/machines/f33 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install systemd passwd dnf fedora-release vim-minimal glibc-minimal-langpack

pacstrap /srv/trees/arch

These commands construct chroot environments that Docker later packages. Updating software (e.g., a newer Node.js version) can be handled via distribution backports or by building custom packages, eliminating the need for Dockerfiles in many cases.

3. Deployment isolation is not new

The isolation provided by containers mirrors the long‑standing chroot technique. By changing the root directory of a process, administrators can present a completely separate filesystem hierarchy, libraries, and binaries. This approach has been used for development, QA, and production environments for decades, and Docker’s claim of novelty is therefore overstated.

4. Docker provides little security by default

Docker’s primary security benefit is network isolation—preventing containers from binding to host ports. However, the same effect can be achieved with host firewalls. Running containers as root further reduces security, and many namespace‑based containers inherit known privilege‑escalation vulnerabilities. Docker does not enable non‑privileged execution by default, unlike traditional chroot setups that often run as unprivileged users.

5. Application containers are absurd

The term “application container” adds no technical value; it is essentially a lightweight virtual machine that isolates a single service. Issues such as zombie/orphan processes, missing init systems, and absent syslog/cron daemons persist unless additional tooling is added. In practice, the same isolation can be achieved with plain namespaces and cgroups without the Docker abstraction.

6. Alternatives to Docker

A simple Unix‑style utility, systemd‑nspawn, offers container‑like execution with stronger integration into the host system. It combines the isolation of namespaces and cgroups with filesystem virtualization, and works well with tools like debootstrap and btrfs snapshots. Other filesystem‑based approaches (btrfs, ZFS, OverlayFS, AUFS) can provide copy‑on‑write layering without the overhead of Docker’s storage drivers. systemd‑nspawn -D /srv/trees/ubuntu /bin/bash Use btrfs subvolume create /srv/trees/ubuntu followed by

btrfs subvolume snapshot /srv/trees/ubuntu /srv/containers/webapp

to clone and modify filesystem trees efficiently.

Overall, Docker adds a layer of abstraction that is not required for most container‑like tasks; traditional Linux tools can achieve the same goals with less complexity.