Pantacor Hub Docs

Appearance

Putting a build on a device ​

A succeeded build leaves one pvr export per architecture (<app>.pvrexport.tgz): a state patch with the app's container, its pvpkg/ overlay and signature, plus its objects. Adding it to a device is the same as adding any exported part: merge it into the device's state and post a new revision. Pick the export of the device's architecture (arm64 for arm64v8 devices, and so on).

In the web UI ​

  1. On the build's page, Artifacts → Download the export (checked against its sha256).
  2. Open the device, Manage tab → Begin Transaction.
  3. Upload the export as a new part. Its files are merged into the transaction; the device's other parts stay as they are.
  4. Review the diff and Commit Transaction. The device walks to the new revision like any other update.

With pvr ​

sh
pvr build download --platform arm64 $ID -o hello-http.tgz

pvr clone <user-nick>/<device-nick> my-device
cd my-device
pvr merge ../hello-http.tgz       # merges the export's files, keeps the rest
pvr checkout
pvr add .
pvr commit -m "hello-http 0.0.0-gc2aedc4"
pvr post -m "hello-http 0.0.0-gc2aedc4"

Review pvr status and pvr diff before committing. pvr merge adds the export's parts to the checkout; pvr import would replace the whole state with the export instead, which is not what you want here. See Updating with pvr for the rest of the cycle.

With an AI assistant (MCP) ​

With the Hub's MCP connector, an assistant can do it end to end: import_build_artifact takes the build's export into the account, plan_revision with the import_export operation merges it into a device's next revision (showing the changes and any signature warnings), and commit_revision sends it to the device.

Signatures on the device ​

Devices that verify signatures check the export's signature when they install it:

  • An export signed with the developer key installs on devices that accept development keys — the default for development images.
  • A device whose image trusts a signing identity needs apps signed with its OEM key (<identity>-oem), and the BSP and the OEM configuration signed with its platform key: in strict mode it refuses anything else, and anything unsigned. See what signs what.
  • A device configured for other release certificates needs exports signed with that key: build with a pvs signing secret.

To flash new devices rather than update running ones, build flashable device images.

The build's summary, and the plan in the MCP flow, say which key signed it.