updater

The updater domain has 5 actions. On the meta surface they are all reached through arcane_updater; on the individual surface each one is its own tool; on the dynamic surface run them with arcane_execute_action and the canonical ID.

Summary

Action	Title	Kind
updater.container_update	Update a single container	destructive
updater.history	Get updater history	read
updater.project_check	Check project service updates	write
updater.run	Run updater	destructive
updater.status	Get updater status	read

Actions

updater.container_update

Update a single container

Pull the latest image and apply the appropriate update strategy for a specific container

• Kind: destructive — requires confirm: true
• Required parameters: containerId
• Meta tool: arcane_updater with "action": "container_update"
• Individual tool: arcane_updater_container_update
• Arcane route: POST /api/environments/{id}/containers/{containerId}/update
• Operation ID: update-container
• Usage: Pulls the container’s image tag and, when the image changed, recreates the container (same name, new ID). The result counts checked/updated/skipped/failed and each item has status and updateApplied. containerId from container.list. Use instead of updater.run to touch one container. A compose service is better updated with project.update_services. It ignores the auto-update exclusion setting and opt-out label, but skips a container run by a Podman quadlet (since Arcane v2.17.1, use podman.auto_update_run). async=true returns the accepted activity at once (follow it with activity.get).
• Related actions: updater.run, updater.status, container.list, container.get, image_update.check_ref, activity.get

updater.history

Get updater history

Get the history of update operations

• Kind: read
• Required parameters: none
• Meta tool: arcane_updater with "action": "history"
• Individual tool: arcane_updater_history
• Arcane route: GET /api/environments/{id}/updater/history
• Operation ID: get-updater-history
• Usage: Stored per-resource auto-update records (resource, status, old/new image, updateApplied, error), newest first, and limit defaults to 50. Only unscoped runs write them (updater.run without resourceIds, dry runs included, and the scheduled auto-update). Scoped updater.run calls and updater.container_update are not recorded, so read their outcome from their own result or from activity.list.
• Related actions: updater.run, activity.list

updater.project_check

Check project service updates

• Kind: write
• Required parameters: projectId
• Meta tool: arcane_updater with "action": "project_check"
• Individual tool: arcane_updater_project_check
• Arcane route: POST /api/environments/{id}/updater/projects/{projectId}/check
• Operation ID: check-project-updates
• Since: Arcane v2.11.0
• Usage: Checks each image service of a compose project against its registry, honoring the services’ update-policy labels, and replaces the project’s stored image-update records with the fresh results. Nothing is pulled or recreated. projectId from project.list. Returns updateInfo-style fields (status, hasUpdate, imageCount, imagesWithUpdates, serviceUpdates). Apply with project.update_services or project.redeploy.
• Related actions: project.list, project.updates, project.update_services, project.redeploy

updater.run

Run updater

Apply pending container updates

• Kind: destructive — only when dryRun is false or absent; those calls require confirm: true, the others do not
• Required parameters: none
• Meta tool: arcane_updater with "action": "run"
• Individual tool: arcane_updater_run
• Arcane route: POST /api/environments/{id}/updater/run
• Operation ID: run-updater
• Usage: Applies updates across the environment and waits for the result (checked, updated, restarted, skipped, failed, items, activityId). Without resourceIds it applies the pending standalone image updates found by earlier image_update checks. With resourceIds and type container, project (project ID or compose:<name>) or image it updates only the matching containers, and 400s when none match. dryRun reports without changing anything, forceUpdate updates even when current. It fails if another update is already running (see updater.status). With or without resourceIds, a manual run updates opted-out containers too: those with the label com.getarcaneapp.arcane.updater=false or named in the autoUpdateExcludedContainers setting, when they have a pending update (since Arcane v2.17.1. Without resourceIds that means every opted-out container with one. Containers only restarted as dependents still honor both.) automatic=true honors them, as the scheduled auto-update and webhooks do. Containers run by a Podman quadlet are always skipped (use podman.auto_update_run). Only the scheduled auto-update waits for the autoUpdateDelay setting (hours since Arcane first saw the new image, and a container’s com.getarcaneapp.arcane.updater.delay label overrides it, 0 included). This action applies at once. Needs confirm=true unless dryRun=true.
• Related actions: updater.status, updater.container_update, image_update.check_all, image_update.summary, activity.get, podman.auto_update_run

updater.status

Get updater status

Get the current status of the updater

• Kind: read
• Required parameters: none
• Meta tool: arcane_updater with "action": "status"
• Individual tool: arcane_updater_status
• Arcane route: GET /api/environments/{id}/updater/status
• Operation ID: get-updater-status
• Usage: Live, in-memory view of updates in progress: updatingContainers and updatingProjects counts plus their containerIds and projectIds. Check it before updater.run or updater.container_update, which refuse to start while another update holds the updater.
• Related actions: updater.run, updater.container_update