This is getting out of hand!

Now, there are two of them! 👽

9 minutes ago, gusdleon said:

This is getting out of hand!

Now, there are two of them! 👽

There has been two versions (stable and beta) since this was added to CA.

2 minutes ago, mstrhakr said:

There has been two versions (stable and beta) since this was added to CA.

I'm sorry I never noticed there was a beta release haha,
I thought it was a result of the problem with the blacklisting, and as the name of the beta version ends with ... I thought was a new release simply to fix that.

sorry.

and thanks for the plugin.

23 minutes ago, gusdleon said:

I'm sorry I never noticed there was a beta release haha,
I thought it was a result of the problem with the blacklisting, and as the name of the beta version ends with ... I thought was a new release simply to fix that.

sorry.

and thanks for the plugin.

OMG you are right, i will have to change it to (Beta) Compose Manager Plus or something. Thanks for pointing this out! It does have the big beta flag but still...

i keep trying to update my containers that are in the docker compose file and it keeps failing on containers i have removed

"=== Updating: Media Server ===

Pulling latest images...

service "sabnzbd" has neither an image nor a build context specified: invalid compose project

✗ Failed to pull images for media_server, update aborted

X Stack Media Server failed to updating (exit code: 1)

========================================

=== All operations complete ===

========================================"

1 hour ago, lordbeavis said:

i keep trying to update my containers that are in the docker compose file and it keeps failing on containers i have removed

"=== Updating: Media Server ===

Pulling latest images...

service "sabnzbd" has neither an image nor a build context specified: invalid compose project

✗ Failed to pull images for media_server, update aborted

X Stack Media Server failed to updating (exit code: 1)

========================================

=== All operations complete ===

========================================"

This is due an issue with how I was cleaning up orphaned services from the override (labels) file. A quick fix is to go to the stack settings, uncheck the box for Override File Management (set it to manual)

Once you save and then reopen the editor, you will be able to manually remove the sabnzbd entry from the override file.

Your other option is to update to the beta which includes the fixes for this as well as the ability to edit the override file manually more easily.

3 hours ago, mstrhakr said:

This is due an issue with how I was cleaning up orphaned services from the override (labels) file. A quick fix is to go to the stack settings, uncheck the box for Override File Management (set it to manual)

Once you save and then reopen the editor, you will be able to manually remove the sabnzbd entry from the override file.

Your other option is to update to the beta which includes the fixes for this as well as the ability to edit the override file manually more easily.

that did the trick. thanks

The compose manager's update detection compares the remote index manifest digest against the locally cached one, but this produces false positives when Docker Hub republishes an image with a new index manifest that points to the same underlying image layers. In this case, redis:8 and postgres:17 both received new index manifest SHAs 0a972391 and 2203e628 respectively) while the actual image content — the layer digest — remained identical 494dcdc6 for redis). A more accurate update check would compare the platform-specific image digest (the actual content hash) rather than the top-level index manifest digest, since only a change in the former represents real new content that warrants recreating a container.

I'm having (what I think) is an odd issue. The second and third container in a 3 container stack are getting "-1" appended to their name upon creation. There's no other containers with those names, so I can't figure out how to fix it. I've done a Compose Down, removed them manually, etc. and nothing - always created with "-1" at the end.

Any thoughts/ideas how to fix would be great. It's purely cosmetic, but it's annoying.

...I actually just realized it's adding the stack name to the beggining as well. So [stackname]-[container]-1. Not certain if that's a setting or what. The first container, which is the same name as the stack, does NOT do that.

Edited June 20Jun 20 by Necro

On 6/17/2026 at 7:03 PM, osamarao said:

The compose manager's update detection compares the remote index manifest digest against the locally cached one, but this produces false positives when Docker Hub republishes an image with a new index manifest that points to the same underlying image layers. In this case, redis:8 and postgres:17 both received new index manifest SHAs 0a972391 and 2203e628 respectively) while the actual image content — the layer digest — remained identical 494dcdc6 for redis). A more accurate update check would compare the platform-specific image digest (the actual content hash) rather than the top-level index manifest digest, since only a change in the former represents real new content that warrants recreating a container.

Thanks, this has been a pain point, I'll take another look into getting this perfected.

4 hours ago, Necro said:

I'm having (what I think) is an odd issue. The second and third container in a 3 container stack are getting "-1" appended to their name upon creation. There's no other containers with those names, so I can't figure out how to fix it. I've done a Compose Down, removed them manually, etc. and nothing - always created with "-1" at the end.

Any thoughts/ideas how to fix would be great. It's purely cosmetic, but it's annoying.

...I actually just realized it's adding the stack name to the beggining as well. So [stackname]-[container]-1. Not certain if that's a setting or what. The first container, which is the same name as the stack, does NOT do that.

Can you share your compose file? The container names are chosen by compose, not by Compose Manager. You can use container_name: to manually set the container name, or if you don't care and just need the hostname to be something specific you can use hostname:.

This is standard Docker Compose v2 naming rather than anything the plugin does — but there's an important catch about fixing it that's worth adding.

Compose names a container after its service's container_name: if set; otherwise it falls back to <project>-<service>-<n>, where <project> is the stack/project name and the trailing -1 is the replica ordinal Compose always appends. That's why your first container is clean — that service has an explicit container_name: (it happens to match the stack name) — while services 2 and 3 don't, so they get the <stack>-<service>-1 form. It's purely cosmetic; containers still reach each other by service name regardless.

The fix is to add container_name: to the other services:

  services:
    app:
      container_name: app
    db:
      container_name: app-db
    cache:
      container_name: app-cache

The catch:

adding container_name: to a stack that's already running will NOT rename the existing containers on a normal restart — or even on a Compose Update / force-recreate. Compose identifies an existing container by its internal labels (project + service), not by its name, so it keeps the old name when it recreates in place. To actually apply the new names you have to do a full Compose Down, then Compose Up, so the containers are removed and created fresh.

One more thing worth checking if a name ever looks "wrong" despite your file being correct: confirm which file actually created the container. docker inspect <container> --format '{{index .Config.Labels "com.docker.compose.project.config_files"}}' shows the exact compose file it came from. If that points somewhere other than the file you're editing (for example a stray docker-compose.yml sitting in a build-context directory), that other file is what's really launching the stack — and that mismatch, not the plugin, is the cause.

Edited June 21Jun 21 by Samsonight
typo

Well, that answered it. Thanks!