Strux Fleet, coming soon
Every device on the release you choose.
Strux Fleet enrolls your devices, holds the releases you publish, and keeps each Fleet, group, and device on the version you set. Devices pull their desired release on check-in; nothing pushes into your network.
Coming soon Build with Strux OS today.
From a built image to a converged Fleet.
Four steps, and three of them happen where you already work: the project, the terminal, and the Console.
01
Enroll from the image
Create an enrollment token for a Fleet in the Console and reference it from the project. The token is built into the image; on first boot the device redeems it for its own identity and credentials, then checks in on a schedule the Fleet sets.
strux.yaml
fleet
fleet: enabled: true api: https://api.strux.sh enrollment_token_file: ./strux-fleet-enrollment.token
02
Publish a release
Sign in once from the terminal, build, and publish. The Registry registers your signing key on first publish, creates a release with one bundle per board, verifies each bundle's manifest signature, and makes the release available on the channel you name.
# approve this computer once, in the Console
$ strux login# build, then publish one bundle per board
$ strux build$ strux registry publish --channel stable✓ Published kiosk-os@1.4.0 to stable
03
Set the desired release
Pin a Fleet, a group, or a single device to a version, or let it follow a channel. Groups override their Fleet and devices override their group, so a showroom can hold back while the rest moves on.
console.strux.sh/fleets/downtown-stores
Fleet
Downtown stores
Package @northline/kiosk-os Desired release Follow channel stable Resolves to 1.4.0 for hd215-rk3576 and rt101-rk3568 Overrides Group Showroom pinned to 1.3.2 04
Watch the rollout
Every desired-state change opens a rollout with a row per device. Statuses come from the device's own check-ins, from queued to confirmed, and a device that boots back into its old slot is recorded as rolled back and left alone until you retry.
console.strux.sh/rollouts/8f2c1a
CompletedRollout
kiosk-os 1.4.0 to Downtown stores
Desired release set on the Fleet. Devices converge on their next check-in.
Devices
8Confirmed
8Updating
0Rolled back
0Device Status Progress lobby-kiosk-01 Confirmed ████████████████████lobby-kiosk-02 Confirmed ████████████████████checkout-03 Confirmed ████████████████████checkout-04 Confirmed ████████████████████warehouse-wall-01 Confirmed ████████████████████warehouse-wall-02 Confirmed ████████████████████showroom-01 Confirmed ████████████████████showroom-02 Confirmed ████████████████████
Organize mixed hardware the way you run it.
A Fleet is the operational container. Inside it, nested Device Groups carry properties, labels, and their own desired release, and every device keeps the inventory ID you give it.
Fleets
One per operation: a region, a customer, a product line. A Fleet sets the check-in interval and the default desired release for everything under it.
Device Groups
Nested as deep as you need. Move a group and every device under it follows, along with the access and the desired release that applied to it.
Properties and labels
Key-value properties and free-form labels on groups and devices, for the classifications your operation uses rather than the ones a vendor imagined.
Identity that survives reflashing
A device's identity comes from its hardware. Flash the same board again and it rebinds to its existing record, history included.
Strux Registry
Releases live in a Registry your organization owns.
Packages are scoped to your organization, releases carry one bundle per board, channels are yours to name, and every upload is checked against the signing keys registered on the package.
~/projects/kiosk-os
publish
Scoped names
A package is @organization/name. Publishing never transfers ownership, and package access never implies Fleet access.
One bundle per board
A release holds a full-image bundle for each board it was built for. A device is only offered a release that has a bundle for its board.
Channels
stable always exists. Add beta, dev, or whatever your process calls them, and let Fleets follow a channel instead of a pinned version.
Signing keys per package
The CLI registers the project's public key on first publish. A release bundle is accepted only when its manifest signature verifies against an unrevoked key.
Publish from CI
Create an API token in the Console and pass it to the CLI. Tokens carry a subset of your own permissions and can be revoked at any time.
Rollouts report what the device says, not what the server hopes.
Every status in a rollout comes from a check-in the device made. Nothing is marked done because a command was sent; a device is confirmed only when it reports the new release from its new active slot.
Only one rollout runs per device at a time. A newer desired release cancels the running one and starts another, and the audit timeline keeps both.
- Queued
The device has not checked in since the desired release changed.
- Downloading
The device is streaming the bundle into its idle slot.
- Installing
The payload is verified on disk and the bootloader is being armed.
- Rebooting
The device acknowledged the new slot and is restarting into it.
- Confirmed
The next check-in reported the release from the new active slot.
- Rolled back
The device came back on its previous slot. It is not offered the release again until an operator retries.
- Failed
The updater reported an error before the bootloader was armed.
Access is a role, applied somewhere.
Roles are named sets of actions. Access gives a person or a team a role for the whole organization, one Fleet, one group, or one device. Built-in roles cover the common jobs; custom roles pick from the same action catalog.
Fleet Operator
Every operational device action within its scope: desired releases, rollouts, device records, retirement.
Fleet Viewer
Read access to Fleets, devices, rollouts, and the audit timeline.
Registry Publisher
Create packages, register signing keys, and publish releases.
The audit timeline
Every enrollment, release, desired-state change, and update outcome is recorded with who or what caused it: a person in the Console, a device on check-in, an API token in CI.
device.enrolled · device.retired · release.published · release.yanked · desired-state.changed · update.offered · update.confirmed · update.rolled-back · enrollment-token.revoked
What Strux never holds.
Fleet is built so that a compromise of the platform cannot put software on your devices. The key that signs your images stays with you, and every device checks for itself.
- Your signing key never leaves you. The Registry verifies each uploaded bundle against the public keys you register on the package, and the platform holds no private key.
- Every device verifies every bundle itself: the manifest signature first, then the payload hash while writing and again by reading the slot back.
- Download links expire. A device receives a short-lived address for the bundle on each check-in, not a durable credential.
- Device credentials are issued per device, rotate on their own, and are revoked the moment a device is retired.
- Enrollment tokens belong to a Fleet, can be limited by use count and expiry, and can be revoked at any time.
- One rollout at a time per device. A newer desired release cancels the running rollout and starts a new one, and the audit timeline keeps both.
What is next for Fleet.
These are not in the product today. They are listed here so the shape of the service is clear, and the changelog will say when each one lands.
- Roadmap
Staged rollouts that expand from a first group to the rest of a Fleet with an inspection gate between stages.
- Roadmap
Remote actions beyond reboot and power off, delivered through the same check-in the device already makes.
- Roadmap
Remote screen and remote shell sessions from the Console, on the paid plans.
Strux Fleet is coming soon. Start with Strux OS today.
When Fleet opens, the free tier covers enrolling devices, setting desired releases, and watching rollouts, with bundles served from a server you run. Hosted storage and remote sessions come with the paid plans.