OCI containers and Linux host kernel: repeatable development environment portability across kernel versions

A repeatable development environment is intended to provide consistent toolchains and dependencies across developer workstations by running OCI images on a shared Linux host kernel.

Isolation relies on Linux namespaces for view separation and cgroups v2 for resource enforcement, with OverlayFS providing read-only image layers plus a writable layer for local changes. User namespaces allow a root-like view inside the container while mapping to an unprivileged user on the host.

Portability is constrained by kernel version compatibility between build and runtime hosts and by UID/GID mapping interactions with host bind mounts used for source code and data. The interoperability of these mechanisms at the container-host boundary remains an unresolved design decision for repeatable workflows.

What guarantees does the OCI runtime specification provide for image portability when the host kernel lacks a syscall present in the build environment? How does UID/GID mapping in user namespaces affect file ownership semantics for bind-mounted host directories used in development? Under what conditions do cgroups v2 limits set on the host interact predictably with per-process limits observed inside a user namespace?