The product is a platform for the equipment
The starting point is the device fleet: what equipment exists, who owns it, which firmware it runs, whether it is connected and what it can do. The application organizes this information by equipment type and organization, with users and permissions. It provides a shared foundation for different products without rebuilding fleet management for each project.
On that foundation, the system provides registration and provisioning, presence monitoring, status and history, event catalogs, remote procedure execution and versioned configuration. Artifacts and update workflows support ongoing maintenance. The web interface gives teams access to these functions, while APIs let them integrate with other applications.
A vending machine, for example, needs to report a fault, receive configuration and support a diagnostic query. The content of each operation belongs to the product. Identity, communication, history and access management can share the same platform.
MQTT is the transport; Dextro IoT Protocol is the contract
MQTT handles publishing and subscribing to messages. The Dextro IoT Protocol, whose core also appears in the project as Atrio Core, defines the meaning of an exchange: which device is speaking, what operation is requested, how to recognize its response and how to handle retries, expiration or unavailability.
The core separates two needs: an immediate response and a delivery that must survive a disconnection. These are organized into four primitives. Mailbox flows build on the protocol’s own calls, keeping the communication contract consistent.
| Primitive | Direction | Purpose |
|---|---|---|
| Remote-procedure | Device → backend | Call a service and obtain a response within a deadline. |
| Device-procedure | Backend → device | Execute or query a remote operation. |
| Inbox | Device → backend | Persist information with acknowledgment and deduplication. |
| Outbox | Backend → device | Store pending work for the device to retrieve and acknowledge. |
One platform, from firmware to operations
- 01
Device
Firmware implements procedures, events and configuration.
- 02
MQTT + TLS
Authenticated connectivity and per-device topics.
- 03
Dextro IoT
RPC, mailbox, presence and per-type contracts.
- 04
Web application
Fleet, commands, history and business integration.
Dextro controls the device contract; Kubernetes organizes where and how the services run.
How a call finds the right response
Each request carries metadata, op and payload. Metadata includes the protocol version, device identity, timestamp, messageId and relationId. The messageId identifies the message; relationId correlates the request/response transaction. A response adds rescode to distinguish success, rejection, unavailability and timeout.
For calls to a device, instance identifies the backend instance that originated the request. The response returns to that instance’s topic and is matched to the device and relationId. This prevents a response received by a different pod from being treated as a local call’s reply.
For device-to-backend requests, the service uses EMQX shared subscriptions to distribute requests across replicas. The envelope, identity and deadline are checked before processing. Scaling the service does not require firmware to know the pod names or replica count.
Unstable connectivity requires more than publishing a message
An immediate query has a deadline; pending configuration can wait for the device to reconnect. RPC and outbox therefore behave differently. In immediate mode, the platform reports unavailability or timeout. In durable mode, work remains persisted and the device pulls it, applies it and acknowledges the result.
The inbox handles device-submitted information using entity identity and version. Business deduplication relies on those identifiers rather than messageId alone. Batched events also carry a sequence and occurrence time; the backend reports what it accepted, recognized as a duplicate or rejected.
MQTT QoS 1 can produce redelivery. End-to-end reliability comes from persistence, acknowledgment and application idempotency rules. For an operation that actuates hardware, firmware and business logic must define how to handle a retry safely.
A small core, extended for each product type
The protocol keeps a core of common operations and allows product-specific procedures to be registered. list-procedures and list-services expose the available capabilities. In the platform, per-device-type contracts define input and output schemas for business operations.
This allows a diagnostic function or automation operation to be added without inventing an entire protocol for each piece of equipment. A call can be exposed through the REST API or used by another platform service while retaining validation, authorization and execution records.
Configuration is an application capability: per-type templates populate versioned collections for each device, with history and synchronization. The server maintains the mirror; the device applies configuration and reports its version. The protocol core does not require AWS Device Shadow or Azure Device Twin semantics.
From device identity to business applications
Device communication uses certificates and mTLS with topic permissions. The identity declared in a message must match the authorized connection identity. This ties data and commands to the correct equipment rather than trusting a serial number supplied freely in a payload.
On the application side, sessions, organization context and authorization determine what each user or service can read and change. Devices integrate with other capabilities through APIs and the Uhura mesh, using events and RPC. Presence and events can feed applications, notifications and operational workflows without placing all business logic in firmware.
The project’s C/C++ clients and platform abstractions support integration across embedded targets. The operational contract stays consistent; hardware resources, transport libraries and persistence strategies remain decisions for each product.
Where Kubernetes fits
Kubernetes organizes service execution: the web application, device backend, business services and their dependencies. The project infrastructure uses K3s, EMQX, PostgreSQL, RabbitMQ and observability services, with deployments described in Git and synchronized by ArgoCD.
Portability comes from the combination of packaged services, understood dependencies and platform-controlled contracts. Kubernetes alone does not make a product vendor-independent: if firmware and backend remain coupled to provider-specific APIs, that dependency persists. In Dextro, the project controls the protocol and application layer.
How this reduces AWS and Azure coupling
Equipment communicates with the Dextro platform using MQTT and the Dextro IoT contract. Registration, configuration, procedures and mailbox are application functions. This communication path does not require AWS IoT Core or Azure IoT Hub, nor does product logic have to be organized around their device-management APIs.
The platform can still use AWS or Azure infrastructure when that is the right hosting choice. It also creates a path to another provider or privately operated infrastructure. Hosting decisions follow cost, operations, region and connectivity needs while preserving the device’s application contract.
Migration still requires planning for data, certificates, DNS, endpoints, networking, storage, backups and capacity. The benefit is the ability to change hosting without redesigning the business protocol or replacing product logic with a different proprietary IoT API.
What changes in the cost model
Managed services have their own pricing models. AWS IoT Core meters components such as connectivity, messages, registry/shadow operations and rules. Azure IoT Hub uses capacity units and message allowances, alongside operation-metering rules. Running this path in our platform removes dependence on those specific managed-service charges.
Costs are then driven by infrastructure and operations: compute, memory, storage, traffic, backups, observability, maintenance and support. The chosen solution may also involve software and service contracts. Operating our platform does not make messages, devices or operations free; it changes who controls the architecture and how capacity is purchased.
Potential savings should be assessed using total cost of ownership. For a known fleet and traffic pattern, retention, load and growth can be estimated and the managed-service scenario compared with Dextro. The decision also accounts for operational effort and the value of flexibility, without assuming universal savings.
Value for teams bringing a product to market
Dextro Cloud provides an application foundation for connecting products, making fleets visible and supporting remote maintenance. Manufacturers can focus development on equipment functions while sharing a communication and operations layer. Integrators can connect the platform to customer processes without turning firmware into a collection of vendor dependencies.
For teams in the United States and Brazil, the proposition is the same: turn connected equipment into a manageable operation, with clear interfaces and freedom to choose infrastructure. Work starts with the product, the workflows that must function and the operational requirements. The cloud should support those decisions.