Docs

Playbook - Deployment

Deployment guide for the first managed device.

Install the Dataplicity Agent, register the first unit, verify that the device is online in Dataplicity, add class and customer context, then use that management channel for customer application operations.

  • Copy the install command into your image, provisioning system, or first device.
  • Confirm the first device appears with a recent heartbeat.
  • Apply class, customer, and rollout metadata before scaling.
  • Use Dataplicity for customer-code logs and commands after the device is online.
Get install commandPlaybooks

Onboard the first unit

Create the management channel and make the device visible before you turn this into a fleet rollout.

01 - Install

Run the install command locally

Use the generated command on the device, in the factory image, or in the provisioning workflow.

Install
$ curl -fsSL https://install.dataplicity.com/<provisioning_key>.sh | sudo bash
Dataplicity agent installed
next=waiting for first check-in

This is the local install step that creates the management channel.

02 - Optional local check

Confirm the service is running on the device

If the device has not appeared yet, a single local service check is enough before returning to the provisioning workflow.

Local verification
$ sudo systemctl is-active dataplicity
active

This is not the case study; it is just a local sanity check that the install started.

Verify the device in Dataplicity

Once the device checks in, use Dataplicity CLI to confirm identity, heartbeat, and fleet context.

03 - Inventory

Find the new device

The first rollout gate is simple: the device exists in Dataplicity and has a recent heartbeat.

Find the new unit
$ dataplicity devices list --class <class> --customer <customer> --since 30m
DEVICE        STATUS   CLASS     CUSTOMER     LAST CHECK-IN
<device>      online   <class>   <customer>   2m ago

From this point, Dataplicity can manage and observe the device remotely.

04 - Context

Check class, customer, and rollout metadata

Make sure the unit is in the right operational cohort before using the same command in production.

Describe the device
$ dataplicity devices describe <device>
status=online
class=<class>
customer=<customer>
rollout=pilot
last_heartbeat=2m ago

Metadata makes later logs, alerts, firmware analysis, and support evidence useful.

What deployment unlocks

After the first heartbeat, Dataplicity can help operate customer code on the remote device.

05 - App logs

Tail customer application logs

Use Dataplicity to inspect customer code only after the device is online.

Tail app logs
$ dataplicity logs tail <device> --service customer-app --since 15m
10:44 customer-app: config loaded for <class>
10:45 customer-app: ready

This validates customer application observability through the management channel.

06 - Remote command

Check a customer service remotely

Run targeted commands against customer services once the management channel is present.

Inspect customer service
$ dataplicity run <device> -- systemctl status customer-app --no-pager
customer-app.service active (running)
exit=0

This is the operational handoff: deployed devices can now be managed without a truck roll.

Deployment gate

A device is ready for rollout when Dataplicity can identify it, monitor it, and operate customer code.

Gate

Require heartbeat and metadata

The first successful check-in should carry class, customer, and rollout context before the process scales.

Alerting

Add a heartbeat rule for the class

On-call should know when the new cohort stops checking in.

Operations

Move to customer-code playbooks

Use the case-study playbooks for logs, firmware cohorts, network evidence, runbooks, and warranty support once devices are online.

Deploy the first managed device.

Install the agent to get the first unit online. For agent options, device APIs, and day-two operations, open the documentation.

Open documentation