Balena to Pantavisor
Balena is the closest of the migration sources to Pantavisor: both run your application as containers on the device. The difference is ownership. Balena runs containers (under balenaEngine, a Docker fork) on top of a host OS that is updated separately via hostOS/hostApp mechanisms. Pantavisor is PID 1 and treats everything as a container — the BSP, the kernel, system services, and your apps — so the base and the apps update through one signed revision.
See also: Pantavisor vs Balena for the capability comparison — footprint, openness, and OTA model.
How the concepts map
| Balena | Pantavisor | Notes |
|---|---|---|
| balenaOS (host OS) + hostApp updates | Pantavisor as PID 1, BSP as a container | The base and kernel are part of the same revision as your apps — no separate host-OS update path. |
docker-compose.yml multi-container app | Containers in a revision | Each service becomes a Pantavisor container. |
| balenaEngine (Docker fork) | LXC | On-device containers run under LXC, not a Docker daemon. See the FAQ. |
balena push / release | pvr commit + pvr post / push to Pantahub | The unit of update is a content-addressed revision. |
| balenaCloud fleet management | Pantahub (optional) | Or manage devices directly with pvr over the local network. |
| Delta layer updates | Object-level diffs (built in) | Only changed content-addressed objects are transferred. |
Migration path
- Translate your compose services to containers. Each service image is
added with
pvr app add --from <image>— Pantavisor converts it to an LXC container. See Install with the pvr CLI. - Move inter-service communication to the host network or pv-xconnect. Containers that shared a Docker network can use the host network namespace or the xconnect service mesh.
- Build your base with
meta-pantavisorinstead of relying on a separately-updated host OS. - Flash a Pantavisor image (Install on hardware) and manage the fleet via Pantahub.
What changes for your team
- The host OS stops being a separate update channel. Base, kernel, and apps are one revision, rolled back atomically together if needed.
- No Docker daemon on the device — containers run under LXC, supervised by PID 1.
- You keep the multi-container mental model, but gain whole-device atomicity and rollback.
📝 Note — Docker images still work
You do not have to rebuild your images.
pvr app add --from <image>pulls a standard Docker/OCI image and converts it to a Pantavisor container — see How does Pantavisor run Docker images?.