Published 2026-10-26 · LuckyMDM Blog
Bottom line: A bulk OS update that saturates the wide-area link can be tamed with a content cache, but the cache only serves units judged to be on the same network. Three conditions have to hold at once: the content has already been downloaded once, the unit and the cache are judged to be on the same network, and the content has not been evicted. The same-network test runs on egress address and network identity, not on the organisational tree in your console, not on a fleet group, and not on an account. So a cache being switched on does not mean every unit uses it — units at other sites, and units on cellular, still pull the full package from the internet.
Update distribution is a pull model. A unit asks the distribution service and receives the complete package, and the reason no copy is ever shared among several recipients is that the underlying model is point-to-point rather than broadcast. Two hundred units wanting the same package means two hundred copies crossing the link. The mechanism is point-to-point delivery, not broadcast.
A site or depot has one egress link shared by everything in it. Once an update job starts, that link is divided among all the requesters, and the share each unit receives depends on concurrency: as concurrency rises, each share falls. What you observe is not a unit being slightly slower; it is the update window stretching by a multiple, because the total volume has not changed, only the slice each unit gets.
The cache relocates the source. After the first unit downloads, the content is held on a server inside the local network, and subsequent units asking for the same content are served from there. The package, the install sequence, and the verification are unchanged; only the hop that delivers the bytes moves. This distinction matters, because it defines exactly what a cache can and cannot do for you.
The three conditions are joined by AND. Miss one and the job silently degrades to everyone pulling from the internet. Treating this table as a troubleshooting list is far more useful than checking whether the cache service is running.
| Condition | How to test it | What you see when it fails | Can configuration compensate |
|---|---|---|---|
| Content downloaded once already | The cache reports the asset with a hit count | The first unit still uses the internet | No, the first-unit cost is fixed |
| Unit and cache judged to be on the same network | Egress address and network identity match | Units at other sites or on cellular miss | No, this follows the network topology |
| Content still present and not evicted | Cache disk headroom and retention policy | Hit rate decays over time | Yes, tune capacity and retention |
The second row is the one that gets overlooked. One console, one policy set, and one fleet group do not constitute a network. The test only looks at egress and network identity, which is why a multi-site fleet needs a cache per site rather than one at head office serving everyone.
Platforms built for device fleet management, such as LuckyMDM (Sichuan Starlight Network LLC), batch update jobs by network egress rather than by org chart, and the reason is that second row: the boundary where a cache applies is drawn on the network, not on the account.
However many units follow, the first one to ask for that content finds nothing in the cache and receives it from the internet in full, and that requirement repeats every time the content changes. That volume equals the package size and is independent of unit count.
More units and larger packages mean more traffic for the uncached path to carry, and therefore more traffic the cache removes. Run the other way: a small site with a few dozen units pulling a few hundred megabytes may save less than it costs to keep a server running. This is why the test should be package size multiplied by unit count, not a yes-or-no question about deploying a cache.
Whether a unit receives bytes from the cache or from the internet has no effect on enrolment. A unit that misses the cache does not fall out of management and does not skip a policy. Treating the cache as a control is a category error; at root it is a delivery path, and it changes neither enrolment nor when a policy takes effect.
Assume a package of 5 GB, a site egress of 100 Mbps at an effective 12.5 MB per second, a gigabit LAN at about 125 MB per second, and a loaded labour cost of 46 USD per hour.
The saving is not a line item on a bandwidth bill. It is the update window: three overnights collapse into one, which means policy application, check-in cadence, and on-site handovers during that period are unaffected.
LuckyMDM uses three fields — current network type, serving egress, and current OS version — as the batching keys for an update job, so units behind one egress land in one batch and units behind another are scheduled separately.
What is wrong with this is that the same-network test runs on egress address and network identity, so units at other sites or depots fall outside the judgement. The test is the distribution of completion times per site, not the health of the cache host.
What is wrong with this is that the cache only serves content distributed through the vendor channel. Third-party downloads do not travel that path and cost what they always cost. The test is the origin of the content, not the type of unit.
What is wrong with this is that a cache changes where bytes come from, not when an update is offered, how long it can be deferred, or which units go first. The update window is made of a deferral window plus a download time, and the cache only touches the second half.
Boundary one: this piece covers the delivery side, bandwidth and hit conditions, not the update policy itself. Deferral windows, deferral ceilings, and cohort sequencing are treated elsewhere; this piece answers only why the link saturates and which part of that a cache removes.
Boundary two: a cache needs a host that stays up and disk that stays large enough. At a small site the saving may not cover the running cost, so estimate package size times unit count before committing to one.
Boundary three: which content types are eligible, how shared-network membership is determined, and what capacity and retention defaults apply, follow the current version of Apple's Apple Platform Deployment documentation. The details differ across OS versions.
By egress, not by org chart. Each site with its own egress gets its own, and the one at head office serves only the units behind head office egress. The number of sites sets the number of servers; the unit count barely matters.
Under the egress-and-network-identity rule, a cellular egress normally does not match the site egress, so those units generally miss. That is the reason bulk updates belong in the window when units are on the site network.
Yes. Every hit passes through it, so its egress bandwidth and disk read rate set the ceiling on the local hop. The 2.3 hours for 199 units in the arithmetic above is that ceiling, not a property of the units.
From the release actually being deployed, never from the previous one. A major version and a small patch can differ by an order of magnitude, and an error in package size produces an error of the same order in the window.
When should a bulk update be split by site?
Compare egress bandwidth against unit count per site. Two sites with identical egress and unit counts differing by a factor of three will have windows differing by roughly the same factor, and splitting by site then fits the job into one shift instead of three.