AlmaLinux 9 module stream switching versus rootless Podman for reproducible development environments

The short answer

For a reproducible, low-friction development environment on AlmaLinux 9, rootless Podman with a pinned almalinux:9-based image is the stronger default. Module streams are the right choice only when the environment is simple — one runtime, one version, no per-project isolation needs — and you want zero container tooling. The deciding factor is that a Containerfile pins exact versions and travels with the project, while a module stream mutates the host package database and depends on whatever the repos happen to offer at rebuild time.

Why module streams lose on reproducibility

Switching streams is not atomic. The sequence dnf module reset nodejs followed by dnf module install nodejs:20 can fail partway, leaving orphaned packages from the old stream or unresolved dependencies. Before any switch, capture the current state so rollback is possible:

dnf module list --enabled
rpm -qa | grep -E '^(nodejs|python3\.|golang)' > /root/pre-switch-packages.txt

Even when the switch succeeds, the stream's contents change over time as the repos publish updates, so "rebuild this machine from scratch in six months and get identical versions" is not guaranteed. A container image digest is.

The undocumented support-window problem

Module stream lifecycles generally track the upstream runtime's support window, not the full AlmaLinux 9 lifecycle, and there is no single consolidated AlmaLinux support matrix for every stream. Treat this as a per-stream verification task rather than an assumption:

• Run dnf module list nodejs (or python, go) to see available streams and which is enabled.
• Check the upstream project's published EOL schedule (e.g., the Node.js release schedule) for the exact stream you intend to use.
• Record that EOL date in your project docs and plan a migration before it arrives, because the stream may stop receiving fixes while the OS itself is still supported.

This uncertainty itself is an argument for containers: a pinned image keeps working after a stream goes EOL, though you then own security patching of the image.

SELinux implications of each path

Module streams install stock, confined packages, so SELinux normally requires no adjustment at all — a genuine operational advantage.

Rootless Podman is mostly handled by the container-selinux policy, but two issues come up routinely:

• Bind mounts. A container cannot read or write host files in your home directory unless the volume is relabeled. Use :z (shared between containers) or :Z (exclusive):

podman run --rm -v "$PWD:/src:Z" almalinux:9 ls /src
ls -Z  # confirm the relabel happened

Note that :Z relabels exclusively for one container and can break access for other containers or host tools; prefer :z for shared source trees. For custom paths outside home, you may need semanage fcontext plus restorecon.

• Networking. Rootless containers cannot bind privileged host ports (<1024) without sysctl changes, and a database listening on the host's 127.0.0.1 is not reachable from the container's loopback. Publish ports explicitly or use --network=host where acceptable.

Decision criteria

Recommendation

A hybrid works well in practice: keep the AlmaLinux 9 host minimal and stable, and run each project's toolchain in a pinned almalinux:9-based image. This eliminates stream switching entirely. Verify the setup by rebuilding from scratch on a clean VM and confirming the Containerfile yields identical tool versions. Rootless Podman behavior (subuid/subgid mapping, fuse-overlayfs) varies across 9.x minor releases, so test against your installed podman --version before standardizing.