urunc
a simple container runtime that aspires to become `runc` for unikernels
- 9
- Projects
- 1
- Years active
- 2
- In 2026 T3
- Go
- Basic understanding of container runtimes and OCI concepts.
- Experience with Go.
- contianer runtimes
- +39
Projects
92026
9 projectsTerm 3 · Sep-Nov · 2 projects
Fuzzing and robustness testing for urunc
LFX Mentorship · Listed in the official cohort
As a container runtime, urunc is a crucial component of the whole container stack and as a result it s very important to ensure its robustness, reliability and expected behavior. One of the best ways to do so is with fuzzing This project aims to extend the current testing suite of urunc, increasing test and fuzzing coverage with the goal of improving its robustness, predictability, and error reporting. Apart of the implementation, the tests should also be included in the CI and even integrating them with OSS-Fuzz (or ClusterFuzzLite so that fuzzing runs continuously and its outcomes are automatically reported.
- Go
- contianer runtimes
- fuzzing
- testing
Integration of urunc's sandbox execution with Argo
LFX Mentorship · Listed in the official cohort
While urunc has successfully enabled the use of unikernels and single application kernels within Kubernetes environments, its integration with other CNCF projects has been less seamless. A notable example is Argo, a widely adopted platform for defining and managing workflows, complex pipelines, and distributed applications on Kubernetes. In urunc's execution model, untrusted components of a deployment run inside sandboxed environments as unikernels or single-application kernels, while trusted components run as standard containers. Although this separation enables fine-grained workload isolation, it introduces friction in deployments like Argo, since it breaks pod-level assumptions (e.g. shared networking, storage). This project aims to bridge that gap between Argo deployments and urunc's sandboxed execution model by enabling compatibility at the runtime and workflow levels. The expected outcome is that users can easily choose which parts of their Argo deployment run in isolated urunc sandboxes. Expected Outcome: - A document describing the architecture of Argo and the execution model of urunc, including a clear breakdown of the main incompatibilities. - A working integration with the necessary changes required in urunc and its components. - A tutorial showing how to deploy and run Argo workflows using urunc, including setup, configuration, and example use cases.
- Go
- container runtimes
- Argo
- Kubernetes
Term 2 · Jun-Aug · 4 projects
Extensive evaluation of urunc's sandboxing execution model
LFX Mentorship · Listed in the official cohort
According to urunc's execution model, the application executes inside a VM-based or software-based sandbox. While this model strengthens isolation boundaries, it can introduce performance overhead and additional resource consumption compared to standard containers. Over the past years, evaluations of urunc have focused primarily on spawn time and container density and less on other aspects, such as CPU and memory usage, storage overhead I/O performance and network latency. As a result, it is necessary to conduct a thorough performance evaluation of urunc across multiple metrics. The evaluation should span across microbenchmarks, macrobenchmarks, and representative real-world workloads. Apart from the evaluation itself, it is also important to create a reproducible benchmarking suite, with all scripts, tools and documentation, so that anyone can extend and reproduce the experiments across different environments and versions.
- Good understanding of benchmarking methodologies and tools (e.g. fio
- perf)
- Experience with scripting (e.g. Bash
- Python) for automation of benchmarks.
- Basic understanding of virtualization and container runtimes concepts.
- Familiarity with Kubernetes.
Improve lifecycle management of sandbox monitors
LFX Mentorship · Listed in the official cohort
Currently, urunc launches sandbox monitors, such as Firecracker and QEMU through command-line invocations. This approach offers limited control over the sandbox lifecycle once the process is started. On the other hand, most monitors expose remote management interfaces, typically through a socket-based API. These interfaces provide access to the same operations currently performed via CLI, but also enable further control over the sandbox lifecycle. In particular, they allow more fine-grained lifecycle management of the sandbox, including querying and monitoring its state, performing device hotplug and unplug operations and interacting with the guest. This project aims to extend urunc's sandbox integration layer to support remote management interfaces and to explore each monitor's capabilities in order to extend the functionalities of urunc sandboxed containers.
- Basic understanding of container runtimes and OCI concepts.
- Good understanding of Linux systems programming (IPC
- process management
- etc.)
- Experience with Go.
- Familiarity with virtual machine monitors.
Improving DNS and localhost based networking compatibility for urunc across CNIs
LFX Mentorship · Listed in the official cohort
In a standard container setup, the container shares the network namespace with its host environment, meaning localhost inside the container refers to the same loopback interface as the host's network namespace. Many CNI plugins and container networking services rely on this assumption. For instance, Docker sets up an internal DNS server listening on localhost within each container's network namespace and configures /etc/resolv.conf accordingly. Similarly, service meshes (e.g., Istio, Linkerd) inject sidecar proxies that listen on localhost, and certain CNI plugins expose health checks or metrics endpoints on the loopback interface. In urunc, however, workloads execute inside a sandboxed environment with its own isolated network stack. As a result, localhost inside the sandbox does not refer to the host's network namespace loopback interface but to the sandbox's own. This breaks any service that relies on localhost-based communication between the container and host-level components. This project aims to investigate and implement mechanisms to bridge localhost communication between the host network namespace and the sandbox. The mentee will survey the landscape of CNI plugins and networking services that rely on localhost, categorize the different communication patterns, and design a solution that restores compatibility while preserving the isolation guarantees that urunc provides.
- Good understanding of Linux networking concepts (network namespaces
- loopback interfaces
- DNS resolution).
- Basic understanding of container networking (CNI plugin model
- bridge/overlay networks).
- Experience with low-level networking tools (iptables
- +2
Integration of urunc's sandbox execution with Argo
LFX Mentorship · Listed in the official cohort
While urunc has successfully enabled the use of unikernels and single application kernels within Kubernetes environments, its integration with other CNCF projects has been less seamless. A notable example is Argo, a widely adopted platform for defining and managing workflows, complex pipelines, and distributed applications on Kubernetes. In urunc's execution model, untrusted components of a deployment run inside sandboxed environments as unikernels or single-application kernels, while trusted components run as standard containers. Although this separation enables fine-grained workload isolation, it introduces friction in deployments like Argo, since it breaks pod-level assumptions (e.g. shared networking, storage). This project aims to bridge that gap between Argo deployments and urunc's sandboxed execution model by enabling compatibility at the runtime and workflow levels. The expected outcome is that users can easily choose which parts of their Argo deployment run in isolated urunc sandboxes.
- Good understanding of Kubernetes.
- Familiarity with Argo and its architecture.
- Basic understanding of container runtimes and OCI concepts.
- Experience with Go.
Term 1 · Mar-May · 3 projects
Create a dashboard and a notification system for CI testing in urunc
LFX Mentorship · Listed in the official cohort
GitHub Actions provides detailed views of CI workflows at the repository level, but it can be difficult for maintainers to quickly track the overall status of recurring workflows, such as nightly tests, over time. Important information, like historical failures or trends, often requires manual inspection of individual workflow runs. This work aims to improve CI observability for urunc by creating a centralized dashboard that presents an aggregated view of its nightly (and other CI) test workflows. The dashboard will provide maintainers with a clear overview of recent runs, success and failure states, and relevant metadata in a single place. In addition to visualization, this work includes the design and implementation of a notification mechanism that alerts maintainers when tests fail. This will help ensure that regressions are noticed quickly and addressed in a timely manner, improving overall project reliability.
- Basic understanding of CI/CD
- GitHub Actions and GitHub API.
- Experience with a suitable programming language (e.g.
- Go
- Python
- JavaScript)
Investigate missing custom OCI Annotations in urunc containers
LFX Mentorship · Listed in the official cohort
In order to pass sandbox-specific configuration, such as the guest type, monitor type, rootfs information and others, urunc relies on a set of custom OCI annotations. However, these annotations are missing from the container's configuration in non-Kubernetes-deployments. To work around this issue, a urunc.json file containing the same information is currently injected into the container’s root filesystem. This works aims to investigate the OCI image build and runtime flow to understand where and why these custom annotations are dropped or ignored in non-Kubernetes setups.
- Go
- Familiarity with container tools (docker
- nerdctl
- skopeo etc.)
- Familiarity with container runtimes (containerd
- runc
- +2
Optimizing Rootfs Handling with block-based snapshotters in urunc
LFX Mentorship · Listed in the official cohort
When urunc is used together with a block-based snapshotter, it can take advantage of block-device backed container root filesystem and pass it directly to the sandbox as a disk image. This approach avoids filesystem conversion and enables efficient access to the container root filesystem. However, in order to spawn the sandbox, urunc requires access to the guest kernel and the initrd (if present). Since these files are part of the container rootfs, urunc must first extract and store them elsewhere before attaching the block-based root filesystem to the sandbox. As a result, this process introduces unnecessary file copies and additional I/O overhead. A more efficient approach is to leverage read-only (view) snapshots. Instead of copying files, urunc could request a read-only snapshot of the container root filesystem and mount it separately. The kernel binary and other required artifacts could then be read directly from this snapshot without modifying or duplicating data. Since view snapshots simply redirect read requests to the underlying snapshot layers, this approach is expected to introduce little to no additional storage overhead while simplifying the runtime flow.
- Go
- Familiarity with containerd
- Familiarity with Linux filesystems and block devices
