Operate without changing releases
Use remote access, Pulse, diagnostics, logs and fleet visibility alongside your existing application and update mechanism.
Explore this pathRelease software across your Linux fleet. Know what actually happened.
Fleet operations does not require Dataplicity to own your software lifecycle. Keep the application and updater you already use. If you want more later, add managed application releases or fleet-level RAUC rollout control as separate, optional capabilities.
- Use remote access, Pulse, diagnostics and fleet visibility without changing your updater.
- Add managed application releases or RAUC OS updates only when they solve a problem for you.
- When Dataplicity manages a rollout, success, rollback, failure and unresolved devices remain distinct.
Start with the fleet you already have.
Software delivery is optional. Dataplicity can add an operating layer around an existing Linux product without forcing a new application packaging or OS-update strategy.
Add application releases if useful
When you want Dataplicity to manage application delivery too, use versioned Software Builds and cohorts. You do not have to containerise an existing product merely to use fleet operations.
Read the technical guideAdd OS rollout control if useful
If your product already uses a suitably prepared RAUC A/B image, Dataplicity can add fleet targeting, rollout control and outcome visibility. RAUC remains responsible for the device-side update and recovery chain.
Read the technical guideRelease deliberately. See what actually happened.
When you choose Dataplicity-managed delivery, the marketing promise is an operator outcome rather than a new device architecture.
Choose what changes
Keep application and OS releases distinct. Select the version you intend to deploy and the bounded cohort that should receive it.
Watch the rollout
See devices move through delivery and validation rather than treating a requested version as proof that it is running. Offline and unresolved devices remain visible.
Decide whether to continue
Separate successful, failed and rolled-back outcomes, check product health, and expand only when the observed result supports the release decision.
Read the technical guideManage application releases without turning fleet operations into a migration project.
Software Builds are there for teams that want Dataplicity to manage this part of the lifecycle.
Version the application
Use immutable versions and Software Builds to describe the application composition you want to run. Keep product-specific code and hardware integration in your application.
Stage by cohort
Start with test hardware or a limited production group, observe the result and promote deliberately rather than changing the entire fleet at once.
Read the technical guideKeep RAUC on the device. Add fleet-level control around it.
Dataplicity works with a correctly prepared RAUC A/B image and adds fleet targeting, rollout control and outcome visibility. Your device remains responsible for its qualified boot and update chain.
Bring an existing RAUC update path
You keep the signed image, inactive slot recovery design and recovery chain. Dataplicity adds the fleet view around it.
Read the technical guideControl rollout from the fleet
Choose the target, follow progress and distinguish validation, rollback, failure, offline and unknown outcomes. Resume or expand as an explicit operator decision.
Read the technical guideKeep integration detail in the technical guide
Bootloader integration, slots, signing, certificates, image preparation and device qualification are important engineering requirements. They belong in the RAUC integration guide rather than being prerequisites for understanding the product page.
Read the technical guideA rollout is useful only if failure is understandable.
The operating surface should help the team decide what to do next, not collapse every non-success into silence.
Offline is not failed
A device that has not reported an outcome remains unresolved. Keep it separate from a device that attempted the release and failed.
Rollback is an outcome
Show that the device recovered to the previous known-good state rather than reporting the attempted release as successful.
Product health matters
A booted Linux device is not automatically a healthy product. Verify the signals that matter to the equipment before expanding a release.
Read the technical guideProve the operating workflow on a small part of your fleet.
Use representative equipment and the release mechanism you actually intend to operate.
Start with one useful change
Connect representative hardware, establish its current state and release to a bounded cohort.
Include an imperfect outcome
Exercise an offline or deliberately failed test device so the team can see how unresolved and recovery states appear.
Expand only after evidence
Confirm the running version and product health, then decide whether the release should continue.
Read the technical guideEvaluate the release path that your product actually needs.
Start with container Builds or a qualified RAUC device. Use the requirements and operating guides to define a bounded evaluation before changing the installed base.