Skip to content


Pantavisor implements a lightweight container run-time with the help of Linux Containers (LXC). Each container, in its minimal form, is then comprised of a rootfs that will be run isolated in its own name-space and an LXC configuration file. All these, as well as more advanced configuration, are included in the state JSON.


The most basic storage unit is always the rootfs. In addition to this, a container may define several more auxiliary storage volumes. Pantavisor gives flexibility to configure persistence of changes and encryption.

There a three types of persistence options:

  • permanent: changes are stored in a single writable location.
  • revision: changes are stored in a writable location pegged to the revision.
  • boot: a pure tmpfs storage that will throw away changes after a reset.

Storage can be linked to a storage disk.


Containers, by default, will automatically direct these logs from the container to the log server:

  • syslog
  • messages
  • lxc log
  • lxc console

This list can be expanded to other files using the state JSON.


With the addition of conditions, the start of a container can be delayed until all its conditions are satisfied by other reporting containers.

Conditions are just a key-value pair. The key is a string that identifies the condition, while the value is a string that has to be equal to the reported one for the condition to be met. Container names can also be attached to a condition, in which case the condition will not be true until the reporting container name matches the one attached to the condition.

The containers can report conditions either by using Pantavisor local control or automatically, in the case of the status conditions.


Containers can belong to one of the default groups created by Pantavisor:

  • data: for containers which volumes we want to mount but not to be started.
  • root: meant for the container or containers that set network connectivity up for the board.
  • platform: the default value for containers without group.
  • app: application level containers.

If a container does not have an explicitly defined group, it will be automatically set to platform, except if it is the first container in alphabetical order and no other container has been set to root, in which case it will be set to root.

Groups define how containers are started if no further conditions are set. In the most basic scenario, data containers are mounted first, and then it follows with the mounting and starting of root, platform and app containers. Conditions will be automatically set to the containers depending on its group to make sure this order is respected.

Group also determines if the device reboots or not after an update. If the update modifies any of the artifacts belonging to data, root or platform groups, the device will reboot after an update.


Roles can be set to a given container. Roles will determine the elements that Pantavisor will make available in the container rootfs. There is just one role supported for now: mgmt.

If no role is defined, Pantavisor just mounts these elements into the container under the /pantavisor path:

In addition to this, mgmt containers get these elements in /pantavisor:


After a new revision is updated, or after the board is booted up, the containers will try to start if they were not previously started (this could happen in case of a non-reboot update.

These are the different status containers can be at:

  • DATA: containers that belong to the data group will always be set to this status.
  • READY: the container is ready for start.
  • BLOCKED: any of the container conditions is not yet met.
  • STARTING: container is starting.
  • STARTED: container is running.
  • STOPPING: container is stopping because of a update transition.
  • STOPPED: container has stopped.

Status changes will be reported as conditions with status key attached to each one of the containers.

Additional Files

Before starting a container, Pantavisor will mount its main rootfs and any other configured volumes. Besides this, additional files can be attached to a revision to create a new overlay that will overwrite whatever is in that location in the rootfs of the container, creating the directories or files if necessary.

Thanks to this, configuration files or scripts can be added or modified without having to do it in the rootfs file itself when preparing a new revision.