Build a customer experience #

Give customers a branded place to see their devices, read data and use the controls you allow. Add an application when they also need to manage records or run workflows across devices and sites.

Remote access, logs, Pulse and fleet management work independently. If those are your job, go straight to fleet operations.

Give customers access to their devices #

A Customer Portal gives each customer their own view of assigned devices, data and permitted controls, in your brand.

Set up your first customer portal. Finish with a customer signing in and seeing their assigned device. You do not need to build a custom workflow to provide this experience.

Build records and workflows around devices #

A Product Application adds the work around the hardware: for example, customer records, schedules, approvals and processes that run across devices or sites.

Build your first Product Application, or build a Process if you already have an application and need a workflow. Use Product Applications explained for the underlying concepts.

Use a portal that is already set up #

Open the portal operator guide for day-to-day work with sites, devices and applications.

Complete walkthroughs #

Follow one worked example from setup to customer verification. These are alternatives, not chapters to read in order.

Your product	Worked example
Linux appliance or industrial gateway	Linux appliance · Industrial gateway
Camera, level sensor or telemetry device	Camera · Level monitor · Telemetry
Customer records and workflows	Custom application · Paid Wi-Fi · Silo outload · HVAC schedules
A native application starter	Remote signage · Energy site
Edge inference or model-free camera analytics	Edge AI operations · Reference workloads · Model-free video analytics

Decisions and reference #

Look up a question when it becomes relevant. You do not need to work through these before starting a guide. Platform terminology is available whenever you meet an unfamiliar name.

Architecture and adoption questions

Answer the architecture questions first #

Use these to check how Dataplicity fits your existing devices and systems.

Production, security and operating boundaries

Production and operating answers #

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

Compare platform choices

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.

Product patterns and implementation reference

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.

For inference-driven products, continue with Edge AI operations and its five reference workloads. The separate model-free video analytics path uses deterministic local techniques and does not require a neural model.

Workshop library #

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.