You have spent 44 lessons building images with Docker, and there is something worth saying clearly: those images are not "Docker images". They are artifacts that comply with an open standard, and they run identically on Podman, on containerd, on CRI-O or on a Kubernetes node without changing a byte. This lesson explains why, takes the ecosystem apart piece by piece, and runs ghcr.io/auroralibros/aurora-api:2.0.0 outside Docker to prove it.

1. The right question: who owns an image?
2. The OCI standard and its three specifications
3. What this means in practice
4. The map of the pieces: low-level and high-level runtimes
5. CRI: why Kubernetes does not talk to Docker
6. Podman: the daemonless architecture
7. Rootless by default
8. Command compatibility and what breaks
9. Pods, generate kube and play kube
10. Compose, the compatible socket and Testcontainers
11. Docker versus Podman, and migrating Aurora Libros
12. containerd and nerdctl
13. Buildah and Skopeo
14. Reinforced isolation: gVisor and Kata Containers
15. Decision table

When you ran docker build -t aurora-api:2.0.0 ., Docker did not invent a format of its own. It produced an artifact with a public structure: a JSON manifest, a configuration with the environment variables, the ENTRYPOINT, the user and the history, and a list of compressed layers, all identified by SHA-256 digests.

Look at the mediaType: it says vnd.oci.image.index.v1+json, not "docker". That prefix is the literal proof that your image is an OCI artifact, and that the multi-architecture work you set up in 05-05 is a feature of the standard, not of Docker.

The Open Container Initiative was born in 2015 inside the Linux Foundation, driven by Docker itself, which donated its image format and its runc runtime. The motivation was to avoid a war of incompatible formats (there was a serious competitor, rkt, with a format of its own). The result is that today the container is a standard and not a product.

Any builder produces images that any registry stores and any runtime runs. That complete grid is what the standard buys you.

The direct consequence for Aurora Libros: ghcr.io/auroralibros/aurora-api:2.0.0 — 104 MB, two architectures, signed with Cosign, with an SBOM and a provenance attestation — runs exactly the same on Docker, on Podman, on containerd or on any Kubernetes node, and its signature verifies identically on all of them. You have not learned a product: you have learned a standard and one of its implementations.

Changing the low-level one is a single line of configuration, and the images never notice:

Kubernetes needs to talk to some runtime on each node. Instead of coupling itself to one, it defined the Container Runtime Interface, a gRPC API with two services: RuntimeService (the lifecycle of Pods and containers) and ImageService (images).

Docker Engine never implemented CRI, so an adapter called dockershim existed inside the kubelet itself. It was Kubernetes code maintaining compatibility with one specific product, and it was removed in version 1.24 (2022).

That was communicated terribly and generated headlines along the lines of "Kubernetes drops support for Docker". What actually happened was that an intermediary was removed: containerd, which was already down there, started talking directly to the kubelet. Your images were not affected at all, because they are OCI. It is the best possible illustration of this lesson's thesis.

Podman (Red Hat) is the most relevant alternative to Docker, and its structural difference is that there is no daemon.

The fourth row is the underlying reason. The "the docker group is equivalent to root" you learned in 05-03 simply does not exist in Podman: there is no privileged socket to belong to. And the last one matters in regulated environments: audit logs attribute actions to people, not to a daemon.

Docker has supported rootless mode since 20.10, but you have to enable it. In Podman it is the norm from the start, resting on user namespaces (05-07) and on the ranges in /etc/subuid and /etc/subgid.

The container believes it is the redis user (UID 999) and the kernel sees it as 100998, a UID with no privileges whatsoever. A container escape does not give root: it gives you a user that can do nothing.

Podman deliberately replicates the Docker CLI:

It works for the vast majority of daily work. What is not identical:

Podman borrows its grouping unit from Kubernetes: the pod, a set of containers that share a network namespace (and therefore localhost and the ports).

Notice REDIS_URL=redis://localhost:6379: inside a pod, the containers share the network interface, so they reach each other over localhost. It is exactly the model of a Kubernetes Pod, rehearsed on your laptop.

And from there comes Podman's most useful bridge:

generate kube produces a Pod (or a Deployment with --type deployment) ready for review. It does not replace the work from module 6 — it generates no Ingress, HPA, PDB or tuned probes — but as a draft it is far better than kompose, because it starts from something that already works.

Two ways of running your compose.yaml:

Option B is superior because it uses the official Compose v2, with its full coverage of keys, talking to Podman through a socket that emulates the Docker API. And that same socket enables everything else:

Migrating Aurora Libros, step by step and with the proof at the end:

Zero changes to the image, zero changes to the compose.yaml, the same verifiable signature and cache-aside returning db and then cache. The only real operational difference is in step 5: where Docker had restart: unless-stopped, here there are user systemd units, and the enable-linger is the detail everybody forgets.

containerd is a graduated CNCF project, and it is the piece you are already using without knowing it: Docker Engine delegates to it. It manages images, snapshots, basic networking and the lifecycle, and it calls runc. It is also the default runtime of most managed Kubernetes offerings.

Its native CLI, ctr, is a debugging tool, not a working one:

nerdctl is what makes containerd usable: it replicates the Docker CLI, includes BuildKit and ships Compose.

nerdctl also exposes features Docker does not have: encrypted images, lazy pulling with stargz (starting without downloading the whole image) and Wasm containers. It is the usual way to experiment with what is coming.

Buildah builds OCI images with no daemon and with no Dockerfile if you do not want one:

Skopeo is the one people miss most once they know about it: it inspects and copies images between registries without downloading them to your local disk.

The --all copies the complete multi-architecture index, not just your machine's variant: without it you would replicate half an image and the amd64 server would fail. And the last command is pure gold in a pipeline: verifying the production digest costs one HTTP request instead of a full download.

Containers share the host kernel. If a privilege escalation vulnerability turns up in the kernel, the isolation breaks. These two runtimes attack exactly that.

Aurora Libros does not need them: your code is yours and it already runs unprivileged, with read_only, cap_drop: [ALL] and no-new-privileges. They are justified when you run code you do not control — customer functions, CI for public repositories, third-party notebooks — and there the performance cost is paid without argument.

The honest conclusion: in 2026 Docker is still the natural choice for development thanks to its ecosystem and convenience, Podman wins in environments where security and system policy rule, and containerd is what runs the world in production without almost anybody typing it. And all three run the very same image of yours.

• Believing you have to rebuild to change runtime. You do not. The digest is the same and the Cosign signature verifies identically.
• Repeating that "Kubernetes dropped support for Docker". What was removed was dockershim, an adapter. OCI images were never in question.
• Mixing root and user containers in Podman. The stores are separate: what you build with sudo podman, plain podman cannot see. It is the number one source of confusion when starting out.
• Expecting restart: always in Podman. There is no daemon. Generate units with podman generate systemd and do not forget loginctl enable-linger.
• Publishing port 80 in rootless mode without adjusting anything. Privileged ports are off limits. Adjust ip_unprivileged_port_start or put a proxy in front.
• Copying images with skopeo copy without --all. You take only one architecture and the other environment fails on deployment.
• Using ctr for daily work. It is a containerd debugging tool. Use nerdctl.
• Tip: run docker buildx imagetools inspect --raw against your image and read the mediaType. Seeing vnd.oci on screen fixes the idea better than any explanation.
• Tip: if Podman interests you, start with the compatible socket and docker compose. You migrate the execution without migrating the tooling.
• Tip: podman generate kube is the best manifest draft there is, because it starts from something that already works.

Exercise 1 — Prove the portability. Run ghcr.io/auroralibros/aurora-api:2.0.0 with Docker and with Podman (or nerdctl) on the same machine. Compare the image digest in both, check that the /books endpoint returns the nine titles in both cases, and verify the Cosign signature against the registry. Write down what is identical and what changes between the two runs.

Exercise 2 — A Kubernetes-style pod with Podman. Create an aurora pod containing aurora-cache (redis:7-alpine) and aurora-api, communicating over localhost, with port 8080 published. Check that cache-aside works (source: db the first time, cache the second). Then generate the Kubernetes manifest with podman generate kube, read it, and note three things it is missing to be production-ready according to what you learned in module 6.

Exercise 3 — Skopeo in the pipeline. Write a script that, without downloading a single image, checks whether the digest of ghcr.io/auroralibros/aurora-api:2.0.0 matches the one deployed in production (read it from a digest-production.txt file), and that in case of a mismatch replicates the complete image, with both its architectures, to the internal registry registry.internal:5000. The script must return 0 if everything matches and 10 if it had to replicate.

Solution 1.

Identical: the digest, the content, the API's behavior and the signature verification — because Cosign validates an artifact that lives in the registry, not in the runtime. What changes is everything around the execution: in Docker the container is a child of dockerd (root) and appears in ps aux as such; in rootless Podman it is a child of conmon under your UID, the internal process maps to a high host UID, and podman ps only shows your containers. Networking also changes (netavark versus Docker's bridge), and so does the handling of automatic startup. None of those differences affects the artifact: what runs is exactly the same thing.

Solution 2.

What the generated manifest is missing to be production-ready: (1) the three probes — at most it generates whatever it inferred from the container, not the startupProbe, livenessProbe and readinessProbe on /health/live and /health/ready that you separated out in 06-01; (2) resources with requests and limits, without which the scheduler cannot place the Pod sensibly and the HPA cannot calculate a usage percentage; (3) it is a bare Pod, not a Deployment, so there are no replicas, no rolling updates, no rollback and no recovery if the node falls over. I would add two more: there is no ConfigMap/Secret (the configuration goes in as literal variables, credentials included) and there is no Service or Ingress. It works as an excellent draft because it starts from something that runs, and as a reminder that everything that makes a deployment production-ready is deliberate work.

Solution 3.

The key points. skopeo inspect --format '{{.Digest}}' makes a single HTTP request to the manifest: checking whether something changed costs milliseconds instead of downloading 104 MB, and that lets you run it every five minutes at no cost. skopeo copy transfers registry to registry without materializing layers on the local disk, something a docker pull followed by a docker push cannot do. The --all is essential: without it you would copy only the manifest matching the runner's architecture, and the day an arm64 node pulled from the internal copy, the pull would fail with a platform error that is quite hard to diagnose; the subsequent check with --raw confirms that both architectures arrived. And exit code 10 distinguishes "there was nothing to do" from "I replicated", which is what lets you chain a notification step in the pipeline only when there really was a change.

You now know why the images you have built throughout the course are not "Docker images". You have verified it by reading the mediaType of your own multi-architecture index: application/vnd.oci.image.index.v1+json. The Open Container Initiative standardizes three things — the Image Spec that shapes your images, the Runtime Spec that defines the config.json you opened in 05-07, and the Distribution Spec that governs every push to ghcr.io — and from there comes the complete grid: any builder, any registry, any runtime.

You have the map of the pieces sorted by layer: low-level runtimes that live for milliseconds (runc, crun, youki) versus high-level managers (containerd, CRI-O, Podman, Docker Engine), with CRI in the middle explaining why the kubelet talks to containerd and why removing dockershim in 1.24 meant getting rid of an intermediary, not dropping support for your images.

You know Podman in depth: daemonless, with containers as children of your user rather than of a root process, which makes the "the docker group is root" from 05-03 simply not exist; rootless by default on top of user namespaces, with its four real limitations and their solutions; the pods that rehearse the Kubernetes model on your laptop with localhost between containers; generate kube and play kube as the best manifest draft there is, because it starts from something that works; and the compatible socket that lets you use the official docker compose and Testcontainers without changing tools. And you have genuinely migrated Aurora Libros: same image, same digest, same verified signature, same compose.yaml, with cache-aside returning db and then cache, and user systemd taking the place of restart: unless-stopped.

Completing the picture: containerd — the piece you were already using without knowing it — with ctr for debugging and nerdctl for working, including nerdctl compose; Buildah for building without a daemon; Skopeo for inspecting and copying between registries without downloading anything, with the --all that stops you replicating half an image; and gVisor and Kata for when you have to run code you do not control and the performance cost is happily paid. The decision table tells you when Docker is still the natural choice and when something else pays off.

In the final lesson of the course we lift our eyes from all of it: where the container ecosystem is heading, which trends have substance and which are a bet, what is not going to change — and is therefore where your learning is best invested — and the full closing of the road Aurora Libros has travelled since those fifteen manual onboarding steps.