Remote Shell, Wormhole, files, and the outbound connection.
Appearance
Modern agent architecture #
The modern agent is designed for a Linux product that must remain reachable and supportable after it leaves your factory. It separates the smallest recovery path from optional product-management work so a problem in a container or product integration does not have to take remote access down with it.
Read this architecture by responsibility #
| If you are responsible for… | The part that matters first |
|---|---|
| The Linux image and manufacturing process | Persistent identity, service integration, upgrade ownership, and reboot recovery |
| Fleet operations | Presence, desired-state reconciliation, health, staged change, and evidence |
| Customer support | The rescue path, device status, logs, and a repeatable triage order |
| The product application | The loopback broker, settings snapshot, actions, streams, and optional Class Software |
| Security and networks | Outbound connections, separate Linux users, device credentials, and the fixed privileged helper |
The architecture in plain English #
The rescue plane keeps the device identity and remote operating connection alive. It is intentionally the smaller path. A device that only needs Remote Shell, Wormhole and file access can run rescue-only.
The supervisor is the on-device manager for modern product functions. It reads the cloud's desired state, writes only when state changes, maintains the local product broker, reports health, and optionally reconciles Class Software through a container runtime you provide.
The product application remains yours. It talks to a loopback API and does not need Dataplicity cloud credentials.
A small privileged helper exists only for explicitly supported image-management operations. The supervisor itself runs unprivileged.
CloudDataplicity control plane
On the deviceRescue planeIdentity and remote access SupervisorDesired state and broker Your productProduct application or Class Software Privileged helperRAUC and reboot only
Manifest reconcile, loopback broker, health, and optional Class Software.
Uses loopback only. No Dataplicity cloud credentials in your app.
Fixed path, scoped commands. The supervisor stays unprivileged.
What is required and what is optional? #
| Component | Required? | Remove it when… |
|---|---|---|
| Rescue plane | Yes for a managed modern device | You remove Dataplicity from the device |
| Supervisor | Only for modern product-management functions | The device is intentionally remote-access-only |
| Container runtime | No | You do not use Class Software |
RAUC and casync | No | You do not use Dataplicity-managed A/B image delivery |
| Your product application | Yours | Dataplicity does not replace it |
RAUC image management is off by default. A normal modern-agent install does not require RAUC and should not fail because RAUC is absent.
Files and ownership #
Binaries normally live under /opt/dataplicity. Identity, desired state, caches and current product configuration live under /var/lib/dataplicity.
On an ordinary host, /var/lib/dataplicity can be a normal local directory. On an A/B image-managed product, it must be a persistent partition outside both root filesystems. Keeping binaries inside each signed image slot means an OS rollback also rolls the agent back as part of the tested image.
Failure boundaries operators should remember #
- Losing the supervisor should not redefine the device identity or remove the rescue path.
- Losing a container runtime means Class Software is skipped or unhealthy; it must not be reported as successfully applied.
- Losing cloud connectivity delays desired-state and data delivery; your local product must retain the safe offline behaviour you designed.
- Granting either service account extra groups, files, sockets or sudo rules expands what remote operations can reach.
- Dataplicity can orchestrate a RAUC update, but your bootloader and image must provide the actual rollback safety.
Next: integrate the modern agent, operate it, or review its security boundary.