[0x6c6f6c]

Since no one responded, they're running on Kubernetes, where a unit of containers is called a "pod". A pod may be one or more containers, but it's the smallest deployable unit in the Kubernetes space.

Their docker images were 11-35GB. Using the nix dockerTools approach would have resulted 100-300MB layers. These also may not even cache well between tags, though that's my intuition not knowledge. Especially if that's true, it wouldn't have improved the overall pull time issues they were having, which was 70-210s or image pull time on many new builds.

In their case they added a sidecar container which was actually an init container, which runs before the primary container of the pod runs. They did utilize root privileges to perform things like bind mounting of nix store paths into the running container which made it possible for the container to run software provided in the /nix/store available from those bind mounts. This also meant both the Kubernetes hosts and containers did not require the nix daemon, the nix-sidecar running within the pod orchestrated pulling derivations , binding them, and running garbage collection at low priority in the background to ensure host SSDs don't run out of storage, while still allowing referenced derivations in the cluster to persist, improving sync time where the SSD may already contain all necessary derivations for a new pod startup.