Playbook - FAQ
Short, concrete answers about using Dataplicity as the operational layer for deployed devices — from first install through day-two support.
How Dataplicity sits alongside Greengrass, balena, systemd, containers, or your own supervisor.
No. Keep your existing runtime and application stack. Dataplicity provides the operational layer: inventory, logs, alerts, incidents, remote access, customer context, and audit history tied to each device record.
Any Linux device that can run the agent and reach the internet. Most teams pair Dataplicity with Greengrass, balena, systemd services, Docker, or custom supervisors — the agent adds fleet identity and ops without replacing how you ship software.
The CLI lets on-call move from an alert to the exact device, customer, class, logs, event history, and remote diagnostic command in one flow — without clicking through separate tools.
$ dataplicity devices show <device> --include customer,warranty,alerts,events
customer=<customer>
warranty=active
open_alerts=1
last_event=first_heartbeat 12m agoOperational context, not just connectivity.
Device identity, status, heartbeats, logs, events, and operator actions you configure — all tied to customer, class, warranty, and incident context. You control what is forwarded from customer applications and backend services.
From the first pilot device to repeatable factory or field rollout.
Run the install command on a device, confirm it appears in inventory with a recent heartbeat, then attach class and customer metadata before scaling the same process to production cohorts.
$ dataplicity devices list --class <class> --customer <customer> --since 30m
DEVICE STATUS CLASS CUSTOMER LAST CHECK-IN
<device> online <class> <customer> 2m agoThe deployment gate is a live device record with context, not just a successful curl.
Yes. Bake the install command or provisioning key into image build, Mender, balena fleet deploy, or your own first-boot script. Device classes carry per-SKU defaults so each product line gets the right tags and collectors automatically.
Classes define provisioning defaults, log collectors, and alert templates. Customer and site metadata attach to each device record so support, warranty, and status pages can scope evidence correctly from day one.
Logs, remote access, and fleet-wide patterns after devices are in the field.
The agent opens an outbound connection to Dataplicity. Support opens a secure shell or forwarded port from the browser — no static IP, DynDNS, or firewall exceptions on the device.
Collectors and ingest paths attach logs to class, customer, and device records. Search and tail operations scope by cohort instead of dumping IoT syslog into a server-centric log platform.
$ dataplicity logs query --class <class> --customer <customer> "retry timeout" --last 1h
12 matches
<device> edge-api retry timeout after deploy <version>Investigations start from product context, not raw text search.
Group by network tag, region, or customer before dispatching technicians. Heartbeat alerts plus cohort filters help distinguish provider outages from isolated hardware faults — see the network outages playbook for a worked example.
Remote access and evidence should be governed from the same platform.
Yes. SAML SSO, MFA enforcement, and SCIM provisioning are built into org settings so fleet access follows the same policies as the rest of your tooling.
Yes. CLI and terminal actions are governed by org roles and group scopes, so responders get the access they need without sharing VPN credentials or SSH keys.
Yes. Security activity, command history, incident notes, and event history provide evidence for support, warranty, and compliance review.
$ dataplicity security activity --device <device> --last 24h
10:41 login <operator>
10:44 terminal.exec <device>
10:47 incident.note <incident>The same system that fixes the device also records who acted and why.
Yes. Status pages and read-only dashboards publish uptime and incident updates from live monitors — customers get transparency without credentials to your internal ops tools.
A practical path from evaluation to repeatable operations.
Install one real device, confirm inventory and metadata, then tail customer-app logs and open a remote session. That validates the management channel before you scale provisioning.
Use the deployment guide for first-device rollout, the integration guide to wire app logs into the device model, the incident runbooks for on-call response, and the case-study playbooks for network outages, log analytics, and customer warranty workflows.
Start with an install command, then validate inventory, logs, alerts, and remote access from one device record.