What Dataplicity is for

Dataplicity gives connected-product companies two separated SaaS workspaces around the Linux hardware and product application they already own:

• an OEM workspace for product definition, fleet operations, software delivery, evidence, and remote support
• a branded Customer Portal where each customer sees their own locations, assigned products, product data, and permitted controls

The field agent connects device identity and an outbound operating path to both workspaces. Dataplicity does not replace the product runtime or every specialist system around it.

Use this page as the quick map. For the full evaluation path, start with After devices ship. For a concrete OEM picture, see SiloSentry - a fictional grain-bin sensor company walkthrough of devices, ops walls, incidents, and fleet fixes on Dataplicity (illustrative, not a real customer product).

Before shipment

Use Dataplicity during development and production preparation to:

• test the agent and outbound network path on representative hardware
• validate Remote Shell, Wormhole, and file retrieval under the intended Linux permissions
• include the agent in a repeatable image or provisioning process
• establish device class, organisation, and support context before scale
• define stable streams and safe controls, then prove the customer page with a customer-scoped test user

The customer application

Use Dataplicity when the Linux device is a product you sell or provide:

• define the hardware model with a Device Class
• publish selected product values through the agent-local broker
• design the customer-safe product page
• create separated customer organisations and a branded hosted portal
• place each claimed device on the Network that currently represents its site, vehicle, cabinet, farm, or other customer-facing location

Start with the canonical connected-product activation guide. The suite is beta-gated and Standard+; review plans and availability before integration.

After shipment

Use Dataplicity when a deployed unit becomes an operational responsibility:

• see device and fleet connectivity state
• organise product, rollout, and network context, and customer or site records where those modules are enabled
• gather device-scoped logs and monitor evidence
• move alerts into owned incident response where enabled
• use remote access or bounded fleet actions when intervention is justified
• review supported platform history and communicate selected customer-safe status

Common problems Dataplicity solves

Problem	How Dataplicity helps
Device is behind NAT or on a customer network	Agent-initiated route without per-device inbound port forwarding; restricted networks may require approved outbound destinations
Support needs a consistent field access path	Browser-based Remote Shell and Wormhole through the Dataplicity application
Device is offline and nobody knows why	Fleet visibility, online/offline status, and notifications
Logs are scattered or not tied to the device/customer	Centralised logs with device and fleet context
Engineering keeps getting pulled into routine support	Individual team access, shared evidence, and an explicit escalation path
Custom admin panels are growing out of control	Operational workflows around the device instead of bespoke internal tools
Customer needs to use the connected product	A branded, customer-separated product application where the Customer Portal suite is enabled
Customer only needs selected service status	Customer-facing status surfaces where enabled, separated from internal diagnostics
Team needs access and action history	Supported product history for operational and security review, subject to feature coverage and retention

Fit Dataplicity into your stack

Keep the application runtime, organisation-wide observability, full ITSM lifecycle, CRM, billing, storefront, ERP, and corporate networking tools where they are authoritative. Use Dataplicity for the hosted OEM and customer workspaces centred on the deployed Linux product.

See Dataplicity beside your existing stack for the comparisons and integration boundaries.

Next steps

• After devices ship - how remote access grew into the operations layer
• One device record from factory to field ticket - identity across the lifecycle
• Getting started - install your first device
• Build your first connected product - activate one product through the customer application
• How it works - understand the architecture
• Production rollout - prepare devices for the field
• Business workflows - short stories for internal ops and connected-product companies
• Illustrative customers - demonstration fleets that make those stories concrete
• SiloSentry - fictional OEM walkthrough of post-shipment ops (illustrative)