Operate a Linux edge appliance after shipment

This pattern is for a product where the software is the main IP but it runs on Linux hardware at the customer's site: an edge AI appliance, protocol converter, security appliance, local collector, video processor, industrial integration gateway, or similar product.

The useful Dataplicity architecture is usually not “move the application into Dataplicity”. It is:

Keep the appliance software and runtime you already own. Add a support, fleet, product, and customer layer around it.

System boundary

A representative product looks like this:

customer LAN / industrial network
        |
        v
Linux edge appliance
  - your application
  - local protocol/device integrations
  - local data/cache
  - local safety/failure behaviour where relevant
  - Dataplicity agent
        |
        v
Dataplicity
  - fleet identity and inventory
  - remote engineering support
  - logs / diagnostics / jobs / Pulse
  - Device Class product contract
  - Customer Portal
  - bounded Product Application workflow where useful
        |
        +----> your backend / cloud / ERP / data platform

Dataplicity does not need to become the appliance runtime.

Keep the existing application model

If the appliance already runs as:

• systemd services;
• Docker or Podman containers;
• Kubernetes/k3s;
• Greengrass components;
• a proprietary supervisor;
• a vendor package or image;

keep it unless there is a separate reason to change it.

Dataplicity can sit beside the existing runtime for support and operations. Class-managed OCI software is optional, not a prerequisite for using the product/customer layer.

Define the product with a Device Class

Create a Device Class per appliance model/generation where the hardware/software contract materially differs.

Typical product streams might include:

• application version;
• appliance health;
• upstream connection state;
• message/event throughput;
• local queue depth;
• CPU/storage pressure;
• connected downstream endpoints;
• last successful cloud sync.

Useful settings might include:

• endpoint URLs;
• log verbosity;
• bounded feature flags;
• polling interval;
• customer-safe operating modes.

Useful actions might include:

• restart application;
• run connectivity/DNS/NTP tests;
• capture diagnostics;
• refresh configuration;
• rotate/reload an application component where locally safe.

Do not expose arbitrary shell commands as customer actions.

Model dependencies explicitly

An edge appliance often depends on more than “the Internet”. Define important dependencies such as:

• DNS;
• NTP/time source;
• customer gateway/router;
• upstream API or broker;
• local PLC/device subnet;
• database or local storage;
• certificate/token validity;
• cloud region/service endpoint.

A customer support page is much more useful when it can say which dependency is failing rather than only “device offline”.

Remote support workflow

A strong OEM support path is:

1. customer reports the appliance is not processing data;
2. support opens the device record;
3. connection/dependency state shows whether the appliance itself is reachable;
4. logs and product state narrow the failure;
5. support runs bounded diagnostics;
6. engineering opens Remote Shell only when deeper Linux diagnosis is required;
7. a fleet-wide check determines whether this is one appliance or a product-generation issue;
8. remediation is applied to a small cohort first;
9. resulting state is independently verified.

That is a materially different support model from “ask the customer to open SSH or screen-share with us”.

Customer Portal boundary

The downstream customer usually needs to see product state, not the appliance's Linux internals.

A customer page might show:

• online/offline/stale state;
• application health;
• connected endpoint count;
• last successful data sync;
• recent alarms;
• customer-safe configuration;
• documentation link;
• system status link;
• site/location;
• approved diagnostics/actions.

Keep shell, raw logs, fleet jobs, release management, and product-wide drift evidence in the OEM engineering workspace.

Software and update strategy

Do not choose an update system merely because Dataplicity exists.

If you already use:

• RAUC;
• Mender;
• SWUpdate;
• OSTree;
• package repositories;
• container registries;
• your own updater;

keep it where it solves the problem well.

Dataplicity can orchestrate, diagnose, and verify around that system. If your application is naturally a container and class-managed OCI releases simplify operations, use them. The boundary should be explicit.

Offline behaviour

An appliance should continue its local job for the outage window your product promises.

Define:

• what input can be buffered;
• which product functions continue without cloud access;
• what customer configuration is cached;
• how long local queues can grow;
• what happens on disk pressure;
• how events are reconciled after reconnect;
• whether any customer action is prohibited while disconnected.

For important records, use an application-owned durable journal rather than assuming generic telemetry is a financial or legal ledger.

Product Applications: use only where they add real value

Product Applications are useful when the appliance has bounded customer workflows around it, for example:

• site integration approvals;
• endpoint configuration records;
• customer-defined schedules;
• maintenance acknowledgements;
• access/credential datasets distributed to appliances;
• workflow state spanning several appliances.

Keep broad analytics, enterprise integration, financial records, and arbitrary application compute in the systems designed to own them.

Fleet map and site context

For appliances installed at customer premises, location/site can be operationally important. Use customer/site allocation and device location where available so support can answer:

• which customer owns this unit;
• which site is affected;
• whether nearby/same-site units have the same problem;
• what product generation is deployed there.

Production proof checklist

Before shipping the architecture broadly, prove:

• [ ] appliance boots and performs its local job without Dataplicity;
• [ ] Dataplicity reconnects after reboot/network interruption;
• [ ] normal customer firewalls require outbound connectivity only as documented;
• [ ] product streams/settings/actions have stable semantics;
• [ ] important dependencies are visible;
• [ ] customer role cannot reach engineering-only surfaces;
• [ ] application/update rollback path is understood;
• [ ] fleet change can be verified independently;
• [ ] device can be offboarded without destroying the local product.

Related

• Add Dataplicity to an existing Linux product
• Industrial gateway
• What runs on my device?
• Run and verify a fleet change
• Customer Portal