Keep the essential job local
Put only the work that must continue through an outage on the device. Your existing service or container can remain responsible for hardware and safety.
Keep essential work local when the connection drops.
Dataplicity supports explicit local Process execution, selected offline datasets and bounded data delivery around connected Linux products. Decide which work must continue on the device and which work can wait for the cloud. Your existing daemon or container still owns the hardware interface and physical safety.
- Cloud, Edge and Mixed execution are deliberate choices, not transparent failover.
- Live remote access needs connectivity; essential local behaviour must not.
- Buffered, delivered and physically completed are different states.
Decide what must still work without the cloud.
Offline operation is a product decision first. Dataplicity gives you explicit places to run local work and reconcile it later; it does not pretend every cloud function transparently survives an outage.
Let cloud work wait
Central records, integrations and cross-device coordination can remain cloud-side. Make waiting, expiry and unavailable states visible rather than disguising them as success.
Mix the two deliberately
Use a local segment where the customer job requires it and reconnect it to the cloud workflow when connectivity returns.
Read the technical guideMake the outage understandable to operators and customers.
Local work, buffered data, pending requests and live access have different behaviours.
Local work can continue
Previously deployed local logic and selected data can keep an approved product function running within the authority and limits you define.
Data can wait for delivery
Eligible device data can be retained within documented bounds and sent after reconnect. Critical product records still need the durability policy appropriate to the application.
Read the technical guideRequests are not physical outcomes
Show a setting or command as pending until the device reports what actually happened. Expired, rejected and uncertain work should remain distinguishable.
Read the technical guideLive access waits
Remote Shell and other live device interactions need connectivity. Keep last-seen and data age visible while the device is away.
Follow one customer job through a lost connection.
Illustrative evaluation scenario, not a customer deployment.
Before the outage
Deploy the schedule or local behaviour while connected and confirm what the device has actually applied.
During the outage
The approved local job continues. Cloud-only changes and live support wait, while eligible observations are retained within their configured bounds.
Reconnected
After reconnect, resume delivery, reconcile the reported outcome and surface anything still uncertain instead of assuming queued work completed.
Read the technical guideKeep the device software you already trust.
Dataplicity can work around ordinary device code as well as managed components.
Existing daemon or container
Your service can continue to own protocols, drivers and physical behaviour while exchanging product data and permitted actions with Dataplicity.
Read the technical guideManaged Edge Process when useful
Use local Process execution for bounded product workflow that benefits from the shared application model. It is an option, not a requirement for offline-aware fleet operations.
Read the technical guideKeep safety local
Hard real-time protection, emergency behaviour and irreversible physical safety remain responsibilities of qualified local product software.
Test the customer-visible behaviour, not just the network failure.
A useful offline test proves what continues, what waits and what the user sees.
Disconnect deliberately
Confirm the essential local job continues and cloud-dependent work becomes visibly pending or unavailable.
Restart and reconnect
Exercise the recovery path and confirm retained information is reconciled without silently duplicating physical work.
Inspect uncertain states
Verify stale readings, expired work and unresolved outcomes remain explicit.
Read the technical guideMap one customer job across connected and disconnected operation.
Choose the local work, cloud dependencies and recovery policy first. Then verify the documented runtime and delivery contracts on representative hardware.