How Pantacor Hub works

Pantacor Hub (the Pantahub API plus this web UI) is a cloud service for managing fleets of Pantavisor devices and pushing software updates to them over the air.

The platform is built from a small set of pieces. Understanding how they fit together makes the rest of the docs — and the API Reference — easy to navigate.

How these docs are organized

Four sections, from ideas to endpoints — each linking down to the next level of detail:

Section	Question it answers
How it works (you are here)	What is a device, an object, a trail?
Guides	How do I do things — onboard, update, self-host?
Services	How do I drive each REST service from the command line?
API Reference	What exactly does each endpoint take and return? Try it live.

The pieces

Concept	What it is
Accounts & identity	Who you are, and the tokens that authenticate API calls.
Devices	The Pantavisor machines registered to your account.
Objects	Content-addressed storage for the artifacts a device runs (kernel, system, apps).
Trails & steps	The stepwise revision history that drives each device's configuration.
Apps	Reusable containers/content you compose into a device's state.

The core idea: configuration as a trail

Every device has a trail — an append-only sequence of steps, each a numbered revision of that device's complete state (which kernel, which system, which apps, and their config).

rev 0 ──▶ rev 1 ──▶ rev 2 ──▶ rev 3      (the trail)
 │                              │
factory state                  goal (HEAD)

• The device reports the revision it is currently running.
• You append a new step to set a new goal.
• The device, whenever it is online, walks the trail one revision at a time toward the goal, reporting progress/status for each step.

Because the trail is stored in the cloud, a device that is offline for hours or weeks simply catches up when it reconnects — there is no live connection to maintain. This is what makes updates asynchronous and resilient.

See Trails & steps for the full lifecycle (queueing, errors, retries, reroute, abort).

How an update flows

1. You upload artifacts as objects (or reference existing ones / apps).
2. You append a step to the device's trail describing the new desired state, with revision = current HEAD + 1.
3. The device picks up the new step, downloads the referenced objects, applies the change, and runs health checks.
4. On success the device advances to the new revision; on failure it rolls back to the previous state and marks the step ERROR.

Where the UI fits

The guides cover doing all of this from the web UI. Everything the UI does is the Pantahub API underneath — each of its services is documented with command-line flows, and every endpoint can be tried live in the API Reference — so anything you can click, you can also automate with an API token.

The whole platform is open source and can be deployed on your own infrastructure with Docker Compose or Helm.