The Fleet application

The Console, screen by screen.

In detail

Every Fleet page carries the account in its address: each screen is a shareable link, and no scope selector hides inside the pages.

What appears on every screen

• Sign-in delegated to the platform's identity provider, with enterprise single sign-on through federation.
• Application selector (Fleet, Octopoda) and account selector: every account the user belongs to. Switching account keeps the current screen.
• Seven languages, shown in their own name.
• Arabic flips the layout right to left, and technical values stay readable.
• Light or dark theme.
• Side bar: dashboard, fleets, devices, images, scripts, hardware, repositories, credentials, tasks. Collapsible on mobile.
• Explicit feedback: a notification on every save, a banner for every state in progress.
• A refusal says what is missing, instead of returning an empty page.

Dashboard

The account at a glance: fleets, devices online and offline, deployments in progress, latest tasks and alerts. Until the account is active, a banner shows the current commissioning step and leads to the guided page.

Fleets

A fleet groups devices that share the same application and the same configuration, deployed from a Git repository. Pointing to a new version updates all of its devices.

Creating a fleet

A name (immutable), a free-form environment, a deployment zone — shared or dedicated — and the administration and user teams. The Git repository is attached afterwards, in the Resources tab.

Detail

The fleet's identity, read-only, then the Deployment card: deployed version, last synchronisation, device and module counts, strategy — with buttons to move the tracked branch forward or deploy another version. The history lists every deployment with its author and commit, and lets you compare two versions.

Deploying a version

The dialog recalls the version in place, then offers an existing branch, a tag or a verified commit — or the creation of a branch. The preview takes five forms: loading, error, first deployment, no change, or a side-by-side configuration comparison. Below it, registry availability per architecture, with a plain summary: every image is there, or some are missing. A missing image blocks the rollout, and an explicit checkbox re-arms the button.

Modules, devices, images

The module catalogue is read from the repository, so it is read-only: each row shows the image state per architecture, with a build button and its progress. The device and image views are the global tables, filtered to the fleet.

Resources

The attached repository and its synchronisation state, the resolved credential, and the image registries with their scope.

Settings

A single form: image defaults (time zone, WiFi country, language, base image — each list offering "inherited from parent"), deployment strategy with its written guidance, target agent version, heartbeat rate, parallelism, the fleet firewall, the device network (DNS applies remotely, the address at the next image) and the system maintenance policy.

Devices

Each device converges automatically to its fleet's deployed version and reports its state continuously. The list shows the name, the type (box, development workstation, Android terminal), the fleet, the status, the last heartbeat, the address and the agent version — with a deployment badge spelling out the current phase, a partial failure, a rollback or a missing image.

Detail

Identity, hardware (last heartbeat, outbound address, agent version, fingerprint, network interfaces), image, and the write history with its explicit case: first write, rewrite kept, rewrite that archives, exclusive image, hardware transfer.

This is also where a technician access is generated: a duration from two to forty-eight hours, a scope (this device or the whole fleet), and three files to take along. The supplied script opens the session and a tunnel to the embedded console — on site, with no network.

Scripts

The effective view of build and runtime scripts, with their phase, their source (account, fleet, device, image) and their actual execution status.

Override

Everything that can belong to a single device, each card carrying its "override" or "inherited from fleet" badge and its return button: tracked version, class, agent version, external reference to the point of sale, heartbeat rate, strategy, firewall, network, and a module configuration override. No secret passes through: storage access and cloud keys are held by the platform.

Monitoring

A bar that stays visible — status, last contact, agent, address, temperature, processor, memory, uptime — and two recovery actions independent of the embedded console: restart the device, restart the agent.

Below it: the state (deployment in progress, last deployment with the reason for a failure, applied firewall, modules in real time with a "stale" badge if the running image differs from the target), the embedded console served through the platform's relay, per-module metrics, the action history with author and source, the state history and a timeline that moves to a date, and the audit of access to the embedded console.

Images

An image is the ready-to-write content of a device's card: operating system, network, scripts and identity included. The list gives the label, the scope, the architecture and the status (ready, building, pending, failed), and offers the writing tool for five platforms.

The creation form brings everything together: type and fleet, class, label, base image, agent version, time zone, WiFi country, language — pre-filled by the cascade — plus offline pre-loading, the scripts (with an exact preview of what will be embedded), the network and the WiFi networks.

An image's record recalls its frozen recipe and shows one state at a time: not built, building with live progress, built (size, date, download) or failed. The build log gives each script's full output. An image that has been downloaded can no longer be deleted.

Scripts

Scripts customise devices, at image build time or during their life. They are versioned and immutable: you do not delete a version, you publish a patch or disable the script. Each script carries its phase — build, start, stop, scheduled, manual, after deployment, health — its weight and its timeout.

Hardware

The physical inventory as the platform sees it: each card, its write history and its state. Disabling a piece of hardware immediately rejects its heartbeats.

Repositories and credentials

• Repositories: the source of truth for configurations and code, with their provider and their resolved credential.
• Credentials: the secrets held by you or your teams, with their scope.
• The value is set, never shown — you only see what uses it.
• Renewable without touching the rest, and a local key can be referenced without leaving the workstation.

Tasks

The platform's long-running operations — image builds, module builds, provisioning — with live progress, their author, and the error detail when one fails.

Profile and account

• My profile: identity, theme, language.
• My credentials, project by project, with a button to test them.
• Technician tool and registry access, to download for five platforms.
• Account setup: a guided page follows commissioning step by step.
• Consent, prerequisites, settings, DNS records, through to the account being active.
• The history of each transition is kept.
• Account zone: the shared and the dedicated one, with their commissioning state.
• The first level of the cascade is set there: image defaults, fallback networks, firewall, network.

The conventions found everywhere

• Implicit scope: the account comes from the address, every screen can be bookmarked.
• Lists: a title and a subtitle that explain the concept being handled.
• Create action on the right, state badges on the right, detail on click.
• One colour per source: zone, account, fleet, device, image — the same colours and badges on every page.
• Explicit inheritance: an empty field inherits from the parent, a badge separates override from inheritance, and a button always leads back to the fleet.
• Real time: image builds and monitoring are pushed live; lists only refresh while something is in progress.
• Visible audit: deployments, card writes, actions, states, timeline, console access — every action carries its author, its source and its outcome.