pfSense

Hypothetical solution with use with 2100-MAX and the 30GB drive:

Containerized updates? Just update with a Jailed containerized download, it downloads while the other Jail is in use, after the update is pushed swap to the other Jail as the primary and leave the other as standby for next time. Why even wait for the new download right? Just like AMO the OS that runs the Siemens Hicom PBXs, they use of dual boards, they have a primary and a secondary. To update software changes in a Hicom PBX you run the command "EXE-updat: BP, ALL;" two times so it sends the updates and changes to each board, when the command is run it changes the active board from 1 to 2 and after back to 1. same with EXE-updat : A1, ALL; they have an active and a standby. We have the software to do this with software updates now with containers, lets update the firewalls like this. Right?

This is a proven solution within currently in use as a hardware design for large scale PBXs. We just need to retool this within the context of containers configurations for use with PfSense firewalls software improvements.

This could give pfSense a redundency option for updating software, as well as a fail over to quickly revert back to the older versions on a failed inplace upgrade.

Hypothetical:
If the Jail is set up just to hold a update it could self-check changes within that update and so on within the two containers, once an update starts for the standby jail, it just swaps in as the primary and you never see any downtime, the primary becomes the secondary and waits until the next scheduled update.

Maybe the solution is that we need a different kind of download, "a Jailed containerized download," One container holds the primary useable software, and once it is ready to be live it just swaps to the other container.