That was quick, thank you!That was quick, thank you!

3 hours ago, LAS said:

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]

Does the update complete if you check run in background? That will tell us if the command is correct or not. Then I can check just the ttyd path. Do you have another ttyd window open, like a log window?

2 hours ago, mstrhakr said:

Does the update complete if you check run in background? That will tell us if the command is correct or not. Then I can check just the ttyd path. Do you have another ttyd window open, like a log window?

After some brief testing, when a compose log window is open, and you run update (likely other options also) it takes over the log window and the popup is left empty. It runs the update in the existing new tab log window and does nothing with the popup ttyd. I will be looking into this, expect the fix to land in the beta first. The workaround is to ensure log windows are closed before performing actions or use run in background and grab the output after.

It would be nice support for global ENV file with custom path

3 minutes ago, L0rdRaiden said:

It would be nice support for global ENV file with custom path

I can look into this, please open an issue on GitHub if you want me to actually remember lmao

20 hours ago, mstrhakr said:

After some brief testing, when a compose log window is open, and you run update (likely other options also) it takes over the log window and the popup is left empty. It runs the update in the existing new tab log window and does nothing with the popup ttyd. I will be looking into this, expect the fix to land in the beta first. The workaround is to ensure log windows are closed before performing actions or use run in background and grab the output after.

No log windows open, I had an open ssh session though, but closing it did nothing.

8 hours ago, LAS said:

No log windows open, I had an open ssh session though, but closing it did nothing.

Was this a one off issue or something you can consistently reproduce? What version were you on when you experienced this issue? I have fixed the issue I spoke about above and will be pushing it to the beta soon.

On 4/14/2026 at 1:59 PM, L0rdRaiden said:

It would be nice support for global ENV file with custom path

I opened an issue on GitHub for this, this seems like it is worth doing but I have to look into it first of course.
https://github.com/mstrhakr/compose_plugin/issues/98

16 hours ago, mstrhakr said:

Was this a one off issue or something you can consistently reproduce? What version were you on when you experienced this issue? I have fixed the issue I spoke about above and will be pushing it to the beta soon.

I'm on v5.0.2

I had 4 stacks needing update, it happened on all of them. Manually updated one of them via docker compose pull -> down -> up -d

I've not found a way to get it to update in foreground, but Run in background seems to be working reliably.

I've not attempted rebooting, as this is my this-should-always-stay-on server.

I recently removed that 5.0.2 from the title bar as that is actually the Compose CLI version, not the plugin version. You can find the plugin version on the plugin tab if you are on stable, and in the beta I've moved both the plugin version and the Compose CLI version to the settings->credits page.

Is this only happening for update, or do all foreground actions have the same problem?

16 hours ago, mstrhakr said:

I recently removed that 5.0.2 from the title bar as that is actually the Compose CLI version, not the plugin version. You can find the plugin version on the plugin tab if you are on stable, and in the beta I've moved both the plugin version and the Compose CLI version to the settings->credits page.

Is this only happening for update, or do all foreground actions have the same problem?

2026.04.10

Compose Down, Compose Stop, Compose Restart, Force Update all does this. Did not test Compose Up, but I can only assume it does for this as well.

Check for Updates, Edit Stack, View Logs, View Last Cmd Log working, but those don't spawn a (visible atleast) terminal.

Syslog:

Apr 17 08:32:15 smart compose.manager: [hookLoadlist]  hooked loadlist() for cross-widget sync, tabbed=false
Apr 17 08:32:15 smart compose.manager: [dockerload] initializing subscriber, composeListReady=false
Apr 17 08:32:16 smart compose.manager: [Updates] Last check was 3 minutes ago, interval is 4320 minutes. Skipping.
Apr 17 08:32:20 smart compose.manager: setStackActionInProgress - Data: {"stack":"apipoo","inProgress":true,"text":"updating..."}
Apr 17 08:32:21 smart compose.manager: processPendingComposeReloads - Data: {"stacks":["apipoo"]}
Apr 17 08:32:21 smart compose.manager: [refreshStackRow] response - Data:
Apr 17 08:32:21 smart compose.manager: {"project":"apipoo","data":"{\"result\":\"success\",\"containers\":[{\"name\":\"apipoo\",\"id\":\"328b49acaea9ad668640241b881cc9f073b692b6a7ffe038e26e757bc4fae102\",\"service\":\"apipoo\",\"image\":\"apipoo-apipoo\",\"state\":\"running\",\"isRunning\":true,\"hasUpdate\":false,\"updateStatus\":\"unknown\",\"localSha\":\"\",\"remoteSha\":\"\",\"isPinned\":false,\"pinnedDigest\":null,\"icon\":\"https:\\/\\/<redacted>\\/static\\/images\\/apipoo9_512.png\",\"shell\":\"\",\"webUI\":\"https:\\/\\/<redacted>\",\"ports\":[\"192.168.50.34:5510->5010\\/tcp\"],\"networks\":[{\"name\":\"apipoo_default\",\"ip\":\"172.22.0.2\",\"driver\":\"bridge\"}],\"volumes\":[{\"source\":\"\\/mnt\\/disk1\\/appdata\\/apipoo\\/stock.db\",\"destination\":\"\\/app\\/stock.db\",\"type\":\"bind\"},{\"source\":\"\\/etc\\/localtime\",\"destination\":\"\\/etc\\/localtime\",\"type\":\"bind\"}],\"created\":\"2026-04-02T14:31:46.529499484Z\",\"startedAt\":\"2026-04-02T14:32:08.743673699Z\"},{\"name\":\"ofelia\",\"id\":\"8c26369266ce9e379a7ff24a
Apr 17 08:32:22 smart compose.manager: Deferring pending update check while action is in progress - Data: {"stack":"apipoo"}
Apr 17 08:37:06 smart compose.manager: [hookLoadlist]  hooked loadlist() for cross-widget sync, tabbed=false
Apr 17 08:37:06 smart compose.manager: [dockerload] initializing subscriber, composeListReady=false
Apr 17 08:37:06 smart compose.manager: checkPendingRechecks:found - Data: {"pendingStacks":["apipoo"]}
Apr 17 08:37:06 smart compose.manager: Running recheck for recently updated stack: - Data: {"stackName":"apipoo"}

Found the culprit though, and this is a real edge-case, that you might even don't need to worry about.

I append to .bash_profile on boot with if [ -d /mnt/user/appdata/zsh/.oh-my-zsh ]; then if [ -x /bin/zsh ]; then /bin/zsh; exit; fi fi in order to have zsh as my shell, and $innerCmd = "bash -lc " . escapeshellarg($scriptCmd); (compose_util_functions.php) pick up and execute this.

I've added [[ $- == i ]] and everything now works as it should.

I guess if you want to avoid user customizations you could do --noprofile --norc then load a controlled env, but I wouldn't worry too much about it.

4 hours ago, LAS said:

2026.04.10

Compose Down, Compose Stop, Compose Restart, Force Update all does this. Did not test Compose Up, but I can only assume it does for this as well.

Check for Updates, Edit Stack, View Logs, View Last Cmd Log working, but those don't spawn a (visible atleast) terminal.

Syslog:

Apr 17 08:32:15 smart compose.manager: [hookLoadlist]  hooked loadlist() for cross-widget sync, tabbed=false
Apr 17 08:32:15 smart compose.manager: [dockerload] initializing subscriber, composeListReady=false
Apr 17 08:32:16 smart compose.manager: [Updates] Last check was 3 minutes ago, interval is 4320 minutes. Skipping.
Apr 17 08:32:20 smart compose.manager: setStackActionInProgress - Data: {"stack":"apipoo","inProgress":true,"text":"updating..."}
Apr 17 08:32:21 smart compose.manager: processPendingComposeReloads - Data: {"stacks":["apipoo"]}
Apr 17 08:32:21 smart compose.manager: [refreshStackRow] response - Data:
Apr 17 08:32:21 smart compose.manager: {"project":"apipoo","data":"{\"result\":\"success\",\"containers\":[{\"name\":\"apipoo\",\"id\":\"328b49acaea9ad668640241b881cc9f073b692b6a7ffe038e26e757bc4fae102\",\"service\":\"apipoo\",\"image\":\"apipoo-apipoo\",\"state\":\"running\",\"isRunning\":true,\"hasUpdate\":false,\"updateStatus\":\"unknown\",\"localSha\":\"\",\"remoteSha\":\"\",\"isPinned\":false,\"pinnedDigest\":null,\"icon\":\"https:\\/\\/<redacted>\\/static\\/images\\/apipoo9_512.png\",\"shell\":\"\",\"webUI\":\"https:\\/\\/<redacted>\",\"ports\":[\"192.168.50.34:5510->5010\\/tcp\"],\"networks\":[{\"name\":\"apipoo_default\",\"ip\":\"172.22.0.2\",\"driver\":\"bridge\"}],\"volumes\":[{\"source\":\"\\/mnt\\/disk1\\/appdata\\/apipoo\\/stock.db\",\"destination\":\"\\/app\\/stock.db\",\"type\":\"bind\"},{\"source\":\"\\/etc\\/localtime\",\"destination\":\"\\/etc\\/localtime\",\"type\":\"bind\"}],\"created\":\"2026-04-02T14:31:46.529499484Z\",\"startedAt\":\"2026-04-02T14:32:08.743673699Z\"},{\"name\":\"ofelia\",\"id\":\"8c26369266ce9e379a7ff24a
Apr 17 08:32:22 smart compose.manager: Deferring pending update check while action is in progress - Data: {"stack":"apipoo"}
Apr 17 08:37:06 smart compose.manager: [hookLoadlist]  hooked loadlist() for cross-widget sync, tabbed=false
Apr 17 08:37:06 smart compose.manager: [dockerload] initializing subscriber, composeListReady=false
Apr 17 08:37:06 smart compose.manager: checkPendingRechecks:found - Data: {"pendingStacks":["apipoo"]}
Apr 17 08:37:06 smart compose.manager: Running recheck for recently updated stack: - Data: {"stackName":"apipoo"}

Found the culprit though, and this is a real edge-case, that you might even don't need to worry about.

I append to .bash_profile on boot with if [ -d /mnt/user/appdata/zsh/.oh-my-zsh ]; then if [ -x /bin/zsh ]; then /bin/zsh; exit; fi fi in order to have zsh as my shell, and $innerCmd = "bash -lc " . escapeshellarg($scriptCmd); (compose_util_functions.php) pick up and execute this.

I've added [[ $- == i ]] and everything now works as it should.

I guess if you want to avoid user customizations you could do --noprofile --norc then load a controlled env, but I wouldn't worry too much about it.

Thank you for letting me know, I will look into this.

PLEASE (PLEASE!) can we have Compose Manager actually delete directories under /boot/config/plugins/compose.manager/projects/ when you delete a stack?

If I see another stack get "003" in its name I'm going to lose it.

I'd also like to be able to create stacks without setting their names or descriptions - my compose file already includes that information and it's not for the user to decide when I'm shipping a pre-made stack.

I'd also like the ability to set compose and env via URL instead of pasting - including the ability to just paste a single GitHub URL to grab both at once.

I'd also break with Unraid's convention of using the "DONE" button and relabel that button on the bring-up window "CANCEL" if you can't close the window without stopping the process.

Anyone involved in Unraid web design: DONE does not mean what you think it means and CANCEL buttons shouldn't be named "DONE" all over the UI.

Edited April 21Apr 21 by Espressomatic

4 minutes ago, Espressomatic said:

PLEASE (PLEASE!) can we have Compose Manager actually delete directories under /boot/config/plugins/compose.manager/projects/ when you delete a stack?

If I see another stack get "003" in its name I'm going to lose it.

I'd also like to be able to create stacks without setting their names or descriptions - my compose file already includes that information and it's not for the user to decide when I'm shipping a pre-made stack.

Deleting project folder should be happening unless its an external stack. I've added some additional failure handling to the dev branch (will be in beta soonish) to help if this is still happening.

Creating a stack without a name doesn't work as that is how the folder is created. Currently only the name is required, description can always be skipped/left blank.

1 hour ago, Espressomatic said:

I'd also break with Unraid's convention of using the "DONE" button and relabel that button on the bring-up window "CANCEL" if you can't close the window without stopping the process.

yea, i have to figure out how to deal with this as its in an Iframe and i have limited control over it. i'm sure its possible but I havent looked at it yet. Should show done once the script is finished. I also want to add a setting to run an action without -d and the button would say detach in that case.

One more when you get the chance... Don't let modals get longer than the viewport - controls are pushed beyond the visible display frame when I'm running on anything but my 32" display.

29 minutes ago, mstrhakr said:

Creating a stack without a name doesn't work as that is how the folder is created.

I get that's the way it works now. What I'm suggesting is allowing the compose or a template to be added first, and that determines the project name. Like with Unraid's container-based template docker support. Or Portainer's templates.

2 minutes ago, Espressomatic said:

I get that's the way it works now. What I'm suggesting is allowing the compose or a template to be added first, and that determines the project name. Like with Unraid's container-based template docker support. Or Portainer's templates.

So basically skip the new stack modal and just open the editor when adding a new stack, then automatically use the compose files project name as display name and folder name if not provided. That actually seems like a better UX than enter name, but makes it harder to do the external stack, albeit not by enough to matter.

6 minutes ago, Espressomatic said:

One more when you get the chance... Don't let modals get longer than the viewport - controls are pushed beyond the visible display frame when I'm running on anything but my 32" display.

Yea... There are a couple places that need fixed, the containers list just needs to be made scrollable. I'll fix this real quick in the dev branch, then I will push new beta later today with this fix.

If you are willing, GitHub issues are always preferred for tracking these bugs and fixes. Things that aren't an Issue in GitHub might be missed or forgotten about.

3 minutes ago, mstrhakr said:

If you are willing, GitHub issues are always preferred for tracking these bugs and fixes. Things that aren't an Issue in GitHub might be missed or forgotten about.

For sure. I hadn't seen a git hub link, but I'll go there as I'm sure I'll have a number of others to post.

Just now, Espressomatic said:

For sure. I hadn't seen a git hub link, but I'll go there as I'm sure I'll have a number of others to post.

Thanks, If anything is breaking on main I can do a hotfix, otherwise it goes in the beta first, then pushed to main as a whole after lots of testing and some time for users to report things. Bugs still always make it through to the stable branch inevitably.

1 minute ago, Espressomatic said:

For sure. I hadn't seen a git hub link, but I'll go there as I'm sure I'll have a number of others to post.

https://github.com/mstrhakr/compose_plugin

Hi, I run a single stack using this plugin with two versions of the monica container, and the stack seems to permanently show 'update available' even after I click the option to update (it says I need to update 7d55a04b to 23174c71). Is there a way I can manually force it to update using command line or check that it isn't already on the latest version? Thanks

6 minutes ago, rama3124 said:

Hi, I run a single stack using this plugin with two versions of the monica container, and the stack seems to permanently show 'update available' even after I click the option to update (it says I need to update 7d55a04b to 23174c71). Is there a way I can manually force it to update using command line or check that it isn't already on the latest version? Thanks

It's possible this is a bug in docker manager, the fix is in Unraid 7.3. I had a similar issue with a WordPress container and this pull request below is what fixed it.

https://github.com/unraid/webgui/pull/2581