HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
containerd
containerd
Go2017–2026
containerd / containerd

containerd

An open and reliable container runtime

35Distinct people
37Mentions
0Explicit recommenders
21.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An open and reliable container runtime

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year37 dated mentions

Observed mentions: 2017-07-19 18:43:11 UTC to 2026-09-06 01:48:27 UTC.

024682017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC211
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC716
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC422
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC817
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC606
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC413

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
containerd is an industry-standard container runtime with an emphasis on simplicity, robustness, and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc. containerd is a member of CNCF with 'graduated' status. containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users. Announcements Now Recruiting We are a large inclusive OSS project that is welcoming help of any kind shape or form: Documentation help is needed to make the product easier to consume and extend. We need OSS community outreach/organizing help to get the word out; manage and create messaging and educational content; and help with social media, community forums/groups, and google groups. We are actively inviting new security advisors to join the team. New subprojects are being created, core and non-core that could use additional development help. Each of the containerd projects has a list of issues currently being worked on or that need help resolving. If the issue has not already been assigned to someone or has not made recent progress, and you are interested, please inquire. If you are interested in starting with a smaller/beginner-level issue, look for issues with an exp/beginner tag, for example containerd/containerd beginner issues. Getting Started See our documentation on containerd.io: for ops and admins namespaces client options To get started contributing to containerd, see CONTRIBUTING. If you are interested in trying out containerd see our example at Getting Started. Nightly builds There are nightly builds available for download here. Binaries are generated from main branch every night for Linux and Windows. Please be aware: nightly builds might have critical bugs, it's not recommended for use in production and no support provided. Kubernetes (k8s) CI Dashboard Group The k8s CI dashboard group for containerd contains test results regarding the health of kubernetes when run against main and a number of containerd release branches. containerd-periodics Runtime Requirements Runtime requirements for containerd are very minimal. Most interactions with the Linux and Windows container feature sets are handled via runc and/or OS-specific libraries (e.g. hcsshim for Microsoft). The current required version of runc is described in RUNC.md. There are specific features used by containerd core code and snapshotters that will require a minimum kernel version on Linux. With the understood caveat of distro kernel versioning, a reasonable starting point for Linux is a minimum 4.x kernel version. The overlay filesystem snapshotter, used by default, uses features that were finalized in the 4.x kernel series. If you choose to use btrfs, there may be more flexibility in kernel version (minimum recommended is 3.18), but will require the btrfs kernel module and btrfs tools to be installed on your Linux distribution. To use Linux checkpoint and restore features, you will need criu installed on your system. Build requirements for developers are listed in BUILDING. Supported Registries Any registry which is compliant with the OCI Distribution Specification is supported by containerd. For configuring registries, see registry host configuration documentation Features For a detailed overview of containerd's core concepts and the features it supports, please refer to the FEATURES.MD document. Releases and API Stability Please see RELEASES.md for details on versioning and stability of containerd components. Downloadable 64-bit Intel/AMD binaries of all official releases are available on our releases page. Binaries are published for additional platforms as well; see Platform Support for the full list of platforms and the level of support for each. For other architectures and distribution support, you will find that many Linux distributions package their own containerd and provide it across several architectures, such as Canonical's Ubuntu packaging. Enabling command auto-completion Starting with containerd 1.4, the urfave client feature for auto-creation of bash and zsh autocompletion data is enabled. To use the autocomplete feature in a bash shell for example, source the autocomplete/ctr file in your .bashrc, or manually like: $ source ./contrib/autocomplete/ctr Distribution of ctr autocomplete for bash and zsh For bash, copy the contrib/autocomplete/ctr script into /etc/bash_completion.d/ and rename it to ctr. The zsh_autocomplete file is also available and can be used similarly for zsh users. Provide documentation to users to source this file into their shell if you don't place the autocomplete file in a location where it is automatically loaded for the user's shell environment. CRI cri is a containerd plugin implementation of the Kubernetes container runtime interface (CRI). With it, you are able to use containerd as the container runtime for a Kubernetes cluster. CRI Status cri is a native plugin of containerd. Since containerd 1.1, the cri plugin is built into the release binaries and enabled by default. The cri plugin has reached GA status, representing that it is: Feature complete Works with Kubernetes 1.10 and above Passes all CRI validation tests. Passes all node e2e tests. Passes all e2e tests. See results on the containerd k8s test dashboard Validating Your cri Setup A Kubernetes incubator project, cri-tools, includes programs for exercising CRI implementations. More importantly, cri-tools includes the program critest which is used for running CRI Validation Testing. CRI Guides Installing with Ansible and Kubeadm For Non-Ansible Users, Performing a Custom Installation Using the Release Tarball and Kubeadm CRI Plugin Testing Guide Debugging Pods, Containers, and Images with crictl Configuring cri Plugins Configuring containerd Communication For async communication and lo
Read the full README on GitHub

What Hacker News says

37 sources
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 discovered that various implementations of registry clients didn't handle transport-compression correctly (https://github.com/distribution/distribution/pull/3754), which could result in client either pulling the full, uncompressed, content, or image validation failing.
In Docker 29 has changed its default image store for new installs
There are a couple of notable examples of projects[0] and companies[1] that have got tired of it, and no longer use it. There's considerable difficulty these days extrapolating "real" vulnerabilities from kernel CVEs, as the kernel team quite reasonably feel that basically any bug can be a vulnerability in the right situation, but the list of vulnerabilities in io_uring over the past 12 months[2] is pretty staggering to me. 0: https://github.com/containerd/containerd/pull/9320 1: https://security.googleblog.com/2023/06/learnings-from-kctf-... 3: https://nvd.nist.gov/vuln/search#/nvd/home?offset=0&rowCount...
In Fast-Servers
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://github.com/kubernetes/kubeadm/issues/2020
In Preventing Kubernetes from pulling the pause image from the internet
You seem to have a fundamental misunderstanding about what docker actually does, and how it's achieving it > If you download a Dockerfile that's a couple of years old and hasn't been maintained, it probably won't work The dockerfile is not the produced artifact, that's merely the most common way to build the artifact. The artifact is the image. Which itself is only a zip file of a linux filesystem, basically. This will behave the same, no matter when you downloaded it. And I might add: the goal you seem to have: to make an image runnable forevermore is not the goal of docker, again. But if you made a new image, you can then test the exact same deployment in another environment. You do not need to e.g. run apt update on prod and pray to the gods that nothing breaks. Instead you build the image, deploy to test, see that nothing breaks and t
Read the rest
hen deploy to prod. Also k8s isn't technically backed by the docker backend anymore. It hasn't for a pretty long time now. It's currently using containerd by default https://github.com/containerd/containerd But supports other backends too https://kubernetes.io/docs/setup/production-environment/cont...
In Kubernetes is a symptom, not a solution
Notably, io_uring syscall has been a significant source of vulnerabilities. Last year, Google security team decided to disable it in their products (ChromeOS, Android, GKE) and production servers [1]. Containerd maintainers soon followed Google recommendations and updated seccomp profile to disallow io_uring calls [2]. io_uring was called out specifically for exposing increased attack surface by kernel security team as well long before G report was released [3]. Seems like less of a rust issue and more of a bug(s) in io_uring? I suppose user space apps can provide bandaid fix but ultimately needs to be handled at kernel. [1] https://security.googleblog.com/2023/06/learnings-from-kctf-... [2] https://github.com/containerd/containerd/pull/9320 [3] https://lwn.net/Articles/902466/
In Async Rust is not safe with io_uring
Uploading in chunks could definitely solve the issue, and the OCI Distribution Specification does actually have some language about an optional chunked push API[0]. Unfortunately very few of the registry clients actually support this, critically containerd does not[1], so this means your regular `docker push` and a whole lot of ecosystem tooling does not work. This also means that the single PUT must be able to support very large pushes as a single request, possibly even larger than what R2 or S3 would allow without using multipart upload. This means you actually need a server to accept the PUT, then do its own chunked upload to object storage or otherwise stage the content before it's finally saved in object storage. This rules out presigned URLs for push too, since the PUT request made to the presigned URL can be too large for the backi
Read the rest
ng object storage to accept. There's also other processing that ideally happens on push (like hash digest verification of the pushed layer) that mean a server somewhere needs to be involved. [0] https://github.com/opencontainers/distribution-spec/blob/mai... [1] https://github.com/containerd/containerd/blob/192679b05917b5...
In Serverless-registry: A Docker registry backed by Workers and R2
This might be a question of me holding it wrong but I don’t know how on earth I’m supposed to judge from that link as it doesn’t really contain any relevant information. Just to pick a random example from the list of the 9 community projects they contribute(d?) to: containerd How much did they contribute? It’s not their project in any sense, do they contribute regularly? Did they do it once? Was it meaningful? None of that was answered from your link unfortunately and when I take a look at who actually contributes in practice here: https://github.com/containerd/containerd/graphs/contributors I didn’t really see anyone from Apple initially.. I haven’t done an in depth review or anything but we are now in a situation where they only have 9 community projects they claim to contribute to and I can’t actually find any examples of them doing so
Read the rest
in a meaningful sense. So my original point actually feels kind of validated here.
In Apple is landing patches in FreeBSD
> You’ve written the same message, almost verbatim multiple times in this thread. Until now I had written exactly one message in this thread. If others have made similar statements or cited the same link it's down to the fact that some of us care a great deal and are enthusiastic about io_uring, so this relatively recent information is top of mind. > Docker doesn’t block IO_URING syscalls "Update RuntimeDefault seccomp profile to disallow io_uring related syscalls" from containerd-2.0.0 beta2 release[1], 3 weeks ago... (bear in mind there is considerable history here.) What a bizarre reply. [1] https://github.com/containerd/containerd/releases/tag/v2.0.0...
In Basic proxy implementation using io_uring

Showing the 15 most recent of 37 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.