[Feature Request] Poll container registry for new versions

[CraigBurden]

It would be great to have an optional background task per service that loops through each image referenced in the stack which polls the registry to see if the version that has been deployed is no longer the latest available on that tag. The application could additionally be configured to auto redeploy and pull the latest version when a new container is detected.

If auto deploy is not active for this, a notification or indication on the UI could be surfaced to give the user this information.

This is a great way to ensure that services are kept up to date, which may maintain security posture or make deployment simpler for some use-cases.

The feature could be configured per service/application with a cron style schedule, Coolify then hits the image manifest GET API and compares the image digest to the currently deployed version, if they mismatch, trigger the auto-deploy and/or notification depending on the configuration

[CraigBurden]

Here is a 100% vibe coded PoC that seems to work pretty well!
https://github.com/CraigBurden/coolify/tree/feat/image-update-checks

I'd be more than happy to open a PR if its up to scratch and folks agree that this is a worthy change.

Below is what Claude has to say for itself:

Scheduled image update checks for applications and services

Problem

Stacks that pull images from a registry (Docker Compose apps, one-click services, Docker image apps) have no way to tell when a newer image is published under the same tag, such as nginx:1.27-alpine or postgres:16. Users check by hand or redeploy blindly.

Proposal

Add an Image Updates page to each application and service (under Automation, next to Scheduled Tasks). It lists every registry image in the stack and lets you configure each image separately:

• Check schedule: a cron expression or hourly/daily/weekly/… in the server's timezone. Leave it empty to never check that image.
• When an update is found: Show a notice, Deploy automatically, or Deploy and show a notice.

Example: in a stack with three images, check A every hour and auto-deploy it, check B weekly and only notify, never check C.

When an update is found, an "Update available" chip appears next to the resource status, like the proxy update chip on servers. It links to the Image Updates page.

How it works

• Same tag only. It never moves to a newer tag. ${VAR} / ${VAR:-default} in image: are resolved from the resource's environment variables, the same way Docker Compose does it. Images pinned to a digest and services built from source are skipped.
• Runs on the server that hosts the resource, so the server's existing registry logins apply. It compares the digest of the image the running container uses (docker inspect → RepoDigests) with the registry digest for the tag (docker buildx imagetools inspect). Matching any platform manifest of a multi-arch tag counts as up to date.
• Scheduled like backups and scheduled tasks: a new type in ScheduledJobManager that uses the existing delivery ledger, so each occurrence runs once across nodes.
• Auto-deploy:
  • Queues a normal deployment for a compose application, or pulls and restarts only the affected part of a service.
  • Deploys at most once per new digest.
  • Skips resources that aren't running.
  • After a deploy or service start, pending images are checked again so the chip clears.
• The page shows the running digest, the registry digest, the last result or error, a Check now button, and a link to the image's registry page (Docker Hub, GHCR, Quay, ECR Public, MCR).
• Members can view the page; changing settings or running a check needs admin rights, as with the resource's other settings.

Out of scope for a first version (open to feedback)

• Notifications through Discord, email, etc. This would add an event to every notification channel.
• Showing the chip in project and resource lists.
• Moving to newer tags (semver bumps). That is a different feature.

Status

I have a working implementation with tests on a branch from feat/image-update-checks. I'm happy to open a PR if the approach fits the roadmap. AI tools helped with the implementation, and I have reviewed and tested it.