# Pantavisor 019 Features: Restart Policy

In this post, we are going to talk about how to make use of our [container restart policy](https://docs.pantahub.com/containers/#restart-policy) feature included in the [Pantavisor 019 release](https://community.pantavisor.io/t/pantavisor-019-release/).

## Pantavisor Updates

Firstly, we need to understand how Pantavisor manages [updates](https://docs.pantahub.com/updates). Specifically, how the [transition](https://docs.pantahub.com/updates/#inprogress) to a new update is made after being installed (both [remotely](https://docs.pantahub.com/remote-control/) and [locally](https://docs.pantahub.com/local-control/)) and [validated](https://docs.pantahub.com/storage/#integrity).

Pantavisor will compare the currently running [revision](https://docs.pantahub.com/revisions/) and the upcoming one. This means comparing all the artifacts (objects and JSON files) that are associated to those revisions. Depending on the artifacts that are added, deleted or modified, a [reboot](https://docs.pantahub.com/updates/#reboot-transition) or [non-reboot](https://docs.pantahub.com/updates/#non-reboot-transition) transition will be performed. Affected artifacts associated to the [BSP](https://docs.pantahub.com/bsp/) will always trigger a reboot, while artifacts belonging to [containers](https://docs.pantahub.com/containers/) will depend on its **restart policy**. If the difference between the old and the new revisions contain artifacts coming from components with mixed policies, reboot transition will win.

There are currently two supported **restart policies**:

* **system**: any update that modifies any object or JSON belonging to at least one of the containers with system restart policy will result in a [reboot transition](https://docs.pantahub.com/updates/#reboot-transition).
* **container**: any update that only modifies objects or JSONs belonging to containers with the container restart policy will result in a [non-reboot transition]([https:/](https://docs.pantahub.com/updates/#non-reboot-transition)/).

## Setting a Restart Policy to a Container

As an example, we are going to add a [Home Assistant](https://www.home-assistant.io/) [container](https://hub.docker.com/r/homeassistant/raspberrypi3-homeassistant) to an existing [Pantavisor-enabled device](https://docs.pantahub.com/choose-device/) claimed from my [Pantacor Hub](https://hub.pantacor.com) account:


First step will be to clone our device as usual, in this case, a `Raspberry Pi 4` board with the [Pantavisor 019 image](https://docs.pantahub.com/initial-images/#stable-initial-images) installed:

pvr clone https://pvr.pantahub.com/anibal/home_rpi64_latest
cd home_rpi64_latest

To add the container with **system restart policy**, we have to explicitly set it in the `pvr app add` command:

pvr app add --from homeassistant/raspberrypi3-homeassistant --restart-policy system homeassistant
pvr add .
pvr commit
pvr post

The added container with **system restart policy** will trigger a full board reboot after we post the changes. A [DONE](https://docs.pantahub.com/updates/#done) status indicate the new update has been fully validated after a reboot and set as a checkpoint for potential [rollbacks](https://docs.pantahub.com/updates/#error) in the future:


If we prefer to only restart the container and perform a non-reboot transition, we can set the new container with the **container restart policy**:

rm -r homeassistant
pvr app add --from homeassistant/raspberrypi3-homeassistant --restart-policy container homeassistant
pvr add .
pvr commit
pvr post

Posting this will make Pantavisor transition to the new revision without rebooting. Notice the [UPDATED](https://docs.pantahub.com/updates/#updated) status which means that the revision was correctly transitioned to, but not set as a checkpoint for [rollbacks](https://docs.pantahub.com/updates/#error):


Now, any further update that affects any of the artifacts associated with the _homeassistant_ container will be transitioned to according to its **restart policy**.