[Bug]: When changing docker image versions in Service Stacks (like Supabase), old versions are kept in the ui

[actraiser]

I installed the Supabase template some time ago and today in there updated a few image versions in the docker-file in the coolify ui. Everything works but the list of services still shows the old container versions in addition to the new ones with an "exited" status, e.g.

As you can see, the newer version of the service runs fine while the old version (which is not mentioned anywhere anymore in the docker-compose file) is still listed. When I try to stop and delete that older version of the service (clicking on "settings") - the delete dialog appears and I can submit the request (button gets disabled after click) but it runs forever and the popup will not disappear. The service will not be deleted.

Again, everything runs fine - it just looks strange to have "idling" entries in the service list in the UI. My question is, how to remove those (ghost?) entries from the list and if it should have been removed automatically in the first place. Thanks!

Greets
-act

[actraiser]

Just another note on this. This also leads to confusion when creating scheduled tasks since the old and new version of the service are both listed in the list of targets when creating a cronjob.

Is there another way to manually remove the service with the older image version that should not be part of the stack anymore?

Greets
-act

[actraiser]

I furter investigated and now do the following workaround to delete those old versions from the UI. This was done with my Supabase-Stack which uses the Service Template provided by Coolify.

Before you try, maybe one of the maintainers can clarify if this approach has side effects. @peaklabs-dev @andrasbacsai

First of all, for each image-version you update in a docker-file of a service stack, Coolify stores a row into the coolify-db, either into the table service_applications or service_databases, depending wether the changed service is a database or not. Coolify will not update rows, it will always add a new one, so you end up with multiple entries of the same service for the same service stack in the ui.

My workaround to remove idling older versions of the services after changing image-versions in docker-compose

1. ssh to your coolify instance
2. log into the coolify-db container

docker exec -it coolify-db bash 

3. connect to the coolify database

PGPASSWORD=$POSTGRES_PASSWORD psql -h $HOSTNAME -U $POSTGRES_USER -d $POSTGRES_DB

4. Find the id of the service stack that has "ghost" services and take note of the id

SELECT id, name FROM services;

6. use that service id to delete the applications and databases with duplicate names while keeping only the most recent ones

For Services:

WITH ranked_services AS (
  SELECT
    id,
    name,
    created_at,
    ROW_NUMBER() OVER (PARTITION BY name ORDER BY created_at DESC) AS row_num
  FROM
    service_applications
  WHERE
    service_id = <service_id>
)
DELETE FROM service_applications
WHERE id IN (
  SELECT id
  FROM ranked_services
  WHERE row_num > 1
);

for Databases:

WITH ranked_services AS (
  SELECT
    id,
    name,
    created_at,
    ROW_NUMBER() OVER (PARTITION BY name ORDER BY created_at DESC) AS row_num
  FROM
    service_databases
  WHERE
    service_id = <service_id>
)
DELETE FROM service_databases
WHERE id IN (
  SELECT id
  FROM ranked_services
  WHERE row_num > 1
);

in Coolify UI, the "ghost" applications/databases in that stack have disappeared now. I stop the stack, force-cleanup containers and restart the stack then.

If you have created custom scheduled tasks in the service stack, you need to check if they had targeted any of the updated services because in coolify, tasks are tied to service_ids and as we learned, for every new image version, coolify creates a new row in its database, so you eventually have to re-create tasks that pointed to a service you updated in docker-compose.

Greets
-act