Remote access & fleet operations

Find a fault. Reach the device. Check the fix.

Reach devices behind customer networks, spot unexpected changes with Pulse, and investigate problems through logs and diagnostics. Keep control from the first prototype to the fleet already in the field.

A complete workspace for your team. No customer portal required.

Get the install command by email. Remote access is free on one device. Pricing

Reach the device

Get to the box. Keep the fleet in view.

Open a Linux terminal from the device record. Reach its web interface with Wormhole, or forward a service port for your own tools. The agent connects outbound, so devices behind NAT and cellular networks can stay within reach.

Dataplicity terminal cockpit with fleet device list and a live device shell session

Your Linux. Your application.

Install the agent alongside the software you already run. Keep your hardware and supported Linux distribution.

An outbound connection

Live access requires an online agent that can reach Dataplicity. No inbound port or customer VPN is needed; outbound network policies still apply.

The right device, with context

Move from fleet inventory to the selected device, its diagnostics and its terminal in the same workspace.

Explore remote access →

Spot unexpected changes

Which device stopped looking like its peers?

Pulse compares a device with others in its Device Class, a group for a product type. Review differences in disk use, packages and agent versions to decide what needs investigation.

A finding gives your team a place to investigate. Compare the affected device with its peers, then use diagnostics and logs to understand the change.

See how to evaluate fleet visibility →

One device can prove remote access. To evaluate Pulse, connect comparable devices in a Device Class on a paid plan and allow evidence to accumulate. Start with a representative cohort you can already reach.

PulseProbe gateways · 12 peers

Class normal

South-14 stopped looking like its peers

Root disk 91% · packages diverged · no gold baseline required

Illustrative Pulse finding from the SiloSentry worked reference. A difference is a reason to investigate, not proof of a fault.

Investigate and act

Find the evidence before you make the fix.

Search device logs around the affected time, inspect diagnostics and use remote access to check the service. Work from the evidence available for that device instead of asking someone on site to copy and send files.

Dataplicity logging console with device and platform events from the Northstar demo fleet

Dataplicity logging console, shown with a demo fleet. Retention and analytics depend on your plan; only collected logs are available for review.

Narrow the investigation

Filter the collected logs by device and time. Look for repeated errors or changes around the reported problem.

Take the next action

Use a live terminal for an online device, or guarded fleet jobs on Business+ when the same action needs to reach a selected cohort.

Check the result

Review fresh logs and device health after the action. Keep incident ownership and follow-up together with Business+ incident handling.

Explore logging →

Carry the fix through the fleet.

Once you understand the fault, choose the release or operating change and verify its result. Keep the devices that are still offline or unresolved visible instead of declaring the whole fleet fixed.

Release the change deliberately

Select application versions in a Software Build and target a bounded cohort. For a qualified RAUC image, use the separate OS rollout path and inspect installation, validation and rollback outcomes.

Software lifecycle and RAUC

Account for a disconnected device

Essential local work, buffered data and pending cloud requests have different behaviours. Check the configured local execution, expiry and reconnect contract before treating a request as completed.

Offline and edge operation

Keep a working part of your stack

You do not need to replace an existing updater or customer application to evaluate better fleet support. Compare the ownership of each task and avoid competing systems issuing the same change.

Compare adoption paths

Useful wherever you are in the lifecycle.

You do not have to wait for a new hardware design or a customer application project to improve how you operate devices.

On your desk

Connect a development device and prove remote access before choosing how to roll out.

Entering production

Include agent installation in provisioning and organise devices into classes as the fleet grows.

Already in the field

Install through your existing remote management, software update or on-site process. Start with a reachable cohort; Dataplicity access begins once the agent is installed and connected.

Choose your lifecycle starting point →

Bring the team. Keep access under control.

Use role-based access and review security activity across sign-ins, access changes and device sessions. Remote session opens are recorded as access events; terminal contents and keystrokes are not recorded.

Standard

Remote access, diagnostics, logging and Pulse for everyday device operations. A customer portal is optional.

Business+

Add advanced log investigations, fleet jobs, incidents and on-call escalation. These are useful for operations teams whether or not customers need an application.

Compare plans and calculate your fleet cost →

Start with a device you can reach today.

Get the install command, connect your Linux device and open its remote terminal. Evaluate on one device, then choose the paid plan for the operating capabilities you need.

If customers need their own application, the same connected devices can support it. Explore customer portals & applications →