Overview

Over-The-Air (OTA) updates in qbee provide a flexible and robust framework to remotely update devices with new software, configurations, or even full system images. The qbee platform supports multiple OTA strategies – from simple package installations to full image swaps – so you can choose the method best suited to your project. This overview introduces each supported OTA update method and when to use it, highlighting qbee’s flexibility and reliability in managing updates across your device fleet.

System Package Updates

OTA package management in qbee allows you to update system software through the device’s native package manager. This can target official distribution packages or your own custom packages:

• Native package manager integration: qbee supports Debian (.deb), Red Hat (.rpm), and OpenWRT (.ipk) packages for remote installation and updates. It can fetch packages from your device’s configured repositories or install package files that you’ve uploaded to the qbee file manager.
• Custom package support: By uploading your own package files to qbee, you can distribute in-house or third-party software not available in the default repos.
• Automatic service handling: When qbee installs a software package, it will ensure the corresponding service is started on the device. The platform logs the installation and any service restarts, giving you traceability for the update.
• Controlled roll-out: You can define update pre-conditions (scripts or checks) to ensure packages update only at appropriate times (for example, during device idle hours) to minimize risk of disruption. By default, the update will apply whenever the agent runs, but adding a pre-condition allows fine-grained control over timing.

Docker Container Updates

qbee can deploy and update software packaged as Docker containers. This is useful for containerized applications and services, allowing consistent environments and easy rollbacks via container images:

• Automated container deployment: The qbee agent can pull and run Docker containers from any public or private container registry. You simply specify the image name (and credentials for private registries), and qbee handles downloading and launching the container.
• Self-healing via auto-restart: Containers managed by qbee are supervised – if a defined Docker container stops or exits, the agent will automatically restart it to maintain service uptime. This adds robustness to your deployments, ensuring critical applications remain running.
• Remote access and logs: Qbee integrates remote container management, so you can open a shell into the running container or view its logs through the qbee console. This makes it easy to debug or monitor your containerized app in the field.
• Flexible container configuration: You can provide runtime options such as environment variable files, custom startup commands, or port mappings in the qbee UI (these map to Docker CLI arguments). This allows you to tailor how the container runs on the device beyond just the image name.

Podman Container Updates

For environments that prefer rootless containers or don’t use the Docker daemon, qbee also supports Podman containers. Podman offers a more secure, daemonless container runtime that is increasingly popular in IoT and Linux deployments:

• Podman integration: Qbee can automatically deploy Podman containers from any registry, similar to Docker support. You define the container image and settings in the qbee configuration, and the agent uses the Podman engine on the device to pull and run the container. If Podman is not already installed, you can even install it through qbee’s package or software management features.
• Rootless, secure operation: Because Podman can run containers rootlessly (without a persistent daemon), this method is ideal for systems where security is paramount or where running the Docker daemon is not feasible. It provides an equivalent outcome to Docker deployment but with a lighter security footprint, since containers can run under a non-root user.
• Auto-recovery and config options: Just like with Docker, qbee will ensure Podman-managed containers are kept running – if a container process exits, it will be restarted automatically by the agent. Container definitions support similar options (extra Podman run arguments, environment files, custom commands) so you can fine-tune how the container starts.
• Registry authentication: Qbee’s UI for Podman lets you specify credentials for private image registries when needed, so you can deploy private container images securely (the image name would include the private registry host as required).

Docker Compose Orchestration

For more complex deployments involving multiple containers that work together (an orchestrated stack), qbee supports Docker Compose. This allows you to manage a whole suite of containers (with their networks, volumes, etc.) as a single OTA update unit using a Compose file:

• Multi-container deployments: Docker Compose lets you define all the services of your application in one YAML file. Qbee’s integration with Docker Compose v2 enables you to deploy this file so the agent will bring up the entire stack on the device. Instead of configuring individual containers one by one, you handle them collectively, which ensures the correct interdependencies and ordering.
• Native Compose v2 support: The qbee agent has built-in support for Docker Compose v2 (the Go-based plugin implementation of Compose). This provides a convenient UI in qbee to upload your docker-compose.yml and manage the project lifecycle directly. (Compose v1 projects can still be deployed via a more manual File Distribution approach if needed, but the recommended path is to use the integrated v2 for a smoother experience)
• Consistent and versioned setups: By using Compose, you encapsulate an entire environment (multiple containers, their configurations) in a single versioned file. Qbee applies that consistently across devices, which is great for ensuring all parts of a solution (database, backend, frontend, etc.) update together. You can leverage qbee’s templating to inject device-specific parameters or secrets into the Compose file if needed.
• Additional controls: The Compose configuration in qbee supports features like pre-conditions (only apply the update if certain conditions are met, similar to other configurations) and a Clean option to remove containers that were previously started by qbee but are no longer in the current Compose definition. This helps in safely evolving your multi-container setup over time. Qbee also recommends using immutable image tags (not latest) for reliability, ensuring each rollout is predictable and easy to roll back if necessary.

Full Image A/B Updates

For the most robust, firmware-level updates, qbee integrates with RAUC (Robust Auto-Update Controller) to perform A/B system image upgrades. This strategy replaces the entire device image or firmware using dual partitions, providing a reliable fallback if something goes wrong:

• A/B partition mechanism: In this approach, the device has two system partitions (slot A and B). qbee (via RAUC) will install the new software image to the inactive partition and then reboot the device into that partition. If the new image boots and runs successfully, the update is confirmed; if it fails (e.g. device doesn’t boot properly), the bootloader automatically reverts to the old partition, restoring the previous known-good firmware. This makes A/B updates extremely safe and reliable for critical devices, as they can recover from faulty updates without manual intervention.
• RAUC integration: RAUC is a proven open-source framework for OTA updates in embedded Linux. Qbee’s agent uses RAUC under the hood to handle bundle installation and verification. You simply upload the RAUC update bundle (a .raucb file containing your new image or patch) to the qbee file manager, then configure a RAUC update in the qbee UI by selecting that bundle. The agent takes care of delivering the bundle to the device (with support for streaming the data or downloading fully, depending on device support) and triggers RAUC to install it.
• Delta and streaming updates: RAUC supports not only full image updates but also delta updates, where only the binary diff between the old and new image is sent. This can dramatically reduce download size. Qbee’s RAUC integration accommodates these delta bundles, as well as streaming updates where the bundle is applied on-the-fly without storing the entire file on disk first. These features are very useful for bandwidth-constrained or storage-limited scenarios.
• Use cases: A/B image updates are often used in embedded Linux devices (e.g. IoT gateways, routers, or appliances) where you want to update the entire firmware/OS reliably. It requires your system to be set up for dual-partition booting and RAUC support (commonly done via build systems like Yocto), but once in place, qbee provides a convenient interface to deploy new firmware to potentially thousands of devices with confidence that a bad update won’t brick them.

Custom Scripts

Not every update fits neatly into a package, container, or image. For custom scenarios, qbee’s File Distribution feature, combined with its ability to run post-deployment commands, serves as a catch-all solution. This gives you the flexibility to push arbitrary files (binaries, scripts, configs, etc.) to devices and execute any shell commands for installation or configuration as needed:

• Distribute any file or binary: File Distribution can deliver essentially any file to any path on your devices. This could be a custom application binary, a configuration file, a shell script, or even a whole directory of files. The qbee file manager acts as the source of truth – devices will fetch the file from there, and if the file on a device ever deviates (e.g. gets corrupted or manually changed), qbee can detect that via checksum and re-apply the correct version.
• “Run after” commands: Along with each file distribution, you can specify an optional Command to run after the file is delivered or whenever it changes. This is often used to install the file (e.g. run an installer script, or move a binary into place and restart a service). Qbee will execute this command on the device (as root by default) whenever the managed file is updated or if you trigger a re-run. For example, you might distribute a tarball and use a post-command to unpack it and restart an application. Complex command sequences can be chained with &&, and even background tasks can be started with &. This effectively allows you to automate any update procedure.
• One-off script execution: In cases where you just need to run a script or command on devices without continually managing a file, qbee also supports run-once commands (which can be configured in the File Distribution UI without attaching to a specific file). This is useful for ad-hoc updates or maintenance tasks – for instance, running a database migration script across the fleet.
• Templating and parameters: File Distribution supports qbee’s configuration templating system, meaning you can include placeholders in your distributed files (or commands) that get filled with device-specific values or secrets. This is powerful for customizing config files or scripts per device at deployment time, while still using one template file.
• Ultimate flexibility: Essentially, this method can cover any OTA update that the above specialized methods do not. It’s the most flexible because you define exactly what happens. For example, you could use it to deploy a Python virtual environment, update a machine-learning model file, or execute a series of CLI commands on the device. As the documentation notes, file distribution “can solve basically any configuration management use case,” from distributing simple scripts to orchestrating complex updates.