Is there any way to configure an update check more frequently than once per day? I would like to automate some deployments and I'd like to be able to have the plugin check for updates every 5-15 minutes. Is that possible and/or create some resource issues?

After the latest update, when using the option "Force Updated & Rebuild" on a local stack with a single container, I'm getting this error:

Error response from daemon: pull access denied for container xyz, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

That option worked perfectly before the update, allowing me to change local files then rebuild the container with those changes.

If I add pull_policy: never to the yml, the Force Update & Rebuild is immediate. I see this:

using .env: /mnt/user/appdata/container xyz/.env
Pulling latest images...
[+] pull 1/1
✔ Image minitarr:latest Skipped 0.0s

Recreating containers...
[+] up 1/1
✔ Container xyz Running

But the container isn't rebuilt. It's just restarted.

If I compose down then build and up, that approach works - the container is updated as expected.

Would you mind taking a look please?

EDIT: I tried checking this on the stack settings, to no avail.
Rebuild Images on UpdateAdd --build to docker compose up when updating

If I click save, and Okay, the checkbox doesn't stay saved when heading back into the settings.

I get the same logs as above when Force Update & Rebuild is clicked.

Edited September 15Sep 15 by Raboon
adding the log after adding pull_policy: never

13 minutes ago, Raboon said:

If I compose down then build and up, that approach works - the container is updated as expected.

if you do that without deleting the image manually between the down and up it will NOT be updated, it'll just reuse the image that's already there.

I.e. the problem seems to be what it says, the registry you tried to pull denied you access, that's what you need to investigate. Maybe the author removed or moved the repo, or privated it, or you exhausted your 100 unauthenticated requests per 6 hours to dockerhub etc.

Edited September 15Sep 15 by Kilrah

Thanks for the quick support.
It's a local build folder that's available.

and true, I did click "remove orphans' When clicking compose down so that flow is working as you expect.

Update:

My yml looked like this:

build: .

image: container_xyz:latest

container_name: container_xyz

Swapping to this:

build:

context: /mnt/user/appdata/container_xyz/Build/

dockerfile: Dockerfile

container_name: container_xyz

Correction: Force Update & Rebuild still doesn't work

In the plugin settings, selecting "Rebuild Images on Update by Default" works.

Edit Stack / Settings / "Add --build to docker compose up when updating" doesn't save when selected.

Am I missing a trick? I would rather apply it at an individual level than use the master toggle.

Edited September 16Sep 16 by Raboon
added compose down comment

On 9/15/2026 at 11:36 PM, Raboon said:

After the latest update, when using the option "Force Updated & Rebuild" on a local stack with a single container, I'm getting this error:

Error response from daemon: pull access denied for container xyz, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

That option worked perfectly before the update, allowing me to change local files then rebuild the container with those changes.

If I add pull_policy: never to the yml, the Force Update & Rebuild is immediate. I see this:

using .env: /mnt/user/appdata/container xyz/.env
Pulling latest images...
[+] pull 1/1
✔ Image minitarr:latest Skipped 0.0s

Recreating containers...
[+] up 1/1
✔ Container xyz Running

But the container isn't rebuilt. It's just restarted.

If I compose down then build and up, that approach works - the container is updated as expected.

Would you mind taking a look please?

EDIT: I tried checking this on the stack settings, to no avail.
Rebuild Images on UpdateAdd --build to docker compose up when updating

If I click save, and Okay, the checkbox doesn't stay saved when heading back into the settings.

I get the same logs as above when Force Update & Rebuild is clicked.

I got the exact same issue, local stack is not getting rebuild.
And applying "Add --build to docker compose up when updating" does not save when selected and applied.

This is what I get when I press build

using .env: /mnt/cachetwo/appdata/xyz//.env
[+] pull 1/1
✔ xyz Skipped No image to be pulled 0.0s

✓ Images pulled successfully for xyz

@mstrhakr

Hi, I was thinking about doing a contribution to your project by developing a secret management feature for Compose Manager Plus.

The idea would be to allow Compose stacks to use secrets without storing the actual values in .env files or Compose files. Secrets would be resolved only when the stack is deployed, while keeping the Compose files portable and compatible with standard Docker Compose.

I see two possible approaches:

Option 1 — Build it directly into Compose Manager Plus

Develop the secret management functionality natively, with the first backend being SOPS + age.

The plugin would resolve the secrets before running docker compose, inject them at runtime, and keep the secret values out of the repository and .env files.

Scope would include:

• Secret provider abstraction

• SOPS + age integration

• Per-stack secret configuration

• Runtime secret injection

• Secure handling/cleanup

• UI for configuring the secret source

The main advantage is that Compose Manager Plus would be fully self-contained and would not require another service to be running.
The native approach could also be designed around a provider abstraction, making it possible to add Bitwarden and other secret backends later, or use them as alternative/fallback providers without changing the Compose files. Similar to what dockhand does.

Option 2 — Integrate with Varlock https://github.com/dmno-dev/varlock

Instead of implementing the secret management layer ourselves, Compose Manager Plus could use Varlock as the secret resolution layer.

This would reduce the amount of secret-management code that needs to be maintained by Compose Manager Plus and could provide access to Varlock's supported secret backends.

The main disadvantage is that users would need to run and configure the Varlock container/service in addition to Compose Manager Plus.

My preference would be to keep the Compose files completely provider-agnostic, so that the same stack could potentially be deployed by Compose Manager Plus or another tool such as Dockhand without changing the Compose files.

What do you think?

On 9/30/2026 at 11:25 AM, L0rdRaiden said:

@mstrhakr

Hi, I was thinking about doing a contribution to your project by developing a secret management feature for Compose Manager Plus.

The idea would be to allow Compose stacks to use secrets without storing the actual values in .env files or Compose files. Secrets would be resolved only when the stack is deployed, while keeping the Compose files portable and compatible with standard Docker Compose.

I see two possible approaches:

Option 1 — Build it directly into Compose Manager Plus

Develop the secret management functionality natively, with the first backend being SOPS + age.

The plugin would resolve the secrets before running docker compose, inject them at runtime, and keep the secret values out of the repository and .env files.

Scope would include:

• Secret provider abstraction

• SOPS + age integration

• Per-stack secret configuration

• Runtime secret injection

• Secure handling/cleanup

• UI for configuring the secret source

The main advantage is that Compose Manager Plus would be fully self-contained and would not require another service to be running.
The native approach could also be designed around a provider abstraction, making it possible to add Bitwarden and other secret backends later, or use them as alternative/fallback providers without changing the Compose files. Similar to what dockhand does.

Option 2 — Integrate with Varlock https://github.com/dmno-dev/varlock

Instead of implementing the secret management layer ourselves, Compose Manager Plus could use Varlock as the secret resolution layer.

This would reduce the amount of secret-management code that needs to be maintained by Compose Manager Plus and could provide access to Varlock's supported secret backends.

The main disadvantage is that users would need to run and configure the Varlock container/service in addition to Compose Manager Plus.

My preference would be to keep the Compose files completely provider-agnostic, so that the same stack could potentially be deployed by Compose Manager Plus or another tool such as Dockhand without changing the Compose files.

What do you think?

This is interesting, one thing I am always thinking though is, 'Is this worth doing considering Unraid 8 will have a whole new base OS, layout, and built in compose support.' In this case, I'm not sure because I don't use secrets like that. With that said, I love contributions and would be happy to have you submit a PR for this if you think its worth tackling. I did just add credential management in dev to support private github repos and such so you may have some scaffolding available to reuse now.

On 9/13/2026 at 2:51 PM, rslite said:

Is there any way to configure an update check more frequently than once per day? I would like to automate some deployments and I'd like to be able to have the plugin check for updates every 5-15 minutes. Is that possible and/or create some resource issues?

We are working on Git based stacks which may include a webhook based deployment. We just started (by we I mean a contributor) so the beta only includes CLI based git stacks right now, no UI. Keep an eye out though. Beyond that, if you only want it to poll regularly, I would probably get it down to 15 minutes, I will look into this.

On 9/15/2026 at 5:55 PM, Raboon said:

Thanks for the quick support.
It's a local build folder that's available.

and true, I did click "remove orphans' When clicking compose down so that flow is working as you expect.

Update:

My yml looked like this:

build: .

image: container_xyz:latest

container_name: container_xyz

Swapping to this:

build:

context: /mnt/user/appdata/container_xyz/Build/

dockerfile: Dockerfile

container_name: container_xyz

Correction: Force Update & Rebuild still doesn't work

In the plugin settings, selecting "Rebuild Images on Update by Default" works.

Edit Stack / Settings / "Add --build to docker compose up when updating" doesn't save when selected.

Am I missing a trick? I would rather apply it at an individual level than use the master toggle.

I took a closer look at this and confirmed regression from the 09.13 update (#149 change made rebuilds opt-in, so local-only images hit a registry pull). Fixed in the next beta now: if the pull fails, buildable services are skipped and rebuilt from source automatically. The per-stack "Rebuild Images on Update" save bug is also fixed. With pull_policy: never, enable that per-stack toggle (or use pull_policy: build) to force a rebuild.

Hia! Many thanks for continued development of this life-saver of an addition to Unraid ecosystem. Manually filling out docker form was such a PITA.
Couple of questions:
1. how come some containers on the main (i.e. not the Compose) docker tab's 'VERSION' column are listed as "Compose", yet some are "3rd Party"?
2. all my compose-managed containers, even whose image version is set to particular tag, get restarted in the night. The time roughly corresponds to the Unraid's "Docker Auto Update Settings" scheduled time. Would it be possible to either
a) update if a newer version is available (e.g. if "latest" is being tracked); or
b) disable automatic updates (and hence restarts, I guess?) for compose altogether.

I have a few services that really shouldn't be restarted. But why these containers were restarted at all is still odd, given they're anchored to numeric tags.

Edited October 27Oct 27 by tuxbass

For your first question, this is controlled by a docker label entry, in Compose Manager Plus its handled by the override/labels section. Basically you have to specify the label net.unraid.docker.managed as composeman otherwise it shows up as 3rd Party in the UI. This is normally handled automatically but very much depends on how you have it all configured. If you are using a manual override setup, that is one way this could be missed.

services:
  docker-container:
    labels:
      net.unraid.docker.managed: 'composeman'

Compose has its own updates you can configure, sounds like there are still templates with the same name as the running dockers that are now Compose controlled. This likely is causing Unraids updates to try updating them. I will need to confirm this, but I would imagine using new container names would unlink them from their previous incarnation as a Docker Template and thus stop Unraid from trying to update them. I noticed this on a few of my containers but haven't tracked it down yet.

I will look into the update issue, if you can please add an issue on GitHub about it.

On 10/8/2026 at 4:56 PM, mstrhakr said:

I took a closer look at this and confirmed regression from the 09.13 update (#149 change made rebuilds opt-in, so local-only images hit a registry pull). Fixed in the next beta now: if the pull fails, buildable services are skipped and rebuilt from source automatically. The per-stack "Rebuild Images on Update" save bug is also fixed. With pull_policy: never, enable that per-stack toggle (or use pull_policy: build) to force a rebuild.

Thank you for investigating and for the fixes!

Edit: I found the issue and a workaround, github issue submitted. https://github.com/mstrhakr/compose_plugin/issues/189

I am having an error trying to create a git based stack.

I get this error when my project directory is set to /mnt/cache_ssd/appdata/_compose/stacks/

So I removed the trailing / and set the project directory to /mnt/cache_ssd/appdata/_compose/stacks

Now I get this error

I did try removing the plugin and doing a fresh install but still get the same results. Any ideas?

Edited October 31Oct 31 by Scootter

Started using this plugin and have found tge following issues:

1. Check for updates doesn't find all updates. When I force update it then updates

checked by script:
UPDATE: paperless-db-1 (paperless) -> docker.io/library/postgres:18
UPDATE: paperless-broker-1 (paperless) -> docker.io/library/redis:8
UPDATE: joplin-db-1 (joplin) -> postgres:16
UPDATE: arr-radarr-1 (arr) -> lscr.io/linuxserver/radarr:latest

The plugin found and I could update only radarr. The other one it didn't. Had to force update.

2. The UI is not always responsive, i.e. when starting a stack it keeps showing "Starting....". Only a browser refresh fixes this.
Also starting a stopped stack. Even after start it shows "stopped"

Edited November 2Nov 2 by manilx

On 10/30/2026 at 3:17 PM, Scootter said:

Edit: I found the issue and a workaround, github issue submitted. https://github.com/mstrhakr/compose_plugin/issues/189

I am having an error trying to create a git based stack.

I get this error when my project directory is set to /mnt/cache_ssd/appdata/_compose/stacks/

So I removed the trailing / and set the project directory to /mnt/cache_ssd/appdata/_compose/stacks

Now I get this error

I did try removing the plugin and doing a fresh install but still get the same results. Any ideas?

This is fixed in the latest beta if you are willing to try that out.

5 hours ago, manilx said:

Started using this plugin and have found tge following issues:

1. Check for updates doesn't find all updates. When I force update it then updates

checked by script:
UPDATE: paperless-db-1 (paperless) -> docker.io/library/postgres:18
UPDATE: paperless-broker-1 (paperless) -> docker.io/library/redis:8
UPDATE: joplin-db-1 (joplin) -> postgres:16
UPDATE: arr-radarr-1 (arr) -> lscr.io/linuxserver/radarr:latest

The plugin found and I could update only radarr. The other one it didn't. Had to force update.

2. The UI is not always responsive, i.e. when starting a stack it keeps showing "Starting....". Only a browser refresh fixes this.
Also starting a stopped stack. Even after start it shows "stopped"

Thank you for the report. I've also noticed some of these issues with the UI keeping up with what's happening. I'll be doing some work on this next to be included in the current beta soon.