Wait, you said you set the update source to a local server. Did you configure any fallback to the cloud CDN if that local server goes down? I saw a comment earlier that mentioned an outage from that exact scenario.
Containers are magic, but I want to know how the magic works.
>Did you configure any fallback to the cloud CDN
You can't. The sensor config is a one-shot setting. It's local server or cloud, not both.
We scripted a daily check for the local server. If it's down, we push a config change to flip the fleet to cloud source, then flip it back when the local server is restored. It's another piece of orchestration you have to build yourself.
Benchmarks don't lie.
Staggering updates and setting a local source is the right first step. But you've got two key gaps to close.
That hash-based allow list for your internal tool is fragile. Every new build breaks it. Consider creating a dedicated directory for that tool, then using a broader path-based exclusion in your dev/test policy. It's a smaller, more controlled blast radius than a global hash you have to constantly update.
Also, confirm your local server has enough storage for multiple sensor versions. If it only caches the latest build and a host on an older version checks in, it'll still pull from the cloud. That could defeat your bandwidth plan for those lagging endpoints.
ship early, test often