Fleet Management Overview

Preview Status

Warning

The RDFM fleet management integration is currently in preview only and available only on request. The implementation, APIs, and features described on this page may change in future releases.

Introduction

The Bunker-Centric Architecture reference design integrates with a customized version of RDFM (Remote Device Fleet Manager), an open-source fleet management platform to provide device management and Over-The-Air (OTA) software updates for deployed devices. The reference design implementation uses RAUC (Robust Auto-Update Controller) instead of the upstream Mender implementation, providing a lightweight and deterministic update mechanism.

The RDFM Linux Device Client (rdfm-client) runs in the Open World of each device and maintains a persistent connection to the management server over HTTPS and WebSocket. Because rdfm-client is network-connected and runs in Open World, it supports remote shell access, remote command execution, file retrieval, and telemetry collection from the Open World environment.

Note

For exposing security-critical telemetry and metrics from Bunker OS to operators, a separate set of management services is under development. See the note at the end of this section.

Architecture

The RDFM fleet management stack consists of three main components: the management server, the device client, and the web frontend. From the server’s perspective, each connected device is an entity identified by its MAC address. The server maintains a registry of all registered devices, their metadata, and their current software version. Devices are grouped into named deploy groups, and update packages are assigned to groups rather than individual devices. This allows a single update assignment to cover an entire fleet or a targeted subset thereof.

        graph TD
    subgraph Cloud["Fleet Management Backend"]
        Server["RDFM Management Server (REST API + WebSocket)"]
        DB["Database (SQLite / PostgreSQL)"]
        Storage["Package Storage (Local / S3-compatible)"]
        Frontend["RDFM Web Frontend (Dashboard, groups, devices)"]
        Server --- DB
        Server --- Storage
        Frontend -->|"HTTPS REST API"| Server
    end

    subgraph Device["Reference Design Device"]
        subgraph Core["Bunker OS"]
            Services["Core Services"]
            RootfsB["A/B Root Filesystem (RAUC managed)"]
        end
        subgraph OW["Open World"]
            Client["rdfm-client daemon"]
            Apps["User Applications"]
            RootfsOW["A/B Root Filesystem (RAUC managed)"]
        end
    end

    Client -->|"HTTPS - OTA polls, WebSocket - shell, actions, files, telemetry"| Server

    Operator["Operator / CI Pipeline"]
    Operator -->|"Upload packages - Manage groups"| Server
    

The device client communicates with the server over two channels. For OTA update checks it uses standard HTTPS polling. The client sends its current metadata (software version, device type, MAC address) and receives a signed download URL if a newer compatible package is available. For real-time management operations the client optionally connects to a long-lived management WebSocket that the server uses to push commands such as reverse shell requests, action execution triggers, and update progress queries. The server never initiates direct connections to devices; all communication flows through channels that the device itself established outbound, which means devices behind firewalls or NAT remain fully manageable.

The web frontend provides a graphical interface for day-to-day fleet operations: registering and authorising new devices, creating and managing deploy groups, uploading update packages, assigning policies, and opening remote shell sessions. All operations available through the frontend are also exposed programmatically through the RDFM REST API, making it straightforward to integrate fleet management actions into CI/CD pipelines.

Supported Features

The following fleet management capabilities are available on reference design devices:

OTA Updates

Devices receive robust A/B partition full image updates managed by RAUC based on their membership in deploy groups. The server maintains a registry of available packages and can assign them to device groups. Each package contains a complete rootfs image that is installed to the passive partition. A successful update results in the new software being committed to the passive partition; if the update installation fails or the system fails its health checks after boot, RAUC automatically triggers an automatic rollback to the previously running partition. See Ship OTA Updates for the full update system reference.

Remote Shell (Open World)

Operators can open an interactive shell session on the Open World of any connected device directly from the web frontend or command line. The shell is spawned inside the Open World Linux environment and streamed through the management WebSocket. Up to five concurrent sessions are supported per device by default. See Device Management for configuration and security details.

Remote Actions (Open World)

Predefined command sets called actions can be defined in Open World via a JSON configuration file and triggered remotely from the server. Actions execute synchronously in Open World and return their output and exit status back to the server. A persistent queue ensures that actions requested while the device is offline are delivered once connectivity resumes. See Device Management for the actions configuration schema.

File Retrieval (Open World)

Operators can download files from the Open World environment of a running device without requiring shell access. The client transfers the requested file to an intermediate storage location (local or S3, depending on server configuration) from which the operator can download it. Downloadable paths can be restricted to a configurable base directory. See Device Management for configuration options.

Telemetry (Open World)

The client can be configured with a set of loggers, arbitrary executable scripts or binaries that run at predefined intervals and capture their output for transmission to the server. This provides a flexible mechanism for collecting Open World system metrics, sensor readings, or custom application data. See Device Management for the telemetry configuration schema.

Bunker OS Telemetry (Preview)

A separate set of management services for exposing telemetry and events from Bunker OS is currently under development. These services will allow operators to collect security-critical metrics and audit logs from the secure domain.

Integration in the Reference Design

The rdfm-client daemon is built into Open World images produced with the meta-rdfm Yocto layer (reference design custom fork). The layer handles RAUC bootloader integration (U-Boot A/B boot selection) and partition layout, which are prerequisites for robust OTA updates with automatic rollback. It is not necessary to integrate RDFM manually into a Yocto BSP; the layer provides the required recipes and configuration files out of the box.

For deployments that require customizing the client configuration (server URL, update poll interval, shell permissions, action definitions, or Open World telemetry loggers), the relevant configuration files are described in detail in Device Management.

The management server itself is a containerised Python application that can be deployed on any infrastructure capable of running Docker. For development and preview use, it can be run with SQLite and local package storage. Production deployments should use PostgreSQL database, S3-compatible object storage, an OAuth2-compatible identity provider (such as Keycloak), and an HTTPS reverse proxy. A reference Docker Compose stack that includes these components is described in Server Deployment.

Next Steps

• Ship OTA Updates - packages, groups, update policies, RAUC integration, and delta update resolution

• Device Management - device lifecycle, Open World reverse shell, remote actions, file retrieval, and telemetry

• Server Deployment - management server setup, storage backends, authentication, and deployment considerations