containers

crun

C2020–2026

containers / crun

crun

A fast and lightweight fully featured OCI runtime and C library for running containers

Explore on GitHub Read Hacker News discussions

27Distinct people

28Mentions

0Explicit recommenders

4.2KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A fast and lightweight fully featured OCI runtime and C library for running containers

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 year28 dated mentions

Observed mentions: 2020-02-04 23:14:52 UTC to 2026-07-27 22:20:01 UTC.

* 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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	5	0	5
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	4	1	3
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	5	1	4
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	5	1	4
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	0	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	3	1	2
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	4	0	4

What Hacker News says

28 sources

teravor·Jul 27, 2026

this has already been done. runsc (gvisor) Kata Containers (virtualization) both drop in replacements for runc (default OCI runtime) there are others too. one based on libkrun : https://github.com/containers/crun/blob/main/krun.1.md and these are just runc replacements. with some minor scripting you can roll a CLI solution using any of gvisor, cloud-hypervisor, firecracker, muvm (libkrun).

In Securing Services with Rootless Containers

tobwen·Jun 21, 2026

Thanks for the write-up, I like the integration in the Proxmox VE environment. Given some similarities, I’d like to briefly mention `krun` here. Although it’s an OCI-compatible container runtime, it uses MicroVMs with a similar approach. Perhaps we can exchange ideas here? I recall that GPU passthrough is also a recurring topic there. https://github.com/containers/crun/blob/main/krun.1.md

In Running MicroVMs in Proxmox VE, the Easy Way

corford·May 19, 2026

We've been leaning on Lima recently for a "dockeresque" experience with hard VM guarantees. Also keeping an eye on https://github.com/containers/crun/blob/main/krun.1.md

In Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

codethief·Feb 14, 2026

(Though you can certainly configure Podman to use krun[0], which fires up a libkrun VM inside a crun container.) [0]: https://github.com/containers/crun/blob/main/krun.1

In Matchlock – Secures AI agent workloads with a Linux-based sandbox

Imustaskforhelp·Sep 9, 2025

I don't know about the [1] but I think that [2] actually embed's crun https://github.com/containers/crun in the executable itself. Crun can be/is used by podman/docker too so you could think that its essentially stripping docker down to its core of running oci containers and just taking the most lightweight and (fastest?) approach and embedding it directly into the executable. I am sure that I might get somethings wrong, I usually do, so if I have an error, please do let me know as I don't wish to spread misinformation This project on the other hand seems to be using bake https://github.com/losfair/bake which seems to take something like a docker container and I think essentially push it into something like .iso using squashfs The idea here is that they seem to embed firecracker itself into a single binary to actually just make it an exec

Read the rest

utable that can run that microvm as it is. And I think that bottlefire just seems to do something similar but they do it on their server side and seem to just provide you a binary to make things easy for you... I am not sure with microvm's architecture but it seems that there are some additional features that you can get since they are VM, maybe you can get the ability of https://criu.org/Main_Page out of the box but this doesn't seem to be done right now but In my opinion is really very doable. Another idea might be more security. I am going to refer to an article [1] which talks about flatpak but it has this line and I quote `containers are not sandboxed`, so I suppose that this can help blur the lines b/w containers by converting containers into microvm's and then leveraging vm's technology for sandboxing or some other mechanism rather easily as compared to docker (I see it use landlock which was new to me!) article [1]: https://hanako.codeberg.page/

In Show HN: Bottlefire – Build single-executable microVMs from Docker images

jauntywundrkind·Jul 23, 2025

> Alpine container image is <5MB. Debian container image (if you really need glibc) is 30MB. wasmtime is 50MB. That's not the deployment model of wasm. You don't ship the runtime and the code in a container. If you look at crun, it can detect if your container is wasm and run it automatically, without your container bundling the runtime. I don't know what crun does, but in wasmcloud for example, you're running multiple different wasm applications atop the same wam runtime. https://github.com/containers/crun/blob/main/docs/wasm-wasi-...

In When Is WebAssembly Going to Get DOM Support?

ma5ter·Jan 5, 2025Submission

Crun – A fast and lightweight featured OCI runtime

5 points · Open discussion

slpnix·Aug 29, 2024

Podman supports this since quite a while with the krun variant of the crun runtime (https://github.com/containers/crun/blob/main/krun.1), provided in Fedora by the "crun-krun" package. Just add "--runtime=krun" to your podman command line along the other arguments and you'll get the container running inside a VM powered by libkrun.

In RunCVM: An open-source Docker runtime for launching container images in VMs

NilsIRL·Mar 6, 2024

Yep pretty much. The executables bundle crun (a container runtime)[0], and a fuse implementation of squashfs and overlayfs. Appended to that is a squashfs of the image. At runtime the squashfs and overlayfs are mounted and the container is started. [0]: https://github.com/containers/crun

In Show HN: dockerc – Docker image to static executable "compiler"

radlad·Sep 26, 2023

On this note, I was really surprised to find Red Hat's OCI runtime is written in C: https://github.com/containers/crun Is anyone working on a Rust version?

In Google assigns a CVE for libwebp and gives it a 10.0 score

raesene9·Sep 21, 2023

It's interesting that, in light of things like this, you still see large software companies adding support for new components written in non-memory safe languages (e.g. C) As an example Red Hat OpenShift added support for crun(https://github.com/containers/crun) this year(https://cloud.redhat.com/blog/whats-new-in-red-hat-openshift...), which is written in C as an alternative to runc, which is written in Go(https://github.com/opencontainers/runc)...

In The urgent need for memory safety in software products

nazgulsenpai·Aug 7, 2023

I came across this last week when reading about different container runtimes -- crun is implemented in C[0]. Their explanation: "While most of the tools used in the Linux containers ecosystem are written in Go, I believe C is a better fit for a lower level tool like a container runtime. runc, the most used implementation of the OCI runtime specs written in Go, re-execs itself and use a module written in C for setting up the environment before the container process starts. crun aims to be also usable as a library that can be easily included in programs without requiring an external process for managing OCI containers." [0]https://github.com/containers/crun

In Barco: Linux Containers from Scratch in C

rektide·Jun 4, 2023

Kubernetes needs an OCI runtime to run containers with. Crun is one implementation it can use. Docker also appears to be able to use crun for it's engine as well. https://github.com/containers/crun/issues/37

In Crun: Fast and lightweight OCI runtime and C library for running containers

nateb2022·Jun 4, 2023Submission

Crun: Fast and lightweight OCI runtime and C library for running containers

109 points · Open discussion

tosh·Oct 31, 2022Submission

crun

2 points · Open discussion

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