I had a quick question i just updated to the new manager plus,
But how do i delete old stacks that i dont need anymore i cant find that option

On 3/30/2026 at 1:49 PM, mstrhakr said:

I have not experienced this as I don't have any stacks setup this way. Could you provide a sanitized version of that setup so I can try it out and make sure it works?

I am sorry for my late reply, I hope I am able to provide the stack at the weekend.

But it basically is the Docker-Compose setup as written in the official Immich Unraid Installation doc.

1 hour ago, powerbike2 said:

I am sorry for my late reply, I hope I am able to provide the stack at the weekend.

But it basically is the Docker-Compose setup as written in the official Immich Unraid Installation doc.

...
https://github.com/bmartino1/unraid-docker-templates/blob/main/Guides/Compose/Immich/ImmichReadme.md

Brandon Martino - Personal Site

Immich-on-Unraid-Docker-Compose-Guide

Brandon Martino - Personal Site

...

9 hours ago, TheSaviour01 said:

I had a quick question i just updated to the new manager plus,
But how do i delete old stacks that i dont need anymore i cant find that option

Delete is in the context menu at the bottom, on stable click the stack icon to open the Up/Down/Etc context menu, on the beta, you can right click anywhere on the stack row for this menu.

Edited April 2Apr 2 by mstrhakr
Fix quote

1 hour ago, powerbike2 said:

I am sorry for my late reply, I hope I am able to provide the stack at the weekend.

But it basically is the Docker-Compose setup as written in the official Immich Unraid Installation doc.

Okay, I will try setting this up this weekend to see if I can experience the same bug.

23 hours ago, TheSaviour01 said:

But how do i delete old stacks that i dont need anymore i cant find that option

?

Can you add the ability to re-order stacks? visually I like things in a certain order.

1 hour ago, Jonza said:

Can you add the ability to re-order stacks? visually I like things in a certain order.

Its on my to-do list, it will likely be in the next beta in the next few weeks. Comment on or like the GitHub issue for that feature request to show me which ones are important to you guys.

On 3/31/2026 at 12:17 AM, mstrhakr said:

I like this, especially for the backup/sync. If we have a project level repo how to we deal with individual compose from a separate repo? I know some software like Komodo support individual git based compose files/setups, is there a standard way to do this? Maybe we could force git based in another folder, and allow using git for main project folder as a separate thing? I have to think about it. If anyone has a good idea let me know. I'm interested for sure though.

Sorry for the late reply. In my use case, I configured Compose Manager to use a dedicated share (/mnt/user/docker) for storing stacks. In this setup, .git can be in the same location; however, it's not feasible in the default configuration. I don't think that a separate repo for every stack would be required; one main repo should be sufficient (at least for my use case). Ideally, every change in a stack would create and push a new commit, as I often tinker with Compose files and sometimes I lose track of what changes I made in case of issues. Pulling changes from Git automatically would be great, but I'm afraid it would be very complex to implement.

In the latest version, 2026.03.28, my immich stack suddenly appears as stopped with no containers. However, immich is clearly actively running as I can access it. I upgraded from the previous plugin to Compose Manager Plus a couple versions prior to 2026.03.28, and it showed the stack fine. Since it's detected as "stopped", I cannot send a stop command through the plugin, and if I send a start command, it fails because the stack is already running. I'm hesitant to try the beta to see if it fixes this unless someone can confirm that it does.

There is also an update to immich, so I tried the plugin button "check updates", which said there were no updates. I was able to click on the stack icon for immich and click check for updates, which it found that way. When I try to do the update, I run into the same issue that starting the stack, which is already running, has, which is the following error: Error response from daemon: Conflict. The container name "/immich_redis" is already in use by container "34381196eaf6025ce55cd4adfc4ccd9386a532cd6f52c83edffa210dd4a5380b". You have to remove (or rename) that container to be able to reuse that name.

Edited April 7Apr 7 by arcmodo
Add additional info about attempting to update the stack

2 hours ago, arcmodo said:

There is also an update to immich, so I tried the plugin button "check updates", which said there were no updates. I was able to click on the stack icon for immich and click check for updates, which it found that way. When I try to do the update, I run into the same issue that starting the stack, which is already running, has, which is the following error: Error response from daemon: Conflict. The container name "/immich_redis" is already in use by container "34381196eaf6025ce55cd4adfc4ccd9386a532cd6f52c83edffa210dd4a5380b". You have to remove (or rename) that container to be able to reuse that name.

This is likely a project name mismatch that didn't cause UI issues until this last update.

If you run docker inspect immich_redis --format '{{ index .Config.Labels "com.docker.compose.project" }}' from the unraid terminal what does it give?

Also what is your folder and display name set to?

Once you run that command you can go to your project folder cd /boot/plugins/compose.manager/projects/[your immich project] then docker compose down -p [project name from first command].

Once that's done, the UI should stay in sync as it now uses the same project sanitizing function in the front end and back end.

On 4/5/2026 at 8:39 AM, bane said:

Sorry for the late reply. In my use case, I configured Compose Manager to use a dedicated share (/mnt/user/docker) for storing stacks. In this setup, .git can be in the same location; however, it's not feasible in the default configuration. I don't think that a separate repo for every stack would be required; one main repo should be sufficient (at least for my use case). Ideally, every change in a stack would create and push a new commit, as I often tinker with Compose files and sometimes I lose track of what changes I made in case of issues. Pulling changes from Git automatically would be great, but I'm afraid it would be very complex to implement.

I can see this working, but I don't see a good way to do this AND allow users to have a git based single stack. This second use case is far more common as evidenced by all the major players offering it as an option (eg. komodo and the like). So with that said I likely will not be implementing this but there is now an open issue on GitHub you can comment on to show support.

1 hour ago, mstrhakr said:

I can see this working, but I don't see a good way to do this AND allow users to have a git based single stack. This second use case is far more common as evidenced by all the major players offering it as an option (eg. komodo and the like). So with that said I likely will not be implementing this but there is now an open issue on GitHub you can comment on to show support.

by default, the URaid of the Docker system allows us to set a location where the Docker appdata folder is. The default unraid option is folder "/mnt/user/appdata/"

Example Docker edit

By default, with this plugin the data is found under advanced:

so I can see a Default master control setting. that sets the default Docker Compose stacks following the Unraid Docker setting.
as by default the plugin saves them on the flash drive..

so the default stack location is located at:
"/boot/config/plugins/compose.manager/projects"

If I'm understanding the git clone and add to stack. These are the things that already exist that can be edited to fit the need.
? so the questioning then becomes how do you want to handle input of a stak project that can be git cloned and detected if any.

some compose and projects require data and a setup script run to prebuild to your env...

So I'm not sure a transition plan to add a git pull project into this plugin is in the making or works. But my understanding of the user's questions where the stack data is located is based on the settings of that stack or the project location which already have a set place and are editable.

Edited April 7Apr 7 by bmartino1
data - typo

16 hours ago, bmartino1 said:

by default, the URaid of the Docker system allows us to set a location where the Docker appdata folder is. The default unraid option is folder "/mnt/user/appdata/"

Example Docker edit

By default, with this plugin the data is found under advanced:

so I can see a Default master control setting. that sets the default Docker Compose stacks following the Unraid Docker setting.
as by default the plugin saves them on the flash drive..

so the default stack location is located at:
"/boot/config/plugins/compose.manager/projects"

If I'm understanding the git clone and add to stack. These are the things that already exist that can be edited to fit the need.
? so the questioning then becomes how do you want to handle input of a stak project that can be git cloned and detected if any.

some compose and projects require data and a setup script run to prebuild to your env...

So I'm not sure a transition plan to add a git pull project into this plugin is in the making or works. But my understanding of the user's questions where the stack data is located is based on the settings of that stack or the project location which already have a set place and are editable.

I found the above post very confusing so just in case others are unclear about the git features being discussed let me provide a breakdown based on my understanding.
Essentially there are 3 potential interrelated designs/use cases being discussed.

1. Using git to clone existing stacks from github. There are a number of apps out there that recommend compose as the installation method and provide a recommended setup in their git repo. Their instructions for use are essentially clone the repo, add a couple of .env files based on their examples, and then run compose up at the root of the repo. Support for these repos is something that was asked for, and i considered supporting the in the original compose plugin. I eventually decided not to support it for a few reasons. Firstly I did not want to encourage users to pull compose stacks from random sources without understanding how they work. Secondly the kind of apps that I saw recommending this installation method were typically quite complex with multiple (linked or override) compose files, build directories, and environment files. That kind of complexity was not something I intended to support via the ui, which was designed for 1 compose file, 1 env file. Additionally i didnt want to invite the support requests that would come with people trying to use complex stacks that they didnt fully understand.

2. Using per stack git repos to control changes made through the ui. With this idea essentially each stack directory created with the plugin would be a git repo. Every time the user modified the stack via the webui it would make a commit to the repo to allow users to track their changes to the stack and roll back. While very useful for some this could add considerable complexity to the plugin. Also this invites some of the same usage pattern as #1. Personally I wouldnt use the feature as i store my stack in a snapshotted btrfs share.

3. Tracking the top level compose manager projects directory as a git repo. This has the same basic benefit as #2 with slightly simpler management on the plugin side, but potentially more edge cases involving stacks not stored in the projects directory. This could allow for a more granular form of the backup/restore already in this plugin. If combined with #1 it would add considerable complexity with nested git repos.

As a side note one point to consider with all of these git based features is the potential for accidentally enabling security issues. With git repos the natural instinct is to mirror them to github as an offsite backup. Of course with compose stacks there is potential for sensitive keys, passwords, urls, etc. being stored along with the stack (not best practice but common and likely not understood by many unfamiliar with the technology like new unraid users). Making it to easy to push personal compose stacks to a public git repo may unintendedly encourage users to make poor security decisions.

6 minutes ago, primeval_god said:

I found the above post very confusing so just in case others are unclear about the git features being discussed let me provide a breakdown based on my understanding.
Essentially there are 3 potential interrelated designs/use cases being discussed.

1. Using git to clone existing stacks from github. There are a number of apps out there that recommend compose as the installation method and provide a recommended setup in their git repo. Their instructions for use are essentially clone the repo, add a couple of .env files based on their examples, and then run compose up at the root of the repo. Support for these repos is something that was asked for, and i considered supporting the in the original compose plugin. I eventually decided not to support it for a few reasons. Firstly I did not want to encourage users to pull compose stacks from random sources without understanding how they work. Secondly the kind of apps that I saw recommending this installation method were typically quite complex with multiple (linked or override) compose files, build directories, and environment files. That kind of complexity was not something I intended to support via the ui, which was designed for 1 compose file, 1 env file. Additionally i didnt want to invite the support requests that would come with people trying to use complex stacks that they didnt fully understand.

2. Using per stack git repos to control changes made through the ui. With this idea essentially each stack directory created with the plugin would be a git repo. Every time the user modified the stack via the webui it would make a commit to the repo to allow users to track their changes to the stack and roll back. While very useful for some this could add considerable complexity to the plugin. Also this invites some of the same usage pattern as #1. Personally I wouldnt use the feature as i store my stack in a snapshotted btrfs share.

3. Tracking the top level compose manager projects directory as a git repo. This has the same basic benefit as #2 with slightly simpler management on the plugin side, but potentially more edge cases involving stacks not stored in the projects directory. This could allow for a more granular form of the backup/restore already in this plugin. If combined with #1 it would add considerable complexity with nested git repos.

As a side note one point to consider with all of these git based features is the potential for accidentally enabling security issues. With git repos the natural instinct is to mirror them to github as an offsite backup. Of course with compose stacks there is potential for sensitive keys, passwords, urls, etc. being stored along with the stack (not best practice but common and likely not understood by many unfamiliar with the technology like new unraid users). Making it to easy to push personal compose stacks to a public git repo may unintendedly encourage users to make poor security decisions.

You explained that all really well, thank you. I agree with all of it. My focus is on option 1 as I find options 2 and 3 to be way too much for this plugin. I can see option 1 working as an advanced feature or something but you make a lot of good points on the complexity of this. I especially appreciate the comments about frivolous support requests from uneducated users, as it seems that will be a problem forever with unraid. Seems like unraid attracts beginners, which isn't an issue, just something to be aware of. So I'll say it again, thanks for posting your thoughts on this, it is very appreciated. I'll have to think about it, I think limiting it to clone/pull only might work, but it still doesn't seem that needed when you can (for most compose files) just paste it into the editor. The advanced users could still do a git based stack manually so maybe we just leave it at that.

As an aside I had always hoped that the need/want to pull stacks from github would become irrelevant. I had hoped that at some point my plugin would be superseded by Limetech re-writing dockerman to use compose files instead of their custom xml format (and making use of labels for storing and finding custom metadata about containers). Then compose stacks could become the standard for community supported docker apps and there would be less need to pull third party stacks not designed with the unraid use case in mind. Less need for the beginner and intermediate user that is. Dont get me wrong, I am glad to see you pickup the torch of compose.manager and I am very impressed with the changes your are making. I just always hoped that Limetech would see the light and move away from their custom docker tooling (though to be fair they put a lot of effort into dockerman as it is now and I believe it predates the industry standardization on compose).

Edited April 8Apr 8 by primeval_god

11 minutes ago, primeval_god said:

As an aside I had always hoped that the need/want to pull stacks from github would become irrelevant. I had hoped that at some point my plugin would be superseded by Limetech re-writing dockerman to use compose files instead of their custom xml format (and making use of labels as storing and finding custom metadata about containers). Then compose stacks could become the standard for community supported docker apps and there would be less need to pull third party stacks not designed with the unraid use case in mind. Less need for the beginner and intermediate user that is. Dont get me wrong, I am glad to see you pickup the torch of compose.manager and I am very impressed with the changes your are making. I just always hoped that unRAID would see the light and move away from their custom docker tooling (though to be fair they put a lot of effort into dockerman as it is now and I believe it predates the standardization on compose).

Funny you say that because I was recently pondering how one would create an XML based template for compose stacks to be able to pull them from the app store. But a merge/unification of docker+compose actually makes more sense than trying to fit this square peg of compose in the round hole of the CA App store. Until the day that happens or Limetech integrates this plugin, I will continue to try to improve this to meet the standards of integration. I always try to compare new features and improvements against what I think Limetech would want/do if this were integrated, like WWJD but instead its WWLTD lol.

19 hours ago, mstrhakr said:

I can see this working, but I don't see a good way to do this AND allow users to have a git based single stack. This second use case is far more common as evidenced by all the major players offering it as an option (eg. komodo and the like). So with that said I likely will not be implementing this but there is now an open issue on GitHub you can comment on to show support.

Okay no problem, I understand it's a lot of complexity for the plugin. Maybe adding option to run custom user scripts on event (like saving stack) would be great compromise. User (or other plugin) could deal with Git integration or other backup system

I've been thinking about the custom start script, but I haven't heard anyone ask for custom scripts based on specific actions. Would you mind explaining your use case for me so I have a better understanding?

Edited April 9Apr 9 by mstrhakr

I've been using the plugin for a few days, but I don't understand why it shows an update every time [Plugin] CA Application Auto Update checks.

In the Compose Manager Plus plugin the option is disabled

in CA Application Auto Update the option to update containers is enabled but it only does it with a new version!

38 minutes ago, chitalov said:

I don't understand why it shows an update every time [Plugin] CA Application Auto Update checks

An update for what? The plugin itself? You showed your autoupdate settings for containers but not for plugins.

14 hours ago, Kilrah said:

An update for what? The plugin itself? You showed your autoupdate settings for containers but not for plugins.

I only have one stack with one container and I'm getting a notification that it has been updated.

6 hours ago, chitalov said:

I only have one stack with one container and I'm getting a notification that it has been updated.

This is a bug in CA Auto Update, it doesn't check the net.unraid.docker.managed label for dockerman, I'm looking into doing a PR on this but I need to validate this deeper into the docker.manager (built-in) plugin also. Basically at first glance, its checking ALL containers, regardless of the manger, so looking at the code its likely trying to update all 3rd party containers, not just compose managed ones. This would likely affect things like the Nextcloud All-In-One container that manages its own sub-containers. Anyone that knows more feel free to correct me. Easiest fix is to change it to only update the containers you want updated, instead of selecting update all.

I submitted a PR here https://github.com/Squidly271/ca.update.applications/pull/2 pending Squid seeing it and merging or not.

I have a weird issue where when I I click update, I'm left with a non-interactive terminal window at ~/

Running docker compose pull from the project dir successfully pulls the update, and down and up -d works as intended.

I do have a custom .zshrc loaded at server start, with some vars set, but this shouldn't really interfere.

I see mentions above to cd /boot/plugins/compose.manager/projects/[your immich project]

I assume this is a typo, as projects are in /boot/config/plugins/compose.manager/projects/[your immich project]