Container image updates

Sirio tells which containers run an older image than the one their tag names on the registry, and updates them from the panel: it pulls the image and recreates the container on it, keeping its configuration, volumes, networks and overrides. It never updates anything on its own.

What gets checked

Every container, every 6 hours (the first check runs a minute after Sirio starts), or when you press Check now on the Containers page (Docker section) or in a container’s detail (Configuration tab). For each distinct reference, such as nginx:1.27, Sirio asks the registry through the Docker daemon which digest the tag names now, and compares it with the image the container runs. Only the manifest is fetched, never the layers. The daemon’s own registry settings (mirrors, proxy, insecure registries) apply.

A container shows one of these states:

State	Meaning
Up to date	the container runs the image its tag names
Update available	the tag has moved on: the registry has a newer image
Couldn’t check	the registry didn’t answer, or refused: the error says why
Not checked yet	created or recreated since the last check
Not checked	one of the cases below

Some containers are deliberately never checked or updated:

• Containers deployed from a repository, meaning a Compose project started from a pipeline’s checkout. Their compose file belongs to the repository, so which image they run is up to the repository and its pipeline. Sirio leaves them alone.
• Images pinned to a digest (nginx@sha256:…): they never change.
• Images built or loaded on the host, or containers created from an image ID: there is no registry to ask.

Sirio sends no registry credentials, so a private registry shows “Couldn’t check”. Anonymous Docker Hub requests are rate limited per IP address, and pulls count against the same limit. The check asks once per reference, not once per container, every 6 hours.

Updating a container

Containers with a newer image carry an update badge in the list, and a notice in their detail. Both open the update window. Updating needs the containers.edit permission on the container’s site, or on the Docker section for a container that belongs to no site.

1. Backup, optional. If the container belongs to a site with a backup plan, and you may run it (backups.run), you can pick a plan to run first. If the backup fails, the container is left as it is. The run shows up in the plan’s history with the trigger “image update”.

2. Pull. Docker downloads the image again under the same reference.

3. Recreate. If the pull brought a different image:

   • A plain container is recreated from its own configuration. Docker merges the image’s defaults into a container’s configuration at creation (PATH, version variables, CMD, labels, the healthcheck), so Sirio first drops whatever still equals the old image’s default, and the new image provides it instead. Settings of the container’s own stay. The old container is renamed aside and put back if the new one fails to create or start.
   • A Compose-managed container is recreated by Docker Compose (up --force-recreate --no-deps) from its compose file and .env, as with “Reload variables”. Compose runs as Sirio’s user, which needs read access to the project’s files.

   The environment and port overrides are applied again in both cases. If the pull brought nothing new, nothing is recreated.

The whole update holds the site’s lock, so it waits for a deploy or backup of the same site to finish, and they wait for it in turn. Once it has started it carries on to the end even if you close the page: the panel may be served through the very proxy being updated. The old image stays on the host, untagged. Remove it from Images once you’re happy with the new one.

Every update is written to the activity log as docker.container.image_update.

Turning it off

SIRIO_IMAGE_UPDATES_ENABLED=false stops the checks and removes the badges and the update action.