Dataplicity beside your existing stack

Dataplicity is a device operations layer, not a demand to replace the systems that already run your product and business.

Operating connected products series

1. After devices ship
2. One device record from factory to field ticket
3. Dataplicity beside your existing stack
4. From signal to verified recovery
5. Trust on someone else's network

The usual build-versus-buy question is too broad. A connected-product team rarely needs one system to replace application runtime, observability, service management, corporate networking, device access, and customer communication.

The useful question is:

Which system should remain authoritative for each job, and how does an operator move from a field signal to the right device, evidence, action, and verified outcome?

Dataplicity centres that path on the deployed Linux device. Keep specialist systems where their broader scope matters.

The boundary in one table

System	Keep it authoritative for	Dataplicity's role beside it
Application runtime or supervisor	Running the product workload, deployment policy, and application lifecycle	Device identity, fleet context, field evidence, and support access around the software
Observability platform	Organisation-wide metrics, traces, analytics, and long-term application insight	Device, class, customer, site, and access context for field response
ITSM or service desk	Ticket ownership, approvals, customer conversation, and business reporting	Live device context and supported operational actions linked from the ticket
On-call platform	Organisation-wide schedules and escalation policy	Device and monitor context for the Dataplicity incident path where enabled
Corporate VPN	Access to infrastructure on networks the organisation controls	Outbound access to devices deployed on networks it does not control
CRM or ERP	Commercial customer, contract, order, and manufacturing records	Operational customer, site, class, and device relationships used by support
Public status service	The organisation's wider service communication	Selected device or service status where Dataplicity status surfaces are enabled

Composition is the goal. Duplicating every specialist function inside the device platform is not.

Keep your runtime

Dataplicity does not need to replace systemd, containers, AWS IoT Greengrass, balena, or a custom supervisor. Those systems run and update the application you ship.

Add Dataplicity where teams need a consistent operational relationship around that runtime:

• identify and find the deployed machine
• group it by product class and operational cohort
• inspect available logs and monitor context
• use a supported remote path for diagnosis
• carry customer or site context into support
• review supported platform history

That division lets an embedded team preserve its software architecture while support gains a common route into field context. See Keep your runtime; add the operations layer for the short business scenario.

Dataplicity compared with inbound port forwarding

Port forwarding publishes a route from a site's public address to a service on the device. It can be appropriate on a controlled lab or private network, but it creates operational work for customer-deployed products:

Consideration	Inbound port forwarding	Dataplicity
Router control	Requires a router or firewall change	Agent initiates an outbound connection, subject to network-owner approval and permitted egress
Addressing	Depends on a reachable site address and forwarding rule	Device reconnects to Dataplicity over its outbound route
Device movement	Rule must be recreated when the network changes	Supported device identity remains associated with the Dataplicity connection
Access scope	Depends on the exposed service and network controls	Dataplicity account, role, device scope, and device-side permissions all apply
Fit	Controlled networks with an intentional inbound design	Fleets spread across customer, remote, or changing networks

Dataplicity does not remove the need for network authorisation. Restricted sites may need the documented outbound destinations allowlisted; review Firewall requirements with the network owner.

Dataplicity compared with dynamic DNS

Dynamic DNS keeps a hostname pointed at a changing public IP address. It solves name-to-address discovery. It does not by itself:

• create a route through carrier-grade NAT
• configure an inbound firewall rule
• identify which customer, site, or product class owns a device
• provide Dataplicity roles or device-scoped support context
• connect logs, monitors, access, and response history

Dynamic DNS remains useful when a team intentionally exposes and secures a network service at a known site. Dataplicity is intended for a different operating model: the agent initiates the route and the platform associates it with device identity.

Dataplicity compared with a site or corporate VPN

A VPN joins networks or clients into a controlled trust boundary. It is often the right standard for corporate infrastructure and sites owned by one organisation.

Per-customer VPNs become harder when a product fleet spans independently administered networks:

• each customer may use different addressing and security policy
• overlapping private address ranges complicate routing
• customer IT must provision, review, and revoke access
• support still needs a separate inventory-to-customer mapping

Dataplicity provides access to the managed device through its outbound agent connection; it does not join the surrounding customer network to yours. That narrower boundary is useful for product support, but it is not a substitute when operators need general network-level access.

Dataplicity beside observability

An observability platform is the better home for broad application telemetry, cross-service traces, organisation-wide analytics, and retention designed for engineering analysis.

Dataplicity adds the field-operational context that determines the next action:

• Which physical unit and product class produced the evidence?
• Which customer, site, rollout, or network cohort is affected?
• Is the device currently reachable through its supported route?
• Which remote or fleet action is appropriate?
• How will recovery be checked independently?

Use both when the organisation needs deep analytics and a device-centred support path. Link from the external signal to the Dataplicity device or cohort instead of copying all telemetry into both systems.

Dataplicity beside ITSM and on-call

Keep the complete ticket lifecycle in the service desk and organisation-wide escalation policy in the on-call system.

Link those records to Dataplicity for:

• current device and cohort context
• available logs and monitor evidence
• Remote Shell or Wormhole when interactive diagnosis is justified
• guarded fleet jobs for selected device commands
• supported product history relevant to review

Dataplicity alerts and incidents also have separate roles. Connectivity monitors create alerts. Use incidents where enabled when acknowledgement, escalation, responder ownership, or selected status communication is required. The wider business process can remain in ITSM.

Direct SSH still has a place

Direct SSH can be the simplest engineering tool for a device on a lab network. Dataplicity is most useful when the same access method must work consistently across devices in customer facilities, remote sites, or mobile deployments.

The two methods are not mutually exclusive. Decide by environment:

Environment	Practical default
One development device on a controlled LAN	Direct SSH may be simpler
Production devices across customer networks	Dataplicity avoids a per-site inbound route
Corporate servers	Follow the corporate network and privileged-access standard
Product support needing customer and device context	Use the Dataplicity record and supported access path

Choose the system of record deliberately

For each integration, document four decisions:

1. Authority: Which system owns the customer, ticket, device, software release, or monitor definition?
2. Link: Which stable identifier moves an operator between systems?
3. Action: Which system authorises and executes the operational change?
4. Evidence: Where is the outcome recorded, and how long is it retained?

Avoid synchronising fields merely because both systems can store them. Duplicate state becomes stale. Transfer only the identity and context needed to complete the business process.

A practical stack-fit exercise

Take one real incident and draw its path:

signal → owner → device and cohort → evidence → action → verification → communication

Name the current system at every step. Add Dataplicity where device identity or the route from evidence to response is missing. Keep the existing system where it already owns the job well.

If Dataplicity would only duplicate a dashboard without improving that path, do not duplicate it. If a responder repeatedly rebuilds the relationship between ticket, customer, device, logs, and access, that is the operational join to evaluate.

Continue the series

Next, read From signal to verified recovery for the response method.

For implementation:

• How it works explains the outbound connection architecture
• Gateway API documents supported server-side integration
• Security model explains platform and device-side control boundaries
• Getting started lets you test the route on one supported device