{"slug": "containerd", "name": "containerd", "category": "infra", "category_name": "Infrastructure and DevOps", "description": "", "recommenders": 3, "commenters": 7, "warners": 0, "score": 3.543, "rising": -0.98, "first": "2025-11-05", "latest": "2026-08-10", "why": "I have been enjoying containerd & nerdctl on Debian for almost 2 years", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 4, "compare": 0, "warn": 0}, "spark": [0, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "I have been enjoying containerd & nerdctl on Debian for almost 2 years", "kind": "", "icon": true, "domain": null, "github_repo": "github.com/containerd/containerd", "official_url": "https://containerd.io", "pricing": "", "aliases": ["containerd"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 768486929, "item_id": 48030433, "url": "https://news.ycombinator.com/item?id=48030433", "by": "thaJeztah", "date": "2026-05-05", "version": null, "stance": "recommend", "quote": "The containerd project was created to provide a more modular runtime for the container ecosystem", "excerpt": "I'm a maintainer of the Moby project (which is used to build the Docker Engine), and saw this post got some attention, so let me try to outline some of the changes and motivation. Happy to answer questions if there's any. First of all, some history; the Docker Engine was a monolith daemon that provided many services; this worked well when using Docker as a standalone solution, but when used as runtime for Kubernetes,", "context": "Moby maintainer", "use_case": "container runtime and image storage", "switched_from": "", "story": "Docker 29 has changed its default image store for new installs"}, {"id": 747814660, "item_id": 46738416, "url": "https://news.ycombinator.com/item?id=46738416", "by": "nyrikki", "date": "2026-01-23", "version": null, "stance": "recommend", "quote": "you aren't using containerd which blocked vsock", "excerpt": "OCI Container Runtimes like OCI's runc are \"container runtimes\", so the runtime spec[2] Basically, docker started using lxc, but wanted a go native option, and wrote runc. If you look at [0] you can see how it actually instantiates the container. Here is a random blog that describes it fairly well [1] crun is the podman related project written in c, which is more efficient than the go based runc. You can try this eve", "context": "", "use_case": "", "switched_from": "", "story": "What Has Docker Become?"}, {"id": 747725249, "item_id": 46732828, "url": "https://news.ycombinator.com/item?id=46732828", "by": "pzmarzly", "date": "2026-01-23", "version": null, "stance": "recommend", "quote": "Docker, or rather containerd, still has better plugin ecosystem around it.", "excerpt": "Docker, or rather containerd, still has better plugin ecosystem around it. Unregistry https://github.com/psviderski/unregistry, Nydus https://github.com/dragonflyoss/nydus, all the different \"snapshotters\" (storage formats), or the utils for sharing NVIDIA GPUs with containers, etc. The gap with Podman is closing though, and most users don't need any of these in the first place.", "context": "", "use_case": "", "switched_from": "", "story": "What Has Docker Become?"}, {"id": 737862097, "item_id": 46116381, "url": "https://news.ycombinator.com/item?id=46116381", "by": "nacozarina", "date": "2025-12-01", "version": null, "stance": "recommend", "quote": "I have been enjoying containerd & nerdctl on Debian for almost 2 years", "excerpt": "I have been enjoying containerd & nerdctl on Debian for almost 2 years after being a docker user for ~7 years. nerdctl uses the same syntax, all my compose.yml files still worked, been a very stable experience, have never considered going back no comment on winders or macs options, never touch them for dev work", "context": "", "use_case": "container runtime", "switched_from": "Docker", "story": "Ask HN: What alternatives to Docker Desktop are people using?"}]}], "caveats": [], "who": [{"by": "cpburns2009", "context": "evaluating sandboxing against supply chain attacks", "url": "https://news.ycombinator.com/item?id=48490080", "date": "2026-06-11"}, {"by": "thaJeztah", "context": "Moby maintainer", "url": "https://news.ycombinator.com/item?id=48030433", "date": "2026-05-05"}], "tags": [], "use_cases": ["container runtime", "container runtime and image storage"], "compared": [{"slug": "docker", "name": "Docker", "co": 5, "switched_from": 1, "switched_to": 0}, {"slug": "podman", "name": "Podman", "co": 3, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 768488640, "item_id": 48030540, "url": "https://news.ycombinator.com/item?id=48030540", "by": "thaJeztah", "date": "2026-05-05", "version": null, "stance": "neutral", "quote": "We explored some options to do this", "excerpt": "Yes, compression being part of the OCI image's digest was (in hindsight) a poor decision. _Technically_ OCI images allow uncompressed layers, and the layers could be included without compression (and transport compression to be used); this would allow layers to be fully reproducible. We explored some options to do this (and made some preparations; https://github.com/containerd/containerd/pull/8166), but also discover", "context": "", "use_case": "", "switched_from": "", "story": "Docker 29 has changed its default image store for new installs"}], "threads": [{"url": "https://news.ycombinator.com/item?id=47986331", "title": "Docker 29 has changed its default image store for new installs", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=46731748", "title": "What Has Docker Become?", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49239751", "title": "Docker Sandboxes \u2013 Disposable, isolated sandboxes for AI agents", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48489485", "title": "Are we defaulting to VM-level sandboxing before understanding the threat model?", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47550282", "title": "Don't YOLO your file system", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46115185", "title": "Ask HN: What alternatives to Docker Desktop are people using?", "mentions": 1}], "sentiment_by_month": {"2025-11": {"neutral": 1}, "2025-12": {"recommend": 1}, "2026-01": {"recommend": 2}, "2026-02": {}, "2026-03": {"neutral": 1}, "2026-04": {}, "2026-05": {}, "2026-06": {"neutral": 1}, "2026-07": {}, "2026-08": {"neutral": 1}, "2026-09": {}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 788049969, "item_id": 49253123, "url": "https://news.ycombinator.com/item?id=49253123", "by": "kylequest", "date": "2026-08-10", "version": null, "stance": "neutral", "quote": "Uses ContainerD compiled natively for Mac OS", "excerpt": "TLDR facts about Docker Sandboxes (based on its install): Uses ContainerD compiled natively for Mac OS and uses Nerdbox for the VMs: \u251c\u2500\u2500 bin \u2502 \u2514\u2500\u2500 sbx \u251c\u2500\u2500 libexec \u2502 \u251c\u2500\u2500 containerd-shim-nerdbox-v1 <- Nerbox integration for ContainerD \u2502 \u251c\u2500\u2500 mkfs.erofs \u2502 \u251c\u2500\u2500 mkfs.ext4 \u2502 \u251c\u2500\u2500 nerdbox-kernel-arm64 \u2502 \u2514\u2500\u2500 nerdbox-rootfs-arm64.erofs More info about Nerdbox is here https://github.com/containerd/nerdbox", "context": "", "use_case": "container runtime", "switched_from": "", "story": "Docker Sandboxes \u2013 Disposable, isolated sandboxes for AI agents"}, {"id": 775841281, "item_id": 48490080, "url": "https://news.ycombinator.com/item?id=48490080", "by": "cpburns2009", "date": "2026-06-11", "version": null, "stance": "neutral", "quote": "containerd: Container runtime.", "excerpt": "This is what I've been working on the past month: a strategy for running sandboxed containers. It's not strictly for agents (I'm now using it for OpenCode). You should be thinking about supply chain attacks for all of your applications that use third-party dependencies. PyPI and NPM have had a lot of compromised packages recently. The litellm hack affected a lot of agents, and there have been some Docker escape explo", "context": "evaluating sandboxing against supply chain attacks", "use_case": "container runtime", "switched_from": "", "story": "Are we defaulting to VM-level sandboxing before understanding the threat model?"}, {"id": 768486929, "item_id": 48030433, "url": "https://news.ycombinator.com/item?id=48030433", "by": "thaJeztah", "date": "2026-05-05", "version": null, "stance": "recommend", "quote": "The containerd project was created to provide a more modular runtime for the container ecosystem", "excerpt": "I'm a maintainer of the Moby project (which is used to build the Docker Engine), and saw this post got some attention, so let me try to outline some of the changes and motivation. Happy to answer questions if there's any. First of all, some history; the Docker Engine was a monolith daemon that provided many services; this worked well when using Docker as a standalone solution, but when used as runtime for Kubernetes,", "context": "Moby maintainer", "use_case": "container runtime and image storage", "switched_from": "", "story": "Docker 29 has changed its default image store for new installs"}, {"id": 760845315, "item_id": 47552832, "url": "https://news.ycombinator.com/item?id=47552832", "by": "kstenerud", "date": "2026-03-28", "version": null, "stance": "neutral", "quote": "Docker container or containerd vm", "excerpt": "Not famous last words ;-) I've already shipped this and use it myself every day. I'm the author of yoloAI (https://github.com/kstenerud/yoloai), which is built around exactly this model. The agent runs inside a Docker container or containerd vm (or seatbelt container or Tart vm on mac), against a full copy of your project directory. When it's done, `yoloai diff` gives you a unified diff of everything it changed. `yol", "context": "", "use_case": "", "switched_from": "", "story": "Don't YOLO your file system"}, {"id": 747814660, "item_id": 46738416, "url": "https://news.ycombinator.com/item?id=46738416", "by": "nyrikki", "date": "2026-01-23", "version": null, "stance": "recommend", "quote": "you aren't using containerd which blocked vsock", "excerpt": "OCI Container Runtimes like OCI's runc are \"container runtimes\", so the runtime spec[2] Basically, docker started using lxc, but wanted a go native option, and wrote runc. If you look at [0] you can see how it actually instantiates the container. Here is a random blog that describes it fairly well [1] crun is the podman related project written in c, which is more efficient than the go based runc. You can try this eve", "context": "", "use_case": "", "switched_from": "", "story": "What Has Docker Become?"}, {"id": 747725249, "item_id": 46732828, "url": "https://news.ycombinator.com/item?id=46732828", "by": "pzmarzly", "date": "2026-01-23", "version": null, "stance": "recommend", "quote": "Docker, or rather containerd, still has better plugin ecosystem around it.", "excerpt": "Docker, or rather containerd, still has better plugin ecosystem around it. Unregistry https://github.com/psviderski/unregistry, Nydus https://github.com/dragonflyoss/nydus, all the different \"snapshotters\" (storage formats), or the utils for sharing NVIDIA GPUs with containers, etc. The gap with Podman is closing though, and most users don't need any of these in the first place.", "context": "", "use_case": "", "switched_from": "", "story": "What Has Docker Become?"}, {"id": 737862097, "item_id": 46116381, "url": "https://news.ycombinator.com/item?id=46116381", "by": "nacozarina", "date": "2025-12-01", "version": null, "stance": "recommend", "quote": "I have been enjoying containerd & nerdctl on Debian for almost 2 years", "excerpt": "I have been enjoying containerd & nerdctl on Debian for almost 2 years after being a docker user for ~7 years. nerdctl uses the same syntax, all my compose.yml files still worked, been a very stable experience, have never considered going back no comment on winders or macs options, never touch them for dev work", "context": "", "use_case": "container runtime", "switched_from": "Docker", "story": "Ask HN: What alternatives to Docker Desktop are people using?"}, {"id": 733144768, "item_id": 45821548, "url": "https://news.ycombinator.com/item?id=45821548", "by": "ralgozino", "date": "2025-11-05", "version": null, "stance": "neutral", "quote": "There was a discussion open on containerd's GitHub on removing the dependency on the pause image", "excerpt": "I went down this rabbit hole not so long ago too. There was a discussion open on containerd's GitHub on removing the dependency on the pause image but it has been closed as won't fix: https://github.com/containerd/containerd/issues/10505 Also, if you are using kubeadm to create your cluster, beware that kubeadm may be pre-pulling a different pause image if it does not match your containerd configuration: https://gith", "context": "", "use_case": "", "switched_from": "", "story": "Preventing Kubernetes from pulling the pause image from the internet"}]}