Fleet — the ten domains

What Fleet does, domain by domain.

In detail

1. Building — the device image

An image is the content of the memory card, ready to write: operating system, network, scripts, identity, and if you want the applications themselves. You describe it in a form, the platform builds it.

• One form, one image: language, time zone, WiFi networks, address, DNS, firewall, scripts.
• Nothing to install: a dedicated machine produces the image, signed and compressed.
• Official base: the operating system comes from official sources, its fingerprint is checked.
• Inherited values: zone, account, fleet, device — the most specific wins, an empty field inherits.
• Two WiFi networks at least: the customer's and a fallback, merged from the fleet and the zone.
• Batch or device image: written to several cards, or tied to one specific machine.
• Device classes: a named profile that filters modules for a mixed fleet.
• Boots with no network: the applications can be embedded in the image.
• Frozen recipe: once created, the image no longer moves. New configuration, new image.
• Isolation: one key per image — a compromised card opens only that one.
• Writing tool for Windows, macOS and Linux: it excludes the system disk, writes, verifies, ejects.

2. Enrolling — identity, hardware, replacement

A device's identity is born in its image and never changes. The hardware that carries it can change: the history follows.

• Key baked into the image: it never leaves the device and signs every exchange.
• Automatic enrolment: at the first heartbeat, the device is created in its fleet and named.
• Tracked across rewrites: four cases arbitrated and recorded, from first write to hardware transfer.
• Transfer between accounts refused by default.
• Append-only history of writes and bindings, visible in the record.
• Immediate cut-off: disabled hardware is refused at authentication. Reversible in one click.
• Soft archiving: an archived device keeps its history readable.
• External reference: it links the device to its point of sale as soon as it arrives.

3. Deploying — version, preview, strategies

The reference configuration lives in the account's Git repository. Deploying means pointing to a version; the device fetches it and updates itself.

• Your repository: GitHub, GitLab, Azure DevOps or the platform's own.
• Preview before approval: a side-by-side comparison shows what changes.
• Registry check: each module is verified for each architecture before rollout.
• A missing image blocks the deployment, unless explicitly confirmed.
• The version deployed is the one read on screen — never a stale one due to propagation delay.
• Three strategies: strict with rollback, lenient for the laboratory, or staged.
• Trial on a single device before rolling out, with a one-click return to the fleet.
• Full history: each deployment keeps its snapshot, two versions stay comparable.
• A new attempt at each heartbeat, without giving up.

4. Configuring — cascade, network, firewall, secrets

One single model: the shape comes from the repository, live settings from the database, secrets from the vault.

• Cascading settings: set at the most practical level, inherited below.
• The server resolves: the device receives a configuration already computed.
• Network field by field: DNS applies remotely, the address at the next image.
• Firewall closed by default: with no rule, everything inbound is refused.
• Its observed state is reported in the console: applied, failed or absent.
• No secret in the configuration: access is issued with a limited lifetime at each heartbeat.
• Re-read live, with no redeployment, and the device is warned before expiry.
• Encrypted disk and identity key inside the chip: a card stays unreadable elsewhere.

5. Monitoring — the live state of the fleet

Seeing without connecting: the device reports everything at each heartbeat, the console shows it.

• A heartbeat every minute by default, adjustable per fleet and per device.
• What it reports: version, temperature, memory, load, addresses, the state of each module.
• The containers actually running — which reveals a device left on a stale version.
• Offline detected within three minutes, centrally.
• The reason for a failure without opening a session: last error, failing modules, observed firewall.
• Timeline: you move to a date and read the fleet's state at that moment.
• Alerts: going offline becomes an event routed to email, SMS or notification.

6. Intervening — remotely and on site

No permanent session, no master key. Every intervention has an author, a duration and a record.

• Recovery actions: restart the device, the agent, or a module, from the console.
• Controllable even with no open channel: orders then travel in the heartbeat's reply.
• Embedded console on every device, served without opening a single port.
• It works offline, on a closed network.
• Time-limited technician access: two to forty-eight hours, validated with no network by the device.
• A bare Windows machine is enough: the technician tool carries everything needed.
• Configuration over a USB cable: a local page sets WiFi, address and DNS, with no rewriting.
• Each change is tested and rolled back if it breaks the link.
• Scripts by phase: start, stop, scheduled, after deployment, health.
• Full audit: each action runs exactly once and stays on record.

7. Updating — agent, system, resilience

Updating a fleet in the field is mostly about knowing how to go back.

• Agent updated remotely, per fleet or per device.
• Automatic rollback if the first heartbeat does not confirm.
• System security patches applied remotely, within a maintenance window.
• One device at a time for the core of the system.
• Works offline: what is collected leaves when the network returns.
• Progressive network repair, then a restart — never during a transaction.
• Minimal writes to the card: in steady state, the device writes nothing.

8. Developing — the application framework

Your teams write the business logic, not the plumbing.

• The contract is imposed: the platform orchestrates any new module without adaptation.
• Explicit failure: a missing configuration stops, it is never guessed.
• Ten base modules: local bus, display, synchronisation, logs, simulator, and five starting points.
• Three execution modes for the same code: development, container, or debugging in your own environment.
• A virtual device in the cloud joins the fleet like a real one — develop without hardware.
• Native debugging, including on Windows without a Linux subsystem.
• Six languages, with a shared library and enforced parity between them.
• One autonomous repository per partner, with no access to the core.
• Protected code: distributed binaries are obfuscated, sources are never inside an image.

9. Governing — accounts, teams, credentials, zones

Who sees what, who can do what, and where the data lives.

• The account is the scope: outside it, the answer is "not found", not "forbidden".
• Teams and roles: read for members, change for the administrator, down to the field.
• Any unknown policy fails closed.
• Credentials never displayed: they resolve to the caller's identity, and every action traces to a person.
• Enterprise sign-in: the user is provisioned on first access, as a plain member.
• Shared or dedicated zones, chosen per fleet — an account can mix both.
• Long tasks followed live: image builds, module builds, provisioning.
• Append-only record: every trace resolves to a named identity.

10. Three device types