> For the complete documentation index, see [llms.txt](https://docs.cipp.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cipp.app/user-documentation/cipp/advanced/container-management/status.md). # Status & Updates The Status & Updates page lets you view and manage the CIPP application container on a self-hosted instance. From here you can see which image and version are running, control the release channel, configure automatic update checks, and restart the container. The page is laid out top to bottom: a status strip summarising the running container, any notices that need action, a row of action buttons, and two settings cards. ## Status Strip The strip across the top of the page summarises the state of the running container in four tiles. | Tile | Description | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Release Channel | The channel the running container was built from. Hover to see the running image tag. A branch build shows its own tag here, in red, rather than a channel name. | | App Version | The version of CIPP currently running, followed by the short commit it was built from. Select the tile to open **Build Details**. | | Update Status | **Never checked**, **Update available**, or **Up to date**. Select the tile to open **Latest on this channel**. | | Last Checked | How long ago the last update check ran, such as `3h ago`. Hover for the exact date and time, in your local time zone. | Selecting the App Version tile opens a **Build Details** panel: | Field | Description | | ----------------- | ------------------------------------------------------------------ | | Image Tag | The tag of the running container image. | | Commit SHA | The source commit the running image was built from. | | Image Built (UTC) | The date and time the running image was built. | | Container Image | The full reference of the running container image, when known. | | App Service | The name of the App Service hosting the container, when available. | Selecting the Update Status tile opens a **Latest on this channel** panel, showing the version, build date and image digest of the newest image found on your channel by the last check. Build details are baked into the image when it is built, and some of them are simply absent from locally built and development images. Any field the running build does not report is left out of these panels rather than shown as unknown, so a development image may show only two or three rows. ## Notices Two notices can appear directly below the status strip, and only when there is something to act on. * A **channel change is pending**: the running and configured channels differ, and the container needs to be restarted to apply the change. Both channels are named in the notice. * A **container update is available**: a newer image has been published on your channel, and restarting will pull it. ## Actions Three buttons sit between the status strip and the settings cards. | Action | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Refresh Status | Re-reads the status of the running container. This does not contact the container registry, so it can never trigger a restart. | | Check for Updates | Asks the container registry whether a newer image has been published on your channel. Opens a confirmation dialog first. | | Restart Container | Restarts the application container. Opens a confirmation dialog first. | ### Check for Updates {% hint style="warning" %} A manual update check is not always read-only. If **Auto-restart when an update is detected** is enabled, finding a newer image restarts the container immediately, causing brief downtime. The dialog warns you when this is the case and its button reads **Check & Apply** instead of **Check Now**. Use **Refresh Status** if you only want to re-read the current state. {% endhint %} With auto-restart off, a check only records what it found. Nothing is pulled and nothing restarts until you restart the container yourself. ### Restart Container Restarting causes a brief period of downtime while the container comes back up. The newest image on the current channel is pulled as it comes back, so a restart always updates to the latest image on the channel, whatever the reason for the restart, including a channel change or a pending update. ## Release Channel This card selects which release channel the container follows. Changing the channel updates the container image tag; the new image is pulled on the next container restart. | Channel | Description | | --------------- | ------------------------------------------------------------------- | | Latest (Stable) | The stable release channel. | | Dev | Development builds, which may include unstable or untested changes. | | Nightly | Nightly builds, which may include unstable or untested changes. | Choose a channel and select **Update Channel** to apply it. The change takes effect on the next container restart. Switching to Dev or Nightly may introduce unstable or untested changes. The channel list is read from the container registry when the page loads, grouped into **Standard channels** and any branch builds that currently exist. Use the refresh button on the field to reload the list without reloading the page, which is useful when waiting for a branch build to finish. The field also accepts a tag typed by hand as a fallback; whatever you enter is validated before it is saved. ### Branch builds Below the standard channels the list may also show **Branch builds**: images built from a branch that has not been merged yet, so a change can be tested on a real instance before it ships. They are named after the branch they came from, such as `fix-sso-multi-domain` or `feat-new-report`. A branch build tag follows its branch, in the same way `dev` and `nightly` do: if the branch is built again, the container picks up the newer image on its next restart. To hold one exact build instead, set the container image to its digest rather than its tag. The build summary in the GitHub Actions run prints the full reference to use. Only builds that currently exist are listed, and the tag is checked before the change is saved, so a build that has already been removed cannot be selected by mistake. Branch builds are **not supported** and are intended for testing only: * They receive no updates, and the automatic update check does not apply to them. * They are deleted when their branch is deleted, and swept after 30 days. Once the image is gone the container cannot start until you switch back to a standard channel, so move off a branch build as soon as you have finished testing. Selecting a branch build shows a warning in the card before you save it, and the Release Channel tile turns red once one is running. Unless you have been asked to test a specific build, stay on Latest (Stable). ## Update Checks This card configures how often CIPP asks the container registry whether a newer image has been published on your channel. By default, it checks every hour and auto-restarts at 23:00. | Setting | Description | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Check Interval | How often CIPP checks the registry for a new image: Disabled, Every hour, Every 4 hours, Every 12 hours, or Every day. | | Preferred Check Time | The hour of the day, in 24-hour time, at which the check should run. | | Auto-restart when an update is detected | When enabled, CIPP automatically restarts the container to apply an update once one is found. | Select **Save Settings** to store these options. Setting Check Interval to **Disabled** turns off scheduled checks and disables the other two settings, as neither has any effect without them; you can still check on demand with **Check for Updates**. Note that if the container restarts for any reason, the latest image for the current release channel is pulled regardless of these settings. ## Update History The version changes recorded for this instance, newest first, so you can see when it landed on the build it is running and what it was on before. | Column | Description | | ---------------- | ------------------------------------------------------------ | | Recorded At | How long ago the change was recorded, such as `3 hours ago`. | | Previous Version | The version the instance was running before the change. | | New Version | The version it moved to. | | Image Tag | The image tag it landed on. | A change is recorded when the container starts on a different version from the one last seen, so the time recorded is when the new build first ran rather than when the image was published. The most recent 50 changes are shown. Until a change has been recorded the table is empty. Version transitions are recorded from the next update onward, so a newly deployed instance starts with an empty history rather than a backfilled one. *** ## Feature Requests / Ideas We value your feedback and ideas. Please raise any [feature requests](https://github.com/CyberDrain/CIPP/issues/new?template=feature.yml) on GitHub. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cipp.app/user-documentation/cipp/advanced/container-management/status.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.