Binary caches are often treated as mere speed boosts for deployments, but they are fundamentally part of your trust model. When you install an artifact from a cache, you are trusting that it matches your requirements, was built correctly, and has not been tampered with. It is a supply chain decision.
If you don’t build everything yourself from declared inputs, you’re accepting a prebuilt artifact from a third party. This raises critical 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.