Skip to main content

Pantavisor vs Yocto — complementary, not competitive

The short answer: use both​

Pantavisor is not a Yocto alternative — it's a Yocto companion.

If you're already using Yocto to build embedded Linux images, you don't need to replace it. Pantavisor provides a Yocto layer (meta-pantavisor) that adds container orchestration, atomic OTA updates, and fleet management to your existing Yocto-built firmware.

What each tool does best​

TaskYoctoPantavisor
Build kernel & drivers✅ Best-in-class—
Create BSP for new hardware✅ Best-in-class—
Generate toolchain✅ Best-in-class—
Base rootfs creation✅ Best-in-class—
Container orchestration❌ Not designed for✅ Purpose-built
Atomic OTA updates⚠️ Bolt-on (Mender, SWUpdate, RAUC)✅ Built-in
Fleet management❌ Not included✅ Pantahub (open source)
Signed system state⚠️ Image signing only✅ PVS over state JSON
Independent app updates❌ Requires full rebuild✅ Update a single container
Kernel as a container❌ No✅ Yes (BSP container)

The problem with Yocto alone​

Yocto is excellent at building firmware, but on its own it has limitations:

  1. Monolithic updates — every change requires rebuilding and reflashing the entire image.
  2. Slow iteration — 30–60 minute build cycles for small app changes.
  3. Risky deployments — no automatic rollback if an update fails.
  4. No fleet visibility — managing thousands of devices requires external tools.

The solution: Yocto + Pantavisor​

Two phases, two tools, one workflow:

Yocto phase — build once, rarely changes:

  • Build the kernel + device tree for your board.
  • Build the BSP container (kernel, modules, firmware).
  • Compose the initial container set.
  • Output: a full bootable .wic image with Pantavisor as PID 1.

Pantavisor phase — iterate fast, deploy often:

  • Clone the device state with pvr clone.
  • Compose / update / remove containers (pvr app add|update|rm).
  • Sign and push (pvr sig add, pvr commit, pvr post).
  • Pantavisor switches atomically and rolls back if any container fails its status_goal.

How it works in practice​

1. Build a Pantavisor-enabled image with Yocto​

The fastest path is the KAS-driven build that ships in meta-pantavisor:

git clone https://github.com/pantavisor/meta-pantavisor.git
cd meta-pantavisor

# Builds BSP + Pantavisor + initial container composition into a flashable .wic
kas build kas/scarthgap.yaml:kas/machines/raspberrypi-armv8.yaml:kas/bsp-base.yaml

See Build with Yocto for the full guide.

2. Flash and boot​

sudo pvflasher copy \
  build/tmp-scarthgap/deploy/images/raspberrypi-armv8/pantavisor-starter-raspberrypi-armv8.wic \
  /dev/sdX

On first boot the device can register with Pantahub and get a nickname.

3. Manage everything above the kernel with pvr​

# Clone the device state
pvr clone https://pvr.pantahub.com/USERNAME/DEVICE_NAME my-device
cd my-device

# Add / update / remove containers
pvr app add wificonnect --from gitlab.com/pantacor/pvwificonnect:latest

# Sign, commit, push
pvr sig add --part wificonnect
pvr commit -m "Add wificonnect"
pvr post https://pvr.pantahub.com/USERNAME/DEVICE_NAME

With vs without Pantavisor​

ScenarioYocto onlyYocto + Pantavisor
Update a Python appRebuild entire image (30–60 min)Update container (2–5 min)
Deploy to 10,000 devicesFlash all devicespvr post to the fleet
Update failsDevice brickedAutomatic rollback
Add a new serviceRebuild imagepvr app add
Team A updates kernelAffects Team B's appsIsolated container updates

When to choose Yocto alone​

  • Your firmware is truly static (no app updates ever).
  • You're building a single prototype.
  • Your team has no container expertise.
  • The hardware has very little storage.

When to add Pantavisor​

  • Faster iteration — update apps without rebuilding the entire BSP.
  • OTA updates — deploy to devices in the field.
  • Fleet management — manage many devices from one place.
  • App composability — mix and match apps per product variant.
  • Team independence — kernel team and app team work independently.

Key takeaway​

Yocto builds the ship. Pantavisor loads the cargo and charts the course.

Use Yocto for what it's great at — building the BSP. Use Pantavisor for what it's great at — managing the dynamic parts of your system.

Next steps​