Skip to content

Comparing over-the-air update and package strategies

Exploring different ways of solving automated updates for edge devices

In any large IoT installation over-the-air updates and device management are crucial to keep the system secure, stable and operational. There are different strategies to achieve this, also depending on the specific use-case and size of the installation. Some of them are discussed here.

Different embedded device over-the-air update strategies

It is very important that you select the correct over-the-air package update and patch management strategy for your system. Most edge devices are behind firewalls and thus an OTA software update functionality is very important. This article contains some best practices and discussions about advantages and disadvantages of different strategies. This is currently working for all Debian based packages. Thus we cover over-the-air updates for Raspberry Pis, remote software updates for odroid and many other Debian based systems. We are working on similar functionality for RedHat rpm. Please contact us about this if you are interested.

The scope of this discussion are package based update strategies. can be integrated with OTA firmware update tools such as or swupdate but that is not in scope here.

There are two ways to manage, update and install packages remotely:

Most users will want to have a system repository in place. This is why we discuss repositories first.

Should I use a standard repository for base libraries or create my own?

The first question to answer is if you can rely on your upstream repository that comes with the system. Let's assume you run a Raspberry Pi with the Rasbian Buster repository. Usually the libaries released in main (stable) are quite reliable. In this case it might make sense to leave the official Raspbian repositories as main source for apt-get. But if your system is ultra critical or you rely on a much less tested upstream repository it might make sense to clone the repository into a custom one and only add new packages that have been thoroughly tested by your organization. Here you would remove the standard repository. The later allows very granular control but obviously demands a lot of work. On the other hand you can use qbee to define exactly which packages should update and to which version.

Your own repository as overlay or as full repository?

If you decide that you want full control about any package on your device you would need to mirror the system repository into your own and only allow tested packages. Often it is fully sufficient to rely on the upstream repository. Then an own overlay repository can be used to play out own apps and system updates while the base packages come from the upstream repository. Alternatively, you can also distribute own libraries through qbee's software installation thus providing specific versions (potentially patched versions from the qbee file manager). So this allows full flexibility and is described below in software management.

How much work is it to operate a repository?

Luckily there are many tools that help you to do this in a simple way. Two tools we use are and Aptly is great if you want to host this yourself and free of charge. Packagecloud is very good if you want to have a simple hosted solution. It is probably easier to setup and operate.

With the package management function in qbee it is possible to:

  • auto update all available packages with a higher version number or

  • update only specific packages that are added by name

  • select a specific version by specifying that

In both cases the update can happen immediately as soon as new packages are available or it can be controlled by a pre-condition (only once a week, only at night between 3AM and 5AM...). More information about this can be found in our package management topic.

Below you see the settings for "update all" and for specific packages.



Package and software updates with qbee software management

The other option to install and manage packages is to use the software management configuration. This allows to install files from two different sources but it does not update packages automatically if this is not specified in package management.

  • using only the package name installs from defined repositories. It installs the current version if nothing else is specified

  • using a debian conform package name with ".deb" ending installs from the file manager

The later option allows to use a standard repository and overlay updates with packages from the qbee file manager. Just imagine that you have a specific package that you need to patch (maybe something hardware related or a driver). While the standard packages are fetched from the repository this specific package can be distributed as a customized package from the qbee file manager.

Distribute and upgrade your own packages with software management

It is possible to upload own packages through file manager into the qbee platform (please adhere to debian naming conventions). By defining a package name with .deb ending such as "mc_4.8.22-1_armhf.deb" the file will be picked up from the file manager and installed. Any new version can now be defined here and played out. Software management stops the service, updates the package and restart the service. This allows a very simple way of managing patches and playing out new versions of software without the need for a repository.

As a conclusion is very flexible when it comes to selecting package management and upgrade strategies. Please select what fits your use case best. If you have questions you can always contact us and we can have a good chat about this.