Introduction
If you're building a product with hundreds of units deployed in the field, device management is something you'll need to think about in advance: how will you push updates, access devices remotely, and keep a growing fleet consistently configured?
Let's use the Grinn GenioBoard - Edge AI SBC to walk through how you can solve exactly that.
The Grinn GenioBoard is an open-hardware single-board computer designed for production-grade edge AI products. Powered by the MediaTek MT8390 processor with a 4 TOPS NPU and an M.2 expansion for external AI accelerators, it is a capable, flexible hardware foundation for developers.
To help you manage edge AI devices at scale, we've partnered with Qbee - a solution that brings fleet management, OTA updates, and remote access to any Linux-based device via a lightweight qbee-agent.
Managing a Grinn GenioBoard Fleet at Scale
Qbee is a pull-based Linux fleet management platform. But how does it work, exactly?
Once you deploy a lightweight qbee-agent on the Grinn GenioBoard, it connects to the Qbee cloud over outbound HTTPS (port 443). It polls at a configurable interval for its current desired state, applies any changes, and reports status back.
Because the board initiates all communication, you can deploy it behind NAT, on a mobile network, or inside a facility with multi-layer firewalls - no special network configuration is needed on your end.
Together, the Grinn GenioBoard and Qbee give you everything you need for production deployments:
OTA software and firmware updates
Remote terminal access and secure port forwarding
Continuous configuration management with drift detection
Device monitoring: CPU, memory, disk, temperature, custom metrics
Role-based access control and audit logging across every change
The qbee-agent runs natively on both Yocto and Debian - the two officially supported operating systems for the Grinn GenioBoard. If you are prototyping on Debian, installation is as simple as dropping in a pre-built package.
For highly customized production builds, the agent can be integrated directly into a Yocto layer (meta-qbee), ensuring your management tooling is baked into the image from the start.
Pushing Updates Across Your Entire Fleet
Say you have 500 Grinn GenioBoard units deployed across factory floors, each running an AI vision pipeline, and you've decided to retrain your inference model. How do you get that update to every unit?
With Qbee's desired-state model, you define a target configuration or software version in the console and the platform stores it on the server - nothing is pushed to your devices immediately. On each device's next poll, the agent downloads the new desired state and converges. It installs packages, distributes files, and updates containers. Because convergence is idempotent, you don't need to worry about a unit receiving the same operation twice.
When it comes to offline devices, if a unit is unreachable when you deploy an update (e.g. due to intermittent connectivity or scheduled downtime), the desired state simply waits on the server. When the device comes back online, it polls and converges - whether it was offline for an hour or a month.
For Docker-based workloads, Qbee's container orchestration allows individual application containers to be updated independently of the underlying OS. This lets teams operate on separate update cadences: application updates (e.g. an updated configuration) can ship monthly, while OS-level updates follow a more conservative quarterly schedule.
Reaching Any Device, No Matter Where It Is
If something goes wrong with a deployed unit, you can reach any Grinn GenioBoard in your fleet via terminal - directly from the Qbee console or via SSH from your local machine, with no public IP or open inbound port required.
Port forwarding goes a step further: you can expose a service running on the device - such as a web UI or a local API - as if it were running on your own machine. A misconfigured network interface or other issue can be diagnosed and fixed remotely, without anyone needing to visit the site.
Keeping Your Fleet Consistently Configured
At some point, something on a deployed device will change unexpectedly - for example, a config file that gets edited manually. The agent re-evaluates the desired state on every poll cycle, so any divergence is detected and corrected automatically, without any action from you. There's no need to track which devices received a change and which didn't.
You can organize your fleet using groups and tags, with configuration applied hierarchically. A change scoped to a group propagates automatically to every member. When you bootstrap a new Grinn GenioBoard into your fleet, it inherits its group configuration immediately.
Every change is recorded in the audit log with a timestamp and the identity of whoever made it, giving you a clean compliance trail if you need it.
Summary
The Grinn GenioBoard gives you a capable edge AI hardware foundation, with high-compute SoC, flexible I/O, M.2 expansion for accelerators, and a production-ready SoM design. Qbee extends this by adding the operational layer that makes your fleet manageable.
Teams can deploy confidently knowing that updates reach every unit regardless of network conditions, that configuration stays consistent without manual enforcement, and that any device in the fleet is reachable for diagnostics without network reconfiguration.
Visit the official Grinn GenioBoard page for technical specifications and more details about this single-board computer. For more information about the device management solution, visit the Qbee website.
Paweł Horbanowicz
