People talk about binary caches like they’re just a speed boost. Sure, they save time and make things easier to deploy. But that’s only half the story. Binary caches are part of your trust model. When you install something from a cache, you’re trusting that the artifact matches what you wanted, was built the way you’d expect, and hasn’t been tampered with. That’s not just about convenience—it’s a supply chain decision. If you don’t use a cache, you build everything yourself from the declared inputs. If you do use a cache, you’re accepting a prebuilt artifact from somewhere else. That raises some big questions:
If you can’t answer these, you’re not just using a cache—you’re inheriting trust from a black box. It’s easy to think a cache hit is always good news. It just means you skipped some work, not that you gained confidence. Confidence comes from knowing:
The more important the software, the less you can ignore these questions. Nix can check that a binary was signed by a trusted key. That’s important, but a signature only says someone vouched for it—not that the build process was solid. A signed artifact could still be:
Crypto checks are necessary, but not enough on their own. Not every package is equally risky. A throwaway dev tool? Maybe you’re fine with a public cache. Production code, regulated systems, or sensitive data? You might want to build those yourself or use a cache you control. Reasonable strategies:
This isn’t paranoia—it’s just recognizing that where your software comes from matters. A cache shouldn’t just show up in your config because a guide said so. It should be a deliberate part of your policy. If you use a cache, be clear about:
If you don’t have answers, you don’t have a trust model. You just have a shortcut to production.
See also: