Dataplicity vs qbee: Linux fleet management vs connected-product operations #

Choose qbee when your main requirement is disciplined Linux fleet configuration, software and container management, monitoring, and remote access. Choose Dataplicity when those fleet operations need to extend into a product model, downstream customer and site tenancy, customer-facing software, and bounded workflows around the hardware.

qbee is the closest technical comparison to Dataplicity on pure Linux fleet operations, and the overlap has grown. Public docs describe a lightweight pull-based agent, configuration convergence, package and container management, RAUC image updates, monitoring with CVE analysis, remote console, file transfer, and port mapping.

Reviewed against public qbee documentation and agent releases on 7 September 2026.

Why these get compared #

Both target Linux devices that are remote, numerous, and hard to service in person. Both operate behind NAT and firewalls over outbound HTTPS, with no public inbound address. Both support remote engineering access, fleet-wide operational work, and orchestration of an existing RAUC setup.

The main difference is where the product model stops.

qbee: Linux fleet configuration and operations #

qbee documents a state-based, pull-based agent that checks in periodically over outbound HTTPS and converges toward centrally defined state. The platform includes:

configuration inherited by group, tag, or device
package and software management across Debian, RPM, and ipk
file distribution and command execution
Docker and Podman container management, including Compose, container logs, and a remote container shell
RAUC A/B image updates, full or delta, streamed or downloaded, with preconditions and reboot handling
metrics with retention, device-side thresholds, and email notification
inventory covering processes, packages, ports, and containers, with CVE analysis
an Analysis function that compares devices to surface deviations and operational anomalies
remote console, direct file transfer, and TCP/UDP port mapping
fine-grained RBAC scoped by node, tag, and action type, and SAML2 SSO on higher tiers
a REST API that qbee says covers every platform operation

Recent agent releases have added direct remote file transfer, a device attributes command and API, resumable downloads, TPM key-sealing changes, and signed packages with SBOM and SLSA provenance. This is a substantial and actively developed Linux operations toolset, and the overlap with Dataplicity fleet operations is real.

Two consequences for this comparison:

qbee orchestrating an existing RAUC setup is a documented, first-class workflow. Keeping RAUC rather than adopting a vendor-specific updater is not a Dataplicity-only option.
qbee's Analysis compares devices to find deviations, so peer comparison is not absent from qbee. Dataplicity's Pulse differs in being tied to a Device Class as a product definition and in surfacing Issues and Releases as ongoing operating concepts, rather than a comparison you run.

Dataplicity: fleet operations plus the product and customer layer #

Dataplicity overlaps on remote access, fleet jobs, software operations, logs, monitoring, RAUC orchestration, and device inventory. It then adds first-class concepts for the thing the OEM sells and the people who buy it:

Device Classes as durable product definitions
product streams, settings, and customer-safe actions
product-specific customer UI
customer, site, and device allocation
a branded Customer Portal separate from the engineering workspace
Product Applications for customer-scoped records, rules, processes, commands, and offline datasets
Pulse for peer drift and outlier evidence within a product class

That broader model matters when the fleet is not infrastructure you administer, but a product you sell and support for other organisations.

Choose qbee when... #

qbee is the stronger fit when:

your central problem is enforcing Linux configuration state across a fleet
package, file, service, and container management is the dominant workflow
you want a pull-based desired-configuration model as the operational core
declarative convergence suits your team better than job-and-cohort operations
you want one client with remote console, direct file transfer, and both TCP and UDP forwarding
package-level CVE visibility across the fleet is a procurement requirement
the fleet is operated by your own engineering or ops team
you already have the downstream customer application and tenancy model you need

For remote Linux administration, qbee is a serious, technically coherent choice.

Choose Dataplicity when... #

Dataplicity is the stronger fit when:

you need Linux fleet operations and a customer-facing product layer
the same product model should drive software, telemetry, settings, actions, UI, and customer allocation
your customers need scoped access without entering the engineering management console
support workflows need fleet evidence, logs, diagnostics, jobs, and continuous peer drift analysis
you need bounded product workflows or offline datasets around the device
the product is sold as an ongoing service rather than treated as a server fleet

The device-management model continues through to the customer product around the hardware.

Where the overlap is real #

Don't pick Dataplicity because qbee lacks a checkbox with the same feature name. qbee's configuration model solves many practical fleet-management jobs cleanly, including package rollout, file state, services, containers, RAUC images, and remote diagnosis, and it does so with a small statically compiled agent.

Dataplicity port forwarding is also a first-class implementation, not a vague remote-access capability. The native CLI opens any permitted TCP service on an online device as a loopback-only local port:

dataplicity devices port-forward <device-hash> --remote-port 80 --local-port 8080

The CLI applies the account's port policy before opening the tunnel, supports interactive device selection or an explicit hash for scripts, gives each concurrent local connection its own relay channel, and reports live connection, byte, and detected-protocol activity. dataplicity devices ssh builds the SSH workflow on the same forwarding path. The Gateway API and hosted MCP expose the underlying redirect-port service for backend and agent integrations.

The verified protocol boundary matters: Dataplicity forwards TCP. qbee documents both TCP and UDP forwarding, so qbee has broader protocol coverage, not a more first-class TCP implementation.

Likewise, Dataplicity can do bounded fleet jobs and software operations without requiring Product Applications or Customer Portal.

The gap gets much larger once downstream customers, product-specific UI, or multi-customer product operations enter the architecture.

Tenancy: grouping is not the same as a customer product #

qbee can represent customers and sites through hierarchical groups, tags, and scoped RBAC, and its desktop client can switch between separate accounts. That covers a good deal of practical segmentation.

What qbee's documentation does not describe is hierarchical parent and child tenant administration, a delegated customer-facing portal, or white-label branding. Dataplicity's Customer Portal is a separate branded surface where a customer's own users see their sites and devices, product pages, and customer-safe controls, without access to the engineering workspace.

If your customers never log in, this section may not affect your decision.

Decision table #

Decision	qbee	Dataplicity
Primary architecture	Pull-based Linux configuration and fleet management	Linux fleet plus connected-product and customer layer
Outbound agent / NAT traversal	Core	Core
Configuration management	Core strength, declarative convergence	Settings plus bounded jobs, software, and product controls
Package / file / software management	Core strength across deb, RPM, and ipk	Jobs and Software Builds, and coexistence with an existing updater
Containers	Docker, Podman, and Compose management with logs and container shell	Class Software containers selected by a Device Class
RAUC image updates	First-class, full or delta, with preconditions	First-class for qualified RAUC Device Classes
Reference OS image	Not part of the product	Dataplicity OS CM5 image, or your own qualified Linux
Remote console	First-class	Remote Shell
Remote port access	First-class TCP and UDP forwarding	First-class scriptable TCP forwarding through the native CLI, Gateway API, and MCP
Direct file transfer	First-class	First-class through `dataplicity devices remote-file`
Monitoring / inventory	First-class, with metrics thresholds and CVE analysis	First-class plus Pulse and product context
Peer comparison	Analysis compares devices on request	Pulse Issues and Releases within a Device Class
Product model spanning data / control / UI	Not the centre of the platform	Device Classes
Downstream customer tenancy	Groups, tags, and scoped RBAC; no documented parent/child tenants	Customer, site, and device model
Customer-facing product UI	Not described in public documentation	Customer Portal
Product records / workflows / offline data	Not the core product	Product Applications

Where qbee is plainly stronger #

If you operate a private estate of Linux boxes, qbee goes deeper than Dataplicity on several things:

declarative configuration convergence across files, users, services, packages, containers, and commands
native Debian, RPM, and OpenWrt package lifecycle management
package and port inventory mapped to CVEs
Docker, Podman, and Compose operational tooling
a small open-source, statically compiled Go agent with no language runtime to provide on the device
straightforward HTTPS-only networking with proxy support

Dataplicity earns the extra scope when the device is something you ship, support, and expose to customers as a product, or when fleet diagnosis and support need the broader operating model.

Sources #

Primary qbee documentation and first-party releases reviewed:

Dataplicity: