Beyond Docker: Exploring Modern Container Engines, Build Tools, and Runtimes

Why Move Away from Docker?

Docker dominated container tooling about four years ago, but it is now just one of many OCI‑compatible engines. While Docker can build, run, pull, push, and inspect images, specialized tools often perform each task better. All the tools discussed follow the OCI specification, so they can interoperate with Docker’s CLI and API.

Container Engines

Container engines provide a user interface for handling images and containers without requiring low‑level security policies. They extract images from remote registries, unpack them, and create container manifests that are later handed to a runtime such as runc or crun.

Podman, developed by Red Hat, is the most prominent Docker alternative. It runs without a daemon and does not require root privileges. Because it also manages Pods (the smallest Kubernetes compute unit), workloads can be migrated to Kubernetes more easily.

~ $ podman pod create --name mypod
~ $ podman pod list
POD ID   NAME   STATUS   CREATED   # OF CONTAINERS   INFRA ID
211eaecd307b mypod Running 2 minutes ago 1 a901868616a5
~ $ podman run -d --pod mypod nginx   # First container
~ $ podman run -d --pod mypod nginx   # Second container
~ $ podman ps -a --pod
CONTAINER ID   IMAGE   COMMAND   CREATED   STATUS   PORTS   NAMES   POD   POD NAME
...

Other engines include:

LXD – a manager for system containers (LXC) that offers VM‑like isolation.

CRI‑O – a runtime‑only component built for Kubernetes; not intended for direct user use.

rkt – a now‑deprecated engine from CoreOS.

Building Images

While Docker remains a popular engine, many dedicated image‑building tools exist.

Buildah (https://buildah.io) is a daemon‑less tool that integrates tightly with Podman. It can build images from a Dockerfile or Containerfile, offers fine‑grained layer control, and produces OCI‑compatible images.

~ $ buildah bud -f Dockerfile .
~ $ buildah from alpine:latest   # equivalent to "FROM alpine:latest"
... (output omitted for brevity) ...
~ $ buildah commit alpine-working-container my-final-image
REPOSITORY   TAG   IMAGE ID   CREATED   SIZE
localhost/my-final-image   latest   1ff90ec2e26e   22 seconds ago   51.4 MB

Buildah’s CLI is a superset of podman build, so users can switch between them as needed.

Kaniko (https://github.com/GoogleContainerTools/kaniko) builds images from Dockerfiles inside a Kubernetes pod without a daemon. It is convenient for CI/CD pipelines but requires Docker to run the Kaniko executor image locally.

BuildKit (https://github.com/moby/buildkit) is the next‑generation Docker build engine. Enabling it with DOCKER_BUILDKIT=1 docker build provides parallel builds, cache improvements, and rootless operation, though it still relies on a daemon ( buildkitd).

Other niche tools:

Source‑To‑Image (S2I) – builds images directly from source code, mainly used on OpenShift.

Jib – Java‑focused image builder with Maven/Gradle plugins.

Bazel – a full build system that can also produce container images via rules_docker.

Container Runtimes

Runtimes execute the unpacked container bundles.

runc (https://github.com/opencontainers/runc) – the reference OCI runtime used by Docker, Podman, and CRI‑O.

crun (https://github.com/containers/crun) – a fast, low‑memory C implementation, often the default in newer Red Hat releases.

CRI‑O – not a full engine but an OCI runtime wrapper for Kubernetes nodes; it delegates to runc.

containerd (https://containerd.io) – a CNCF graduation project that provides a daemon API for image management and runtime orchestration; it uses runc under the hood and powers Docker’s default runtime.

Image Inspection and Distribution

Beyond docker inspect, tools like Skopeo (https://github.com/containers/skopeo) can inspect remote images and copy them between registries without pulling them locally.

Dive (https://github.com/wagoodman/dive) offers a user‑friendly way to explore image layers, assess size efficiency, and integrate into CI pipelines.

Conclusion

The goal is not to force the abandonment of Docker but to present the full landscape of container engines, image builders, runtimes, and inspection tools. Each option has trade‑offs; selecting the right combination depends on your workflow, security requirements, and deployment environment.