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 capabilities to your existing Yocto-built firmware.

What Each Tool Does Best

Task Yocto Pantavisor
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 single container
Kernel as a container ❌ No ✅ Yes (BSP container)

The Problem with Yocto Alone

Yocto is excellent at building firmware, but 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 kernel + device tree for your board
  • Build BSP container (kernel, modules, firmware)
  • Compose initial container set via PVROOT_CONTAINERS_CORE
  • Output: full bootable .wic image with Pantavisor as PID 1

Pantavisor phase — iterate fast, deploy often

  • Clone the device state: pvr clone https://pvr.pantahub.com/<USER>/<DEVICE_NICK>
  • 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

# Output (example):
# build/tmp-scarthgap/deploy/images/raspberrypi-armv8/pantavisor-starter-raspberrypi-armv8.wic

Or wire meta-pantavisor into an existing Yocto build manually — add the layer plus its dependencies (poky, meta-openembedded/meta-oe, etc.) to bblayers.conf and inherit pvroot-image in your image recipe.

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 registers with Pantahub and gets a nickname.

3. Manage Everything Above the Kernel with PVR

# Clone the device state
pvr clone https://pvr.pantahub.com/<USER>/<DEVICE_NICK> my-device
cd my-device

# Add / update / remove containers
pvr app add wificonnect --from=https://gitlab.com/pantacor/pvwificonnect:latest
pvr app update os --from=https://gitlab.com/pantacor/pv-platforms/alpine-connman:latest

# Sign, commit, push
pvr sig add --parts=wificonnect
pvr commit -m "Add wificonnect, refresh os"
pvr post https://pvr.pantahub.com/<USER>/<DEVICE_NICK>

Comparison: With vs Without Pantavisor

Scenario Yocto Only Yocto + Pantavisor
Update a Python app Rebuild entire image (30-60 min) Update container (2-5 min)
Deploy to 10,000 devices Flash all devices pvr post to fleet
Update fails Device bricked Automatic rollback
Add new service Rebuild image pvr app add
Team A updates kernel Affects Team B’s apps Isolated container updates

When to Choose Yocto Alone

You might stick with Yocto only if:

  • Your firmware is truly static (no app updates ever)
  • You’re building a single prototype
  • Your team has no container expertise
  • The hardware has <16MB storage

When to Add Pantavisor

Add Pantavisor when you need:

  • Faster iteration: Update apps without rebuilding the entire BSP
  • OTA updates: Deploy updates to devices in the field
  • Fleet management: Manage many devices from a central interface
  • App composability: Mix and match apps per product variant
  • Team independence: Kernel team and app team work independently
  • A/B testing: Test new app versions on a subset of devices

The meta-pantavisor Layer

The meta-pantavisor Yocto layer provides:

  • pantavisor-bsp — BSP container recipe (kernel + initramfs + modules + firmware)
  • pantavisor-starter — Full bootable image: BSP + Pantavisor + PVROOT_CONTAINERS_CORE
  • pantavisor-appengine — AppEngine variant for development and testing
  • pvroot-image / pvrexport / container-pvrexport classes — Compose containers and export .pvrexport.tgz artifacts
  • pvr recipe — PVR CLI for use on the host or inside pvr-sdk
  • LXC + bbappends — patches and config to run Pantavisor’s LXC integration
  • KAS configs — ready-to-use kas YAMLs for common boards (Raspberry Pi, etc.)

Repository: github.com/pantavisor/meta-pantavisor

Migration Path

If you already have a Yocto project:

  1. Add meta-pantavisor (and its layer dependencies) to bblayers.conf
  2. Build pantavisor-starter (or your own image inheriting pvroot-image) instead of your current image
  3. Keep your existing recipes — they still work as container sources
  4. Move frequently-changing components into containers (BSP container + per-service containers)
  5. Use PVR + Pantahub for deployment, updates, and rollback

No rewrite of your Yocto codebase. No workflow disruption.

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