Use the customer portal for your product

Use this path when you manufacture or integrate Linux hardware and want your customers to operate it through a vendor-branded portal.

You build and configure the product in Dataplicity. Your customers sign in to your customer portal on your-vendor.dvcmgr.com or a configured custom domain. They do not need access to your engineering workspace.

What you need

• representative Linux hardware with a supported Dataplicity agent
• a Device Class for the product line
• the customer-portal module enabled for your organisation
• a customer or site structure for assigning deployed devices
• a field-agent release with the local stream broker if the page will show live product data

Start with one staging device. Do not make the first production shipment the first test of class software, portal access, or the customer-facing layout.

Choose how much of the stack you need

The customer portal does not require a Dataplicity-managed container.

Customer outcome	Stream publisher needed?	Class-managed OCI needed?
See inventory, assignment, and connectivity	No	No
Open a device page with identity and connectivity	No	No
Read live product values in page widgets	Yes	Only when Dataplicity should install and version that publisher
Learn the complete stream and page flow without sensors	Yes	Use an example simulator

If your product already has a systemd service, Docker workload, Greengrass component, balena service, or custom supervisor, keep it. A compatible process can publish to the same local agent broker when its runtime can reach the loopback listener. Class software is the managed deployment path, not a second telemetry path.

1. Connect and classify the hardware

1. Install the agent using the instructions supplied for the agent release used by your programme.
2. Confirm the staging device appears online.
3. Create a Device Class for the product line.
4. Record supported architectures, deployment model, and hardware profile.
5. Assign the staging device to the class.

Do not reuse a class identity for a different product. Provisioning, software, page layouts, and customer records can all depend on it.

2. Decide where application software runs

Choose one of three patterns:

1. No stream publisher. Use portal inventory and connectivity only.
2. Your existing application publishes locally. Keep your runtime and send class stream samples to the agent broker.
3. Dataplicity manages the publisher. Build an OCI image, upload it on the class Software tab, pin it in firmware, and let the field agent run it.

Every telemetry pattern uses the same trust boundary:

flowchart LR
  Publisher["Your process or class OCI"]
  Broker["Local agent broker"]
  Agent["Dataplicity agent"]
  Platform["Dataplicity"]
  Portal["Customer portal"]
  Publisher -->|"Stream sample"| Broker
  Broker --> Agent
  Agent --> Platform
  Platform --> Portal

The publisher does not receive a device API key and does not upload directly to a cloud API. See Build a class container for the managed OCI path and Device class streams for the binding model.

3. Define the customer-facing data

Create one class stream on UI Components for each value the page must present. Use a stable ID and an explicit unit. Keep source-specific details inside the publisher; the page should consume a product concept such as temperature or tank volume, not a GPIO pin number.

Publishers send samples to the local broker. The agent owns authentication, buffering, retry, and delivery to Dataplicity.

4. Design the device page

Use UI Designer on the Device Class to:

1. add the smallest set of widgets that helps a customer operate the product
2. bind live widgets to the class streams
3. include identity and connectivity context
4. preview missing, stale, and disconnected states
5. confirm the page does not expose engineering-only controls

The class device page is not the dashboard/TV designer. See Design a device class page.

5. Configure the portal boundary

Work with your organisation administrator to enable and brand the portal. Then:

1. create the customer or site records
2. invite customer users with the smallest suitable site role
3. claim and assign the staging device to its network
4. open the device from the customer portal
5. verify the class page and live values, where configured

Keep Remote Shell, fleet-wide logs, and firmware rollout controls in the OEM engineering workspace. See Customer portal for the operator pages and role boundary.

Production checklist

• [ ] The agent reconnects after a device reboot.
• [ ] The device resolves to the intended class.
• [ ] The portal user sees only the assigned customer or site.
• [ ] A dormant device becomes available after network assignment.
• [ ] Every live widget uses a declared class stream.
• [ ] The publisher contains no Dataplicity API key.
• [ ] Samples recover after an offline interval.
• [ ] Empty, stale, and disconnected page states are understandable.
• [ ] The OCI image matches the hardware architecture, if class software is used.
• [ ] A bounded staging rollout succeeds before production assignment.

Related

• Build a class container
• Device class streams
• Design a device class page
• Example simulators
• Customer portal
• Keep your runtime