L0rdRaiden

@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?

Do you plan to make this standalone?

it is possible to have a custom path for where the plugins are stored? will it work if I edit both paths? { "/boot/config/plugins/user.scripts/scripts/CCTV Monitoring/script": { "script": "/boot/config/plugins/user.scripts/scripts/CCTV Monitoring/script", "frequency": "start", "id": "scheduleCCTVMonitoring", "custom": "" },

Does the collection interval are related with the API? When I do a request via API the information is gathered at that moment or it takes the information generated by Collection Intervals section?

@Waseh can you add an option to notify if there is a new versión of rclone? and auto-update?

it worked after a reboot....

Attached unraid-diagnostics-20260531-1644.zip

I am using 7.2.5 I have tried to update to 7.3.1 and any of the previous versions but + in this screen after I click on "confirm" the popups gets closed and nothing happens, there is no trace on the log either. Any idea what could be wrong? I have tried with 2 browsers, without add blockers...

via MCP is possible to limit changes on unraid? like an MCP setting that only allow to consume data but not to change or modify anything in unraid, like a read only mode where any MCP skill that changes anything in unraid is blocked by the plugin

Could all this be packaged in a plugin for unRAID?

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

I need this to support Falco FalcoDeploy as a containerLearn how to run and manage Falco as a container Please add it. Unraid security options are extremely limited

Can you add options to configure the statup order of the stacks and delays between them? How is the migration from the old docker compose manager? Do i have to unistall it first? What about auto updates? Any plan for this?

So when I pressed "y" at the end, the program just exit, leaving the cmd again. The same happened to you? how long did you wait to reboot?

It's still working fine, did it solve the issue?