⚡️ Feature Request: Automatically refresh upstream images and re-patch patched images

[juanqp07]

Feature Description

Add an automated update workflow for patched Docker images that detects new upstream image versions, rebuilds the patched images using the latest upstream version, and optionally redeploys the containers using those images.

For example, an image such as ghcr.io/example/app:latest-patched should be linked to its upstream image, ghcr.io/example/app:latest. When the upstream image changes, Arcane should be able to automatically pull the new version, scan it, apply available security patches with Copacetic, and optionally update the associated container or Compose stack.

Problem It Solves

Currently, Arcane's image update checker skips locally built patched images and reports messages such as:

local build, registry check skipped

This makes sense because patched images are built locally and are not necessarily published to a remote registry. However, it also means that the normal image update workflow cannot determine whether the upstream application image has been updated.

Scheduled vulnerability patching and upstream application updates solve two different problems. Patching an existing image does not automatically bring its application to the latest release, and pulling a new upstream image does not automatically recreate its patched variant.

For users running many patched containers, manually tracking upstream versions, rebuilding patched images, and redeploying their services becomes tedious and increases the risk of running outdated application versions.

Proposed Solution

Introduce an optional automated update workflow for patched images, integrated with Arcane's existing image update checking, vulnerability scanning, and Copacetic patching capabilities.

The workflow could:

1. Track the upstream image: Store an explicit association between each patched image and its original image, including the repository, tag, and relevant image digest. Avoid relying solely on the -patched suffix to infer the source image.
2. Detect upstream updates: Periodically check the upstream registry for a newer image digest, using the configured registry credentials where necessary.
3. Pull and scan the new image: When the upstream image changes, pull the new version and run the existing vulnerability scanning workflow.
4. Rebuild the patched image: Apply available security patches to the new upstream image using Copacetic, preserving the patched image's naming convention and relevant build metadata.
5. Update the running services: Offer an option to automatically redeploy the affected container or Compose stack once the new patched image is ready. Users should also be able to require manual approval.
6. Provide safe failure handling: Report the status of each stage, retain the previous working image until the update succeeds, and provide a clear way to roll back if the deployment fails.

The feature should be configurable globally and per image or stack, with options to enable automatic upstream updates, automatic repatching, and automatic redeployment independently.

A useful first implementation could focus on detecting upstream changes and rebuilding patched images, leaving automatic redeployment disabled by default.

Alternatives Considered

• Manually pull and rebuild images: Works, but requires repeated manual intervention for every patched image.
• Use an external image update notifier: Tools such as Diun can notify users about upstream updates, but notifications alone do not orchestrate the full update, repatching, and redeployment workflow.
• Use custom scripts or scheduled jobs: This can automate the process, but requires maintaining custom logic outside Arcane and integrating it with Arcane's existing scanning and deployment workflows.
• Use a conventional container updater: Generic image updaters do not necessarily understand the relationship between an upstream image and its locally patched derivative, or know that Copacetic needs to run again after an upstream update.

An integrated solution would provide a more consistent experience while reusing Arcane's existing capabilities.

Additional Context

This feature would be particularly useful for users who maintain multiple patched images across several Docker Compose stacks.

For example, my environment includes images using tags such as:

• zoraxydocker/zoraxy:latest-patched
• ghcr.io/dispatcharr/dispatcharr:latest-patched
• quay.io/invidious/invidious:latest-patched
• deluan/navidrome:latest-patched

The image update checker currently skips these images because they are identified as local builds.

The main goal is to keep patched images up to date with both upstream application releases and available security fixes, without requiring manual intervention for every update.

The implementation should preserve compatibility with existing patched images and avoid assuming that every patched image follows the same naming convention. It should also distinguish between an upstream image update and a vulnerability patch to prevent unnecessary rebuilds.

Would you be willing to work on this feature?

• Yes, I'd like to implement this feature
• I could help with parts of this feature
• No, I'm just suggesting the feature

[lowlyocean]

@kmendell , would you consider prioritizing this feature? I think this is important for images that have large, infrequent releases (i.e. need to be patched frequently between releases, but you also don't want to miss the next release because you're pointing to a locally-built patch).