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.