Pantacor Hub Docs

Appearance

Deploying updates ​

Once a device is onboarded, everything you do to it is an update: a new revision appended to its trail that the device walks to on its own schedule. This page is the practical side — what you touch in the UI and what you watch while a device updates. For the underlying model (the +1 rule, step statuses, retries) see Trails & steps.

The mental model ​

You never push to a device. You set a goal — the newest revision — and the device pulls its way there whenever it is online, one revision at a time, reporting progress as it goes:

rev 0rev 1rev 2rev 3factory statecurrent (device is here)goal (HEAD)walks one step at a time when online · QUEUED → INPROGRESS → DONE

When current equals goal the device is in sync; the moment you append a new revision it is in transit until it catches up. A device that is offline for weeks just catches up later — there is nothing to keep alive.

Making a change ​

Open the device from your Devices list. The Device Navigator tabs are where updates happen:

  • Files — browse the device state as a file tree and edit files in place. Saving your edits appends a new revision containing the change.
  • State Description — the same state as raw JSON, for structural changes (adding a container/platform, changing object references). Editing it also appends a new revision.
  • Configuration — the device's metadata (user-meta/device-meta), used for labels and per-device configuration values.
  • Manage — the device's state split into parts (BSP, containers). Export parts as a tarball, or start a transaction to upload new parts and commit them as a revision — this is where pvr exports are uploaded.
  • Apps — to add whole applications to a device's state, publish them first under Apps and deploy from there.

Every change goes through the same door: a new step at revision HEAD + 1. There is no "small config tweak" path that bypasses the trail — which is what makes every change auditable and every device state reproducible.

Watching it land ​

  • Summary shows the device's sync state at a glance: the revision it is running versus the newest one.
  • Releases lists the trail — every revision with its status (NEW/QUEUED/INPROGRESS with progress, DONE, ERROR, WONTGO) and its state. This is where you follow an update rolling out.
  • Logs streams the device's logs, the first place to look when a step doesn't complete.

When an update fails ​

Pantavisor applies each step transactionally: if the new revision fails to apply or fails its health checks, the device rolls back to the previous working state and reports the step as ERROR. The device keeps running — the trail just halts there until you act:

  • Retry the failed step if the cause was transient (power loss, flaky network).
  • Fix and reroute: correct the state and replace the failed step so the device proceeds as if the bad step never existed.

The exact semantics of retry, reroute and abort are described in Trails & steps.

Automating deployments ​

Everything above is API calls under the hood — see the /trails endpoints in the API Reference. To script deployments (CI pushing a new release to a fleet), create an API token and append steps programmatically; the UI and the API operate on the same trail.

For a git-like command-line workflow — clone the device state, edit it locally, post it back as a new revision — use the pvr CLI: see Updating devices with pvr.