Kubernetes, Uncontained

A CRI-level containerd runtime shim that still runs standard containers inside pods. At startup, the shim activates a Flox environment inside the container. CI/CD stays the same—but instead of shipping image layers, you specify the name of a declarative Flox environment (immutable, Nix-backed). Pods read only the required, input-addressed packages from a node-local cache—so no multi-gigabyte image pulls.

You replace build-push-pull image pipelines with a declarative Flox environment, the dependencies of which resolve to hash-addressed packages that live in an immutable, node-local store. Organizations can run their own private, signed binary caches, enabling them to build or mirror packages inside their networks, generate SBOMs and attestations (see SBOMs, below), and point security scanners at that cache. At runtime, nodes fetch only hash-addressed artifacts, so existing provenance, approval, and CVE workflows carry over.

In sum: organizations shift from shipping snapshots (container images) to shipping recipes (declarative environments); recipes yield SBOMs-by-default, single-edit A/B and atomic rollbacks, faster CVE triaging, and other operational benefits. For developers, AI/ML engineers, and other practitioners, Flox environments run as subshells, not containers, so developers can work directly on their local systems, with free access to all resources. Flox development environments are co-located with Git repos, so PRs always update code and runtime together. The same environment travels across the SDLC: local dev → CI → production Kubernetes clusters.

Build and test locally using the same exact packages you use for deployments. Declaratively define all runtime dependencies, variables, services, build recipes, and system constraints. Push changes to FloxHub with flox push. Your Kubernetes Pod specifications reference Flox environments and pull these automatically from FloxHub at runtime. There are no images to rebuild and push, no layers to pull. Flox maps all dependencies to read-only, node-local store paths; these get mounted into containers at runtime.

You can easily build, package, and publish your own custom software to your private Flox catalog of packages. Use custom packages with your Kubernetes workloads by installing them to your FloxHub-hosted environments. When pods start, Flox mounts all packages directly from each node’s input-addressed cache into the container, wiring up paths and libraries automatically.

Open your private FloxHub, navigate to an environment’s Generations tab, select the target generation, and click Switch. All subsequent deployments of that environment will use the selected generation. If you prefer to pin the generation in your Pod specification, append the generation number to the environment reference—for example, /:. Everything is immutable and atomic—no image layer edits and no rebuild/push/pull loop.

Yes—and your pipelines will typically get simpler. Keep Argo/Helm/Tekton/GitHub Actions; change what you ship (i.e., a declarative environment pinned to an SHA256 hash), not how you deploy. Most iterations drop build → push → pull entirely.

No. Kubernetes still runs containers. The Flox runtime activates the environment at startup (you can use a tiny placeholder container image). You use the Kubernetes primitives you’re familiar with, along with all Kubernetes orchestration, networking, policy, and admission controls.

Flox makes it easy for teams to recreate the exact production runtime for debugging, maintenance, or audits—anywhere, on any machine: you debug the same environment that runs in the Kubernetes cluster—locally or in a debug pod. No guessing what’s inside an image layer. Plus reproducible behavior at runtime makes issues faster to reproduce and fix.

Very. In Flox (powered by Nix), SBOMs are always derived from the input-addressed build graph—not a post-hoc file scan. Every dependency is a concrete /nix/store/-pkg path, the hash of which covers all build inputs (sources, patches, flags, and transitive deps). This means you get both build-time and runtime SBOMs automatically: the build-time SBOM captures the toolchains/SDKs used to produce built artifacts; the runtime SBOM captures the realized closure. Most scanners only infer runtime after the fact; Flox gives you both, with no opt-in step. Because environments resolve to immutable store paths (and can be constrained per system), SBOMs stay exact for macOS and Linux, x86 and ARM.

This improves security work: CVE matching yields fewer false positives, and provenance is attestable. You can generate an attestation that includes the SBOM and either the Flox environment generation (/:) or the realized closure’s digest—i.e., the cryptographic fingerprint of the exact set of /nix/store/-pkg paths the environment resolves to on a given system. (Change any input and the digest changes.) Because your Deployment references the same value, your Kubernetes admission policy can verify the match before rollout. Nix’s input-addressed provenance makes that identifier deterministic across dev, CI, and prod, so your SBOM↔environment↔deployment check is enforceable end-to-end.