Today, we’re happy to announce Pantavisor Engine, a new and exciting version of our lightweight container framework and runtime for embedded Linux-based projects. This new version of Pantavisor extends the capabilities of Pantavisor, enabling service and product operators to install the container runtime agent on top of existing firmware.
Pantavisor Engine opens up a new world of possibilities with specific use cases for deploying and updating systems and applications on existing embedded devices and CPEs (Customer On-premise Equipment) running OpenWRT – a standard operating system for WiFi routers and other WiFi-enabled devices or any other embedded Linux distro.
Throughout this post, we’ll explore the differences between the two versions of Pantavisor and also touch on a few of the use cases for an engine vs. system-based Pantavisor.
Five key benefits of Pantavisor engine
With a modern container runtime engine running on existing devices and CPE, Communication Service Providers (CSPs), network operators and product makers gain the following benefits:
#1. Expand product models with new services and apps
Take advantage of unused memory and other space on existing CPE devices to offer new services and apps today. With Pantacor Engine, operators can deploy and run containerized apps in excess memory without taking up flash or NOR if needed.
#2. Maintain legacy apps while modernizing the stack
The ability to add a container engine to your existing legacy system and its applications means that legacy applications can be maintained alongside the newer containerized ones. Existing apps are slowly phased out and deprecated while modernizing your CPE’s firmware and software in a controlled manner.
#3. Deliver innovative services faster with DevOps
With containerized and modular systems and applications, you can also take advantage of state-of-the-art DevOps automated workflows and open source tools to experiment and continuously deliver new and innovative services to end users.
#4. Meet compliance with better security guarantees
Automatically apply updates and patches to systems, firmware and apps in a responsive and timely manner. With automation, you can deploy regulated apps to check that you meet network speed compliance as well as other required NIST regulations for IoT.
#5. More reliability with zero downtime updates
Remotely deploy new services, updates, and patches safely over the air to CPE fleets with zero downtime. Pantavisor’s git-like developer experience enable CSP operators to always maintain a good device state with its ability to roll back and roll forward whenever needed.
What is Pantavisor?
Before getting into the differences between Pantavisor and Pantavisor engine, it’s essential to understand what Pantavisor solves for embedded Linux product makers.
If we look at how embedded Linux systems and products are built, we will notice that the tools and techniques have not changed much over the last 20 years. While cloud computing and modern software engineering has pushed the bar revolutionizing the way applications are built and managed, embedded Linux software development tools and methodologies have remained much the same.
Near limitless resources in the cloud are not available to embedded
There are several reasons for this divergence between embedded and cloud. One of the most significant is the number of computing resources available. While large spec embedded devices will eventually dominate, most IoT and embedded Linux products today run on the low end of the spectrum. This is different from cloud developers, who have an almost infinite amount of resources available. The truth is that most IoT devices cannot run Kubernetes or even K3S and have trouble running the Docker engine or dockerd.
Monolithic architectures slow down deployments
Another significant difference between cloud and embedded engineering is software architecture. Cloud apps built in containers have long ago embraced independently containerized services or microservices to build a distributed application that is more easily updated. While this was happening in the cloud, embedded engineers are still building monolithic systems (with either Yocto or Buildroot or others) that can be error-prone and challenging to update. The cloud solved long ago that if you want to deploy fast, keep software secure and deliver more features to your users, you need to be able to update your applications quickly whenever required.
Speed and agility of the cloud without the overhead
Pantavisor enables the speed and agility of the cloud but with an embedded footprint. It is a runtime, control plane, and framework for building, orchestrating, and managing containerized embedded systems. Transform monolithic embedded Linux systems with containers to run and manage your system and apps in containers in the userland.
With a containerized and modular embedded system, product makers can implement state-of-the-art DevOps workflows and choose from the vast number of open source tools available that can automate CICD pipelines. In addition, with a modular and more easily updated system, teams also gain the benefits of agility, portability and better security for IoT fleets. 
Monolithic embedded Linux system vs. modular embedded Linux system
Pantavisor system vs. Pantavisor engine
We’re now offering two different versions of Pantavisor: engine and system that are suitable for a variety of different use cases. Both offer the same embedded-first container runtime and orchestration functionality but instead manage and orchestrate from different parts of the Linux stack.
Pantavisor system (original Pantavisor)
Both Pantavisor System (our original Pantavisor) and Pantavisor Engine are responsible for building, orchestrating and managing containers in the userland, but the key difference is that Pantavisor (system) can also manage and deploy updated drivers and kernel images to the BSP. This enables Pantavisor system to manage the full lifecycle of the device, both the system drivers, kernel as well as any containerized apps you have running in the userland.
Pantavisor system (original Pantavisor)
It is important to note that the components and binaries in the BSP are not containerized. This is because the Pantavisor is the second item to boot. For example, the bootloader runs the kernel and then it runs Pantavisor (the container runtime manager) in the root namespace.
Pantavisor does however componentize and package the BSP to make it simpler to update through automated CICD pipelines. Below are the BSP files and binaries found in a Pantavisor-enabled device.
| File | Description |
| build.json | Description of the BSP build as reproduced from git. |
| firmware.squashfs | Board firmware in compressed Linux format. |
| kernel.img | Linux kernel img |
| modules.squashfs | Added Linux modules in compressed Linux format. |
| run.json | Defines the order the bootloader should run each component. Special add-ons can also be specified at initrd instead of at compile time. |
| src.json | The BSP manifest and url for pvr cli. |
| pantavisor | The container runtime binary. |
See, Firmware Customization and Deployment Strategies for Embedded Linux Fleets for more on how to update the BSP with Pantacor Hub.
Pantavisor engine
Pantavisor engine is only responsible for managing the containers in the userland. It is a lightweight version of a container runtime with the same tiny footprint designed specifically for embedded Linux devices. The engine does not manage the BSP, but it does manage and orchestrate all of the containerized apps in the userland.
Pantavisor engine
Installation method is another difference between the two Pantavisors. The Pantavisor system is just that – a system that gets installed by flashing your entire device with a Pantavisor-enabled BSP. The engine on the other hand is installed to an existing system that keeps any SDKs, and other specialized firmware in the BSP intact.
Wrapping up
In this post, we discussed a new configuration for Pantavisor that we call engine. The Pantavisor engine has all of the same great features as the original Pantavisor. The main difference is that it does not manage the BSP (firmware and kernel drivers) that the original Pantavisor does. By eliminating the BSP management from Pantavisor, customers can run and manage containerized applications on top of existing firmware on existing CPEs.
In an upcoming post, we’ll discuss how these two configurations can be leveraged by ODMs (Original Device Manufacturers) to build in modern container-based workflows and by CSPs to expand their current services and offer new and innovative services today on CPEs.
About Pantavisor and Pantacor Hub and Fleet
Pantavisor and its platform, Pantacor Hub and Fleet is an IoT device management solution that leverages containers. With containers product teams and service operators can implement modern DevOps best practices to continuously deliver new applications and keep them up to date and secure.
Learn more at What is Pantacor? or contact us for a demo.