Virtualization & Containers

This page covers running containerized workloads on InterGenOS. The container stack ships as installable packages in the extra tier; nothing container-related runs until you install it and opt in. That posture is deliberate: security is not first. It is only. The goal is a machine you understand, can modify, and can trust, so a root-privileged daemon never starts on your behalf.

InterGenOS is built from source. The container engines and their runtimes are compiled and signed alongside the rest of the system, verified by pkm before installation against the live package index. See Repository Trust and the Package Manager for how that verification works.

Containers

InterGenOS provides two OCI container engines today: Podman and Docker. Both are open-source (Apache-2.0), and both manage standard OCI images and containers.

Podman

Podman is the daemonless OCI engine. It runs containers without a long-lived background service and supports rootless operation, which fits the system’s least-privilege posture. The Podman package pulls in the supporting runtime stack automatically as dependencies:

crun — low-level OCI runtime
conmon — container monitor for conmon-managed processes
netavark and aardvark-dns — container networking and name resolution
fuse-overlayfs — userspace overlay storage driver for rootless containers
catatonit — minimal init for container PID 1
containers-common — shared configuration for container tools
passt — userspace networking

Install it with pkm:

sudo pkm install podman

Once installed, Podman is invoked directly. Because it is daemonless, there is no service to enable before you can run a container.

Docker

Docker ships as a separate, opt-in package. It bundles the Docker engine (dockerd and docker-proxy), the docker CLI, and an init for container PID 1. Docker depends on containerd (its runtime peer) and runc (the low-level OCI runtime), both built and pinned alongside it.

Docker is mirror-only: it is not part of the default desktop image, so it never lands on a system without explicit operator action. Install it with pkm:

sudo pkm install docker

Unlike Podman, Docker uses a root-privileged daemon. To honor the secure-default posture, docker.service and docker.socket ship disabled. The daemon does not start until you opt in:

sudo systemctl enable --now docker.socket

Until you run that, the Docker daemon is not listening and not running. This is a belt-and-suspenders default on top of the mirror-only inclusion: even after install, you make a deliberate choice to start a privileged daemon.

Choosing between Podman and Docker

If you want a daemonless, rootless-capable engine that keeps privilege low by default, use Podman. If your existing tooling or CI expects the Docker daemon and socket, install Docker and enable it explicitly. Both consume and produce standard OCI images, so workflows are portable between them.

Virtual machines

No VM or hypervisor packages ship by default — there is no QEMU, libvirt, or GNOME Boxes on the desktop image. The current release focuses on the OCI container stack described above. If you need full virtual machines, install the tooling you want with pkm.

Defaults and posture

Nothing pre-installed. No container engine is present in the desktop image. You install exactly what your workload needs.
No privileged daemon by default. Podman is daemonless; Docker’s daemon and socket ship disabled and require an explicit systemctl enable --now.
Verified before install. pkm checks signatures against the trusted package index before any container package is placed on disk.
No telemetry. The container stack carries no usage reporting off your machine.

InterGenOS Wiki