Build the customer product #

Use this section when the Linux device is something you sell or provide to a customer. Dataplicity adds the product definition, fleet software, support workspace, and optional customer application around the hardware and product software you already own.

Customer portal building workplace showing zones and schedules — The destination is a customer product application organised around the place and the devices that run it.

Choose the path #

Your starting point	Open
Learn the names first: Device Class, device, Software, Product Application, portal, network	Platform nomenclature
Connect and operate a Linux product without a Customer Portal	Connect and operate without a Customer Portal
You need the generic device-to-customer activation path	Build your first connected product
You need customer records, rules, durable processes, commands, or offline datasets around the hardware	Product Applications
You need to build and test a durable workflow	Build a Process
You need to package and deliver device-side OCI software	Software workspace
Your devices already use Dataplicity Remote Shell	Expand beyond remote access
You need to understand the customer-facing application	Customer Portal
You operate native applications across sites and devices	Portal operator guide
You need one complete vertical walkthrough	Choose a worked product

Answer the architecture questions first #

These pages answer the questions most teams have before they are ready to follow a product recipe. They are written around the decision you are making, not the Dataplicity feature name you would need to know in advance.

Production and operating answers #

Use these when moving from a prototype or existing fleet into a repeatable production operating model.

Compare platform choices #

These comparisons are architecture guides for technical buyers, not feature-score marketing. They are based on current first-party documentation, state where the other product is the better fit, and separate shipping capability from roadmap.

Start from a product pattern #

The same platform primitives should produce different customer products, not one generic device dump. These reference architectures show the product boundary, support workflow, data/control contract, and customer experience for representative product types.

Define the product once #

Device Classes define the hardware and product model.
Streams, actions, and settings define its stable product contract.
Product UI designer turns that contract into the customer page.
Software workspace combines class I/O, containers, optional OS selection, Builds, cohorts, and delivery evidence.
Customer Portal creates the downstream customer boundary and operating application.

Illustrative Dataplicity Device Classes list with Edge Gateway, Retail Controller, and Environmental Sensor product models — Device Classes keep distinct hardware products separate before software, data, controls, and customer layout are added.

Build and prove a Product Application #

Use the Product Application workspace as a development lifecycle rather than a collection of unrelated forms:

Build a Process for durable customer and device workflow.
Choose Cloud, Edge, or Mixed placement for the failure and connectivity model you actually need.
Test with Scenarios using repeatable fixtures, deterministic responses, and safety assertions.
Investigate executions against the exact published definition and path that ran.
Design the Application Workspace that customers use for overview, work, exceptions, records, and maps.
Author semantic composition for capacity, timeseries, and shared event overlays; browse the widget catalogue.
Connect APIs and integrations without duplicating authoritative business state.
Release and roll out after diagnostics, required Scenarios, and publish warnings are resolved.

Complete walkthroughs #

These articles are designed to be sent to one implementer. The list matches the Product nav and Product Applications overview.

Workshops #

Kit recipes #

Camera, industrial gateway, level, and telemetry begin with the physical product and its Device Class. Paid Wi-Fi, outload, HVAC, and the custom PolarVend guide focus on Product Applications: customer records, workflow, commands, and offline or generic data around one or more hardware roles. Signage and energy are shorter kit recipes for native workplaces.

Product and engineering boundaries #

Your customer sees assigned products, locations, product data, video, and permitted controls. Your OEM team keeps logs, diagnostics, Remote Shell, software delivery, fleet jobs, and peer drift in the separate engineering workspace.

Dataplicity does not replace your Linux distribution, product application, secure boot, OS hardening, sensor calibration, physical safety logic, or firmware-update architecture.