Panel Fleet

Use Fleet to enroll other boxes, allow and audit signed remote actions, hold incoming work during restarts, synchronize verified files, inspect link health, and review guarded campaign progress. Fleet controls are opt-in: a connected peer is not automatically authorized to accept actions.

Where to find each screen

Native pages place help markers beside registered controls. All operations use the same fleet owner and permissions; there is no separate state behind a second tab interface. The membership view updates its non-sensitive role and report summary periodically; refresh it for a complete new snapshot. An unauthenticated visitor or signed-in viewer sees no privileged fleet form.

Join a second box and transfer a model

1. On the intended primary, open Fleet membership at /rust/fleet. Choose This box's role = Primary, then select Save fleet settings with the confirmation checked. Verify Fleet identity and reporting displays Primary.
2. Choose Generate join code under Enroll another box. The primary creates a short-lived, single-use enrollment code; share it with the operator of the second box by an appropriately trusted channel.
3. On the second box, choose Member under This box's role, enter Primary URL (members only) and Single-use join code (members only), then select Save fleet settings after confirming. The settings owner performs enrollment with the primary; no direct browser transport request is needed. It must report back to the primary before it can be trusted for remote actions. Do not reuse a spent code.
4. On the member, use Allow signed remote actions to opt in to only the signed actions and instance IDs intended for that member. Check the primary's member list and Report now results; failed authentication, missing reports and blocked clocks should not be ignored.
5. Open Fleet sync on the primary. Under the summary and peer list, check that the destination is marked sync-ready. Use Start a verified transfer: choose source and destination, the item type, a path relative to the selected verified library, and HTTPS. Choose the port, bandwidth limit and chunk size within the offered limits. Check the explicit authorization box, then select Start fleet sync.
6. Watch Active fleet sync transfers and Recent fleet sync history. A queued transfer is not a complete or verified file. If a transfer is interrupted, use Resume an interrupted transfer with the actual job ID and confirmation. To stop a queued or running transfer, use Cancel a queued or running transfer. Cancellation is checked between chunks; it cannot undo a completed publication.
7. Alternatively open Fleet guided tasks, choose Join a box and sync a model, and run each applicable step. Supply source box, destination box, file path and authorization explicitly. Manual steps open the page where the second-box operator acts; the guide cannot quietly join the remote box for them. The reversible transfer step provides cancellation when given the generated job ID and confirmation.

Remote actions are signed and subject to the receiving member's allowlist. Queue signed action queues only an enrolled, online, allowed action; Cancel pending action may stop pending work, but not undo an action already applied. Change gateway routing prevents new work during a planned restart when set to Drain. Rotate action key requires new key delivery and fingerprint confirmation; Revoke membership rejects future reports until a member joins again.

Diagnose links and prepare an overlay

1. Open /rust/fleet/links to inspect Local clock and network, Members, and Configuration drift. A missing, stale or untrusted clock is not evidence of safe signed action delivery.
2. For a joined member, select Probe a joined member and provide its authenticated private/link-local address, port, attempts, and bytes per sample. Confirm the probe before submitting; it generates active traffic. Probes are refused for addresses not reported by that enrolled member.
3. For a design-only overlay, use Plan overlay. Enter at least two node lines as name, overlay IP, endpoint (optional), listen port; each node needs its own unique, permitted overlay address and valid port. Supply an MTU from 576 to 9000. Generate plan only returns a plan including sensitive generated keys and example commands: it does not create interfaces, write keys, alter routes, or run commands. Store and distribute keys securely outside the Panel.

Run and verify a campaign

1. In /rust/fleet/campaign, inspect Signed receipt progress and the displayed owner-control state. A campaign requires independently provisioned protected policy, authorized enrolled members, and live safety gates; without them the controller refuses to dispatch.
2. In Member campaign history, supply an enrolled member ID, offset (zero or greater) and row count (1–100), then choose Inspect member history. Rows labeled unsigned_local_diagnostic describe local transport events, not signed proof of installation. If signed receipts are provisioned, the page shows their independent verification state.
3. Open Live owner qualification and choose Inspect live qualification as an administrator. This reads local privileged updater state, not network acknowledgments. Missing or unavailable evidence does not qualify a release.
4. Return to Fleet campaign. Tick the explicit authorization checkbox and select Run controller tick once. The existing owner rechecks signed policy, receipt history, clock and admission conditions. A successful response can contain queued: this describes pending work, not completed installation. A dispatched command cannot be automatically withdrawn by the guide.
5. Refresh Signed receipt progress and each member's history to follow independently authenticated receipts. Repeat a tick only after reviewing the resulting state. The Run and follow a fleet campaign guide walks through history, explicit confirmation, guarded dispatch and receipt checking.

Control and help reference

The help text below is the text displayed by the fleet feature markers. The table includes control-level help for each form field, along with the overall action help.

Native fleet form actions and results

The native Fleet page submits its controls to dedicated paths so every form reaches the fleet owner rather than a legacy page handler. Form targets are:

Each action displays the actual owner response. Queued means an action was accepted for later delivery, not that it ran; failed does not mean an action succeeded. All state-changing actions except the member's Report now require the explicit confirmation checkbox. A signed command also requires an enrolled online member and its own policy to permit the operation. Use the member action log and independently verified campaign progress to observe completion.

Field-level help

Direct enrollment (POST /api/fleet/join) and restart event reports (POST /api/fleet/event) are authenticated member-to-primary transport operations. They are not separate browser action forms: membership settings initiate member enrollment and the fleet inventory or action logs show resulting state. These transport endpoints do not bypass one-time codes, authentication or signed-action verification.

Safety and access

Only an authenticated administrator can issue join codes, modify remote-action permissions, probe members, generate link plans, start/resume/cancel transfers, inspect protected campaign history and live owner state, or tick the controller. The receiving member still authorizes signed actions according to its own policy. Fleet peer transport endpoints remain machine-to-machine endpoints: their observable state appears in the fleet, sync, link and campaign screens instead of allowing raw transport requests from the browser.

Do not confuse a member's network report or a transport acknowledgment with a verified installation receipt. Use the independently signed receipt and privileged updater qualification before treating a campaign stage as complete. See Panel API, Panel Instances, and Reference Guided Tasks for related controls.