Can a Content Caching Server compensate for lost standalone updates?

So far, there have been two updates to macOS Big Sur 11: 11.0.1 may seem irrelevant, as that was the version released for Intel Macs on 12 November, but was an important update for those with the first M1 Macs, which shipped with 11.0; 11.1 was released just over a month later on 14 December. We can expect 11.2, which is already in beta, early in the New Year, and the usual succession of updates through 2021.

As it stands, Apple hasn’t been releasing standalone update packages for Big Sur which you can download to update multiple Macs or generate any minor version when you wish. We don’t know yet whether Apple will restart that service, or (if our voice is heard) when it might do so. Some have suggested that there are now solutions which are as good if not better, of which the favourite is the macOS Content Caching Server. This article looks at how you might use that instead of relying on those missing update packages.

Originally, Apple’s Content Caching Server came as part of Mac OS X Server, a costly option unless you bought – as I did – an Xserve. Running as one of several network services on an Xserve or other dedicated Mac server, it was valuable, but expensive for smaller networks or individual users with multiple Macs. When Apple dismantled its Server product, the Content Caching Server was transferred to the client version of macOS, as one of the unsung features of High Sierra.

It’s designed to be simple to use, and fully functional on a Mac which is used for other purposes too. Setting it up is easy, but more advanced administration requires use of the command line, either to set unexposed preferences, or through its command tool AssetCacheManagerUtil. An introduction to those is provided here, and there are more details in the man page for that tool.

What you need

The server works best on a Mac which has computing power to spare, good local network and Internet connections, suitable free storage for cached data, and which is running as much of the time as possible. That said, users run it on older Mac minis alongside other services, and even on laptops. To get best value from it, though, you should ensure that it has ample storage for its cache.

My Content Caching Service is running on my production Mac, a base specification iMac Pro, which runs all the time, has System sleep disabled, and I happen to have 1 TB of storage available externally which is now set aside for caching.

Setting up

If you’re configuring a single server on a simple local network, there aren’t too many options to worry about. I chose to cache all content, which includes that in iCloud such as Photos libraries, but as my other systems each have their own connection to my router, I’m not sharing the Internet connection as well.


Click on the Options button to set the cache location and its size.


Tabs are made available if you hold the Option key before clicking the Options button, which then becomes Advanced Options. This lets you set up clients, as well as other servers functioning as peers or parents, on more extensive networks.


The next time that each of your Macs starts up and connects to your local network, it will then automatically use that Content Caching Server to obtain updates, App Store apps, other content, and iCloud files. That’s all there is to it.

How it works

When a client uses Software Update, the App Store, iCloud, and related services, those connections are made through your server. For example, if you opt to install a macOS update from your MacBook Air, instead of requesting that direct from Apple’s servers, your local server is asked instead.

If the local server already has a copy of that item in its cache, it will be delivered very rapidly without any of the constraints of your Internet connection. So long as your server can keep items in its cache, they’ll be supplied as fast as local network connections permit. If the local server doesn’t have the item requested, it downloads it and streams that item to the client, keeping a copy in its cache.

This spares you multiple downloads. If you have four Macs, each of which needs to be updated to macOS 11.1, the server only downloads a single copy of the update, and serves it to each of those four Macs, resulting in significant economy.

There are several important details to bear in mind. This doesn’t allow a client to install an update more than once. If something goes wrong and the first attempt to install that update causes problems, there’s no repeat button: if that Mac thinks the update has been applied, you can’t force your server to offer it again to that client.

Neither, it appears, is there any way of extracting a standalone installer from the updates cached locally. They’re stored in folders named with UUIDs, referenced by an SQLite database – not easy for you to manipulate, and quite opaque.


Of course you can still extract items which are themselves standalone, such as macOS installer apps, using the normal process on a client. To obtain the current Big Sur installer app, locate it in the App Store and get it from there. That opens the Software Update pane, which connects to your server and – provided that has already been cached by the server – a few minutes later the 12.2 GB installer app will be saved to your Applications folder, from where you can make a copy for safe keeping.

Because Big Sur updates don’t come as standalone packages, that scheme doesn’t work for current macOS updaters. They must be installed in the usual way, through the Software Update pane, so the Content Caching Server isn’t a method of obtaining traditional ‘delta’ or Combo updates.

How you could use Content Caching

There are many different use cases for standalone installer packages. Here I consider just four which I’m most familiar with.

Reinstalling an update: if you suffer problems after installing a macOS update, one of the traditional remedies is to reinstall that update, or, if that fails to fix it, to install its Combo updater. In theory, for items included in Big Sur’s SSV this should no longer be necessary, as each successful update must exactly match Apple’s blueprint for the updated system, or its seal will be invalid. However, that doesn’t cover system files which are installed on the Data volume, including Safari.

As I’ve explained above, Software Update won’t offer an already-installed update, so the only way to address this is to obtain the full installer app for each version of macOS, and keep that. The Content Caching Service makes this easier to perform on multiple Macs, but the full installer still has to be downloaded once, which it wouldn’t be in older versions of macOS.

Installing Combo updates as a panacea: this is a well-established procedure which may appear unscientific but has a good track record, even in recent versions of macOS. It’s similar to the need to reinstall an update, but using only a Combo updater to refresh as much of the system without reinstalling the whole of macOS. Where Macs may be running older minor releases of macOS, this requires you to keep a copy of each full installer app, and to reinstall the whole of that version of macOS. The server merely makes it easier to obtain more than one copy of the installer app.

Reinstalling Safari or another part of the system which isn’t stored on the SSV: in the past, Apple has provided separate and standalone installer packages for some versions of Safari, but has discontinued that too. The only way to reinstall any particular version of Safari in Big Sur is to install the whole of that version of macOS using its installer app. Content Caching provides no shortcut for that.

Create any version of macOS: previously, developers, security researchers, and others have kept a copy of the initial major release of macOS, from which they can generate any subsequent minor version by installing that followed by the relevant Combo update. In the absence of the latter, the only way to achieve this is to keep a copy of the installer app for every minor release. Again, this isn’t helped particularly by the Content Caching Server.

Although the Content Caching Server is very useful for many users, and merits serious consideration by anyone with more than one Mac, it doesn’t address any of the use cases which have been put forward for the continuation of standalone software update installers. That said, I’m going to leave mine running to save me having to download multiple updates to Big Sur.

I’m very grateful to Antonio for starting this discussion, and for making me better informed on the benefits of this service.