Rugix Ctrl 1.4
Rugix Ctrl 1.4 brings faster delta updates, versioned application configuration, and shared storage for container images and other application files.
- rugix
- release
- delta updates
- ota
- embedded linux
We are excited to announce the release of Rugix Ctrl 1.4. 🎉
Rugix Ctrl 1.4 makes dynamic delta updates much faster over HTTP, particularly on high-latency connections. For Rugix Apps, the release adds versioned configuration, staged deployments, and a shared store that deduplicates file content across applications and their versions. It also makes bootstrapping recoverable after interruptions and adds a Nix integration for building bundles and configuring Rugix Ctrl.
Faster Delta Updates
Dynamic delta updates reduce downloads by reusing data that is already on a device. Rugix Ctrl 1.4 fetches the missing data much more efficiently: it combines adjacent missing chunks into larger HTTP ranges, reuses connections, and keeps several requests in flight while the installer verifies, decompresses, and writes the data it has already received. Interrupted transfers now resume with bounded retries. These improvements are enabled by default.
In our benchmark of a monthly Debian update with 40 ms of added round-trip latency, the new fetcher reduced the median installation time from 457.6 seconds to 31.0 seconds compared with Rugix Ctrl 1.3.0. Read Faster Delta Updates for the complete comparison with Rugix Ctrl 1.3.0 and RAUC, including the benchmark setup and its limits.
Delta updates now also happen by default on subsequent updates. Rugix Ctrl 1.4 retains the verified block indices supplied by regular system payloads, so later updates can reuse the installed data. Rugix Bakery bundles include these indices by default. Reusing factory-installed data without matching indices remains opt-in through install.auto-index. See Delta Updates for the requirements and configuration.
Application Configuration and Staged Deployments
Rugix Apps manages application workloads independently of the base system. It installs each application version as an immutable generation and can roll back to a previous generation when an update does not work as expected.
Devices running the same application often need different settings, for example, the address of a site-specific server. Rugix Ctrl 1.4 adds device-specific JSON configuration, which it manages separately from the immutable generations. An app bundle can include a JSON Schema and default settings, and Rugix Ctrl validates the resulting configuration before activating the workload.
Configuration has its own revision history. When an app rolls back, Rugix Ctrl restores the configuration revision that the older generation was last activated with. If the schema of a new generation no longer accepts the current configuration, you can supply a new configuration with --config when installing or activating that generation.
You can now also separate installation from activation. For example, you can download and install an update while the current workload keeps running and then activate it during a maintenance window:
rugix-ctrl apps install --bundle-hash HASH --no-activate my-app-v2.rugixb
rugix-ctrl apps activate my-app 2 --config config.json
Here, HASH is the bundle hash produced by Rugix Bundler, my-app is the app ID, and 2 is the generation number reported by the installation. For signed bundles, Rugix Ctrl verifies the signature against the configured root certificates instead, so you can omit --bundle-hash. Garbage collection keeps a staged generation until it or a newer generation is activated.
Management tools can attach a JSON document with --origin to record the release or deployment that produced a generation, so that they can later recognize the generations they installed. See Application Management and Application Configuration for the complete workflows. Rugix Apps remains experimental, so its interfaces may change between releases.
Shared Storage for Application Files
Keeping several generations of a container workload can consume substantial storage, even when most of their contents are identical. Rugix Ctrl 1.4 adds a content-addressed store for application files, such as container images, shared across apps and generations. The store splits files into chunks, keeps each distinct chunk only once, and stores the chunks compressed as the bundle delivered them.
Docker Compose app bundles packed with Rugix Bundler now keep their container images in this store by default, instead of as files in the generation directory. When activating a generation, Rugix Ctrl streams the images from the store into Docker. When deactivating it, Rugix Ctrl removes the Rugix-owned image tags, so images of old generations no longer accumulate in Docker. Retained generations keep their stored data for later activation or rollback, and garbage collection releases data once no generation references it.
Chunks in the store also serve as local data sources when installing app and system bundles, which gives dynamic delta updates more data to reuse.
Because stored files no longer appear in the generation directory, use rugix-ctrl apps files and rugix-ctrl apps cat to list and read the files of a generation, wherever they are kept. The new rugix-ctrl store commands inspect, verify, and garbage-collect the store. See the store reference for details.
Recoverable Bootstrapping
When a device boots for the first time, Rugix Ctrl can bootstrap it, for example, by growing the partition table and creating the data partition. Rugix Ctrl 1.4 records partition creation and filesystem initialization in a durable journal. If bootstrapping is interrupted, for example, by a power failure, the next boot resumes from that journal and preserves filesystems whose completion was recorded durably. If the disk, the bootstrapping configuration, or the planned partition geometry changed in the meantime, Rugix Ctrl rejects recovery instead of applying an outdated plan to the device. This makes bootstrapping resilient to power failures in the field.
Bundle Inspection and Nix Integration
The new rugix-ctrl bundle inspect command reads a bundle from a file, an HTTP(S) URL, or standard input and reports its manifest, included components, and payload metadata.
For Nix users, the Rugix flake now provides lib.mkBundle and lib.mkComposeBundle for building Rugix bundles and Docker Compose app bundles in Nix. It also provides a NixOS module that sets up the Rugix Ctrl services, the daemon configuration, and app recovery. See the Nix integration guide.
Upgrading to 1.4
Before deploying Rugix Ctrl 1.4, check the following changes:
- HTTPS uses the operating system’s trust store. Rugix Ctrl now verifies HTTPS update servers against the operating system’s CA certificates and no longer embeds a separate set of public CA certificates. Install and maintain
ca-certificateson target devices. Bundle signing roots remain configured independently. - Docker Compose apps use the store by default. Older Rugix Ctrl versions cannot read stored files. If a device rolls back to a system with an older Rugix Ctrl version, a generation installed with stored images can only activate while Docker still has those images, and custom orchestrator scripts that call
rugix-ctrl apps catfail. While devices may still roll back to an older Rugix Ctrl version, pack Compose bundles with--image-location fileto keep the images as files in the generation directory. - Application inspection output changes.
rugix-ctrl apps infonow reports the persisted lifecycle state aslifecycleinstead ofstate, alongside the live workloadstatus. It also omitscreatedAtwhen generation metadata is missing. Update tools that consume this output. - Each app bundle targets one app. Rugix Bundler and Rugix Ctrl reject app bundles with payloads for several apps. No packing command produces such bundles, so this only affects hand-written manifests. Pack a separate bundle for each app.
The changelog lists all changes, including the security fixes from the 1.3 patch releases.
Get Started
Download Rugix Ctrl 1.4 and Rugix Bundler from the GitHub release, or follow the Rugix Ctrl documentation to integrate them into an embedded Linux system.
We welcome feedback and contributions on GitHub. If you have questions or want to discuss a deployment, join our Discord community.
At Silitics, we help companies build robust and secure embedded Linux products. If you need help designing an update architecture or integrating Rugix into an existing platform, we would love to hear from you.
