How it works
Choose the software your devices should run, send an update to the right devices, and check each result. Your team uses a web console; a small SuiFleet client on each device checks for updates and reports what happened.
Start with the big picture
How SuiFleet works
A two-minute animated introduction to approvals, shared records, software files and device clients. Female narration with optional English captions; use the player’s captions menu to turn them on or off.
Illustrative animation. Installation results and current health are different; your platform controls its installer and any reboot.
Read the complete narration
- One fleet. Many devices.
SuiFleet helps you deliver software to devices and see what happened. Start with one machine, then organize a fleet into groups. Here is the idea behind the controls.
- You approve the changes.
Your wallet is the app you use to approve management changes. It signs your request so the network can check your authority. Each device has its own identity. Your wallet's private key is not sent to the devices.
- Publish once. Choose who can read it.
Publishing puts a version and its verification details in shared Sui records. The software files live in Walrus storage for a chosen period. Confidential releases are encrypted, with Seal controlling who can obtain the keys to open them. Publishing alone installs nothing.
- Devices check for their updates.
You approve a deployment for a device or group. The shared records describe the approved version and targets. Each device client checks those records on its configured schedule when connected. This is not a remote session pushing files into your machines.
- Download. Verify. Install.
A targeted device downloads the files, verifies the approved release and runs its configured installer. Your platform handles system update details, including any reboot or rollback. An offline device can catch up later, while the deployment permits it and the files remain available.
- A request is not a result.
The device authenticates its result so the console can show whether installation succeeded or failed. Health is reported separately. A deployment request does not mean installed, and installed does not mean healthy. Reporting frequency determines how fresh that picture is.
- Approve. Check. Verify. Report.
The console, shared records, file storage and device clients work together without a SuiFleet application server. Network providers, connectivity and operating funds are still needed. Try one device first, then use groups and staged rollouts to expand.
What you need for a first update
- A device and an installer. Install the SuiFleet client on a supported platform. Your platform supplies the commands that install and run your application or system update.
- An account approval app. A wallet such as Slush is the app you use to sign in and approve changes. You do not need to manage the underlying contracts to use the console.
- Device capacity and network funds. Your account needs room for the device, and network activity needs funds. These are separate: adding funds does not increase your device limit. The public preview uses test tokens, not real-money payments.
- A software release to try. Start with a non-sensitive test application and one device before using groups or a wider rollout.
From registration to a running release
- Connect the device. The client creates the device's own identity. Register its public address and give it a recognizable name. For manufacturing batches, reserve names and serial numbers and give each device its own single-use enrollment credential.
- Prepare a version. Choose a component name, version, target platform, software file and installation instructions. Publishing adds the version to your library; it does not install it anywhere.
- Choose who can read it. Use confidential delivery for proprietary software and create an access policy before publishing. Public examples are readable by anyone. A policy controls access to private files; deployment permissions control who may send an update.
- Send the update. Select a device or group and approve the deployment. Start with a pilot group and use a staged rollout when you want to observe results before admitting more devices.
- Check the result. A deployment-created message confirms the request, not installation on every device. Follow each device's result, running version and available diagnostics. Health is the latest reported state, not a live connection test.
Your platform stays in control
SuiFleet can deliver application or system-update files and invoke your configured installer, including tools such as SWUpdate or RAUC. Your platform decides how partitions, reboot, boot confirmation and rollback work. SuiFleet does not infer those choices for you.
A verified report identifies the device that sent it. It does not prove that the hardware is uncompromised or that every part of an operating-system update succeeded. Continuous telemetry can continue through your existing tools.
What runs behind the console?
| Part | Purpose | Where it runs |
|---|---|---|
| Web console | Register devices, prepare releases, control access and review results. | Your browser. The site serves static files. |
| Device client | Verify releases, invoke your installer and send device-authenticated reports. | Each supported device. Installation and service setup depend on the platform. |
| Sui network | Record permissions, deployments and device reports. Network transactions require approval and fees. | Public network providers; SuiFleet does not operate a fleet application server. |
| Walrus storage and Seal | Store release files and device archives; control decryption of confidential content. | Storage and key-service providers. Storage has a retention period and may need renewal. |
These services still need internet access, funding and suitable providers. “No SuiFleet application server” does not mean there are no external services or operating costs.
Technical references: service dependencies, permission model and staged rollout behavior.
Follow the first-device guide Check client installation requirements