Apparently this is once again blacklisted?

59 minutes ago, cave said:

Apparently this is once again blacklisted?

I'm taking a look now as to why both versions are blacklisted, the beta i understand because I merged main into dev, but the main version should be fine. You can install anyway by enabling blacklisted apps in the CA settings. Turns out I was wrong, that is for depreciated apps, not blacklisted ones.

Edited June 1Jun 1 by mstrhakr

Well, I fixed the dev side and now the dev/beta branch is missing and the main plugin is still blacklisted with no real reason at this point.

@Squid Do you think you could check this out, I think I'm stuck at this point.

9 hours ago, mstrhakr said:

Well, I fixed the dev side and now the dev/beta branch is missing and the main plugin is still blacklisted with no real reason at this point.

@Squid Do you think you could check this out, I think I'm stuck at this point.

For your information, squid has the community applications moderations repository on his GitHub, which includes everything for CA ,including blacklisted stuff. You basically have to create a PR to un-blacklist (remove your repository from the blacklist file) and let squid merge it. It's super simple and straightforward. I have done that myself 3 times already (not for plugins, but for docker container templates, which got falsely marked as duplicates)

The repository is here https://github.com/Squidly271/Community-Applications-Moderators

If you search for your username in the repo, you will find the blacklist file I was mentioning. Just delete the part for your main branch and PR it

3 minutes ago, Joly0 said:

The repository is here https://github.com/Squidly271/Community-Applications-Moderators

If you search for your username in the repo, you will find the blacklist file I was mentioning. Just delete the part for your main branch and PR it

Thank you Joly, I will look into this today!

Just looked through it, couldn't find it, then realized I linked the wrong repository (but still correct for container templates). The actually file you should edit is this one:

https://github.com/Squidly271/AppFeed/blob/3127c70c026d256115bce4d64f3777afdd6c0862/statistics.json#L1856

I've got a PR in for this here https://github.com/Squidly271/AppFeed/pull/37 so we will see if this takes care of the blacklist issue. I've also pinged Squid here, the only thing left I know of is to ping him on Discord which I will do if I don't see any movement on this soon.

AFAIK it's an intentional protection in CA, if 2 plugins have the same URLs it triggers so there can't be a takeover whether intentional or not if someone forks a plugin and doesn't change it, requiring manual review/reapproval. Happened some time ago with major plugins when their ownership changed, IIRC there is talk about it in the CA thread.

If you want 2 versions of a plugin your dev setup must be separate enough so that such a mistake of mixing them up can never happen.

Edited June 1Jun 1 by Kilrah

Yeah, I didn't look carefully this morning while updating my dockers and plugins, and just clicked "yes"... But ist was "Yes, delete" and not "Yes, update" 🙈 Hopefully the plugin will comeback, as I wanted to build my own immich stack with several ML options and GPU support.
My Paperless stack works flawlessly, so it I really hope, that the plug will comeback. Thanks for your great work @mstrhakr 😊

Mesmerising default reasoning given in the blacklisting... instead of actually notifying that the old plugin is deprecated they sabotage the new plugin with obscure "App "Compose Manager Plus (Beta)" is blacklisted: Blacklisted application" instead of something more clear like "temporarily blocked due to template inconsistencies".

Edited June 2Jun 2 by Samsonight

Converting Docker Compose custom networks to container networking on Unraid

The problem

Most Docker Compose files use custom networks so containers can talk to each other by name (e.g., app calls db instead of an IP address). On normal Linux, this just works.

On Unraid, custom networks are a headache:

• Unraid's Docker UI doesn't know about them

• They don't survive reboots unless you hack the go file

• Containers on custom networks sometimes can't reach the host or LAN

• The Compose Manager plugin creates/destroys them, but Unraid's native Docker tab gets confused

The solution: container networking

Instead of giving containers their own private network, you stack them into one container's network — exactly like how VPN containers (Gluetun) already work on Unraid.

(there are other implementations but they are just made by people stuck in the non-containerized mutable old ways).

Docker Documentation

Networking overview

Learn how networking works from the container's point of view

The conversion recipe:

1. Pick the "main" container — the one users actually connect to (the web UI, the app). This one gets normal bridge networking and port mappings.

2. For every other container in the stack
   
   replace:

   networks:

   - mynetwork

   
   with:

   network_mode: container:main-container-name
   
   

3. Change hostnames to localhost — since all containers now share one network namespace:

   
   replace:

   DB_HOST=db

   REDIS_HOST=redis

   
   with:

   DB_HOST=127.0.0.1

   REDIS_HOST=127.0.0.1

4. Delete the networks: block at the bottom of the compose file entirely.

5. Move all port mappings to the main container — since only it owns the network, only it can expose ports.

What breaks and how to fix it

• Two containers bind the same internal port: Reconfigure one to use a different port via env var

• Startup order matters (DB must be up before app): Most apps retry on their own; compose depends_on still works

• Main container restarts: Supporting containers briefly lose networking, reconnect automatically

What you can't convert

• Stacks where containers need separate IPs (macvlan, multiple web servers each needing port 80) — rare in homelab

• Multi-stack communication (reverse proxy in stack A needs to reach app in stack B) — use host ports instead

• Network segmentation (frontend can't reach database) — nobody does this at home

That's it

For 95% of compose stacks on Unraid (Seafile, Immich, Paperless, Nextcloud, any app + database + cache combo), the conversion is: pick the main container, attach everything else to it, change hostnames to 127.0.0.1, delete the networks block. Five minutes of editing, zero custom network problems.

Example

# Converted to container networking (main: app)
# Supporting services share network via: network_mode: container:app
#
# === CHANGES MADE ===
#   [app] DB_HOST=db
#        -> DB_HOST=127.0.0.1
#   [app] REDIS_URL=redis://cache:6379
#        -> REDIS_URL=redis://127.0.0.1:6379
#
services:
  app:
    image: myapp:latest
    ports:
    - 8080:80
    environment:
    # was: DB_HOST=db
    - DB_HOST=127.0.0.1
    # was: REDIS_URL=redis://cache:6379
    - REDIS_URL=redis://127.0.0.1:6379
    depends_on:
    - db
    - cache
  db:
    image: mariadb:10.11
    environment:
    - MYSQL_ROOT_PASSWORD=secret
    volumes:
    - /mnt/user/appdata/myapp/db:/var/lib/mysql
    # was: networks: [custom]  -- converted to container networking
    network_mode: container:app
  cache:
    image: redis:7
    volumes:
    - /mnt/user/appdata/myapp/redis:/data
    # was: networks: [custom]  -- converted to container networking
    network_mode: container:app

Edited June 2Jun 2 by Samsonight
clarification

IF... one where to ALSO automate conversion (even optionally) to produce hints and starting point examples of any existing compose file needed... in the spirit of lowering adoption threshold...

Usage: python3 compose-to-containernet.py <compose-file.yml> — only needs PyYAML.

The test suite is self-contained, anyone can clone:

for f in tests/*.yml; do python3 compose-to-containernet.py "$f"; done

to see the output for themselves.

(as used in the previous example section)

compose-to-containernet.py

Edited June 3Jun 3 by Samsonight
attachment

7 hours ago, BastiKA84 said:

Yeah, I didn't look carefully this morning while updating my dockers and plugins, and just clicked "yes"... But ist was "Yes, delete" and not "Yes, update" 🙈 Hopefully the plugin will comeback, as I wanted to build my own immich stack with several ML options and GPU support.
My Paperless stack works flawlessly, so it I really hope, that the plug will comeback. Thanks for your great work @mstrhakr 😊

Just so you know, you can reinstall manually and perform updates from the plugin tab, regardless of the status in CA.

I cannot get auto-update to work. When it's all set up and it runs at night I always end up with "toomanyrequests" errors, so Compose Manager Plus has to be doing something terrible to trigger this.

Doesn't happen with containers that are non-compose (updated through the CA auto-updater).

For example, my Jellyfin stack that has one container (Jellyfin) got this error tonight:

Auto-update failed: jellyfin
Auto-update pull failed for 'jellyfin'. Recent output: Image lscr.io/linuxserver/jellyfin:latest Pulling 
toomanyrequests: retry-after: 152.468s, allowed: 44000/minute

14 hours ago, mstrhakr said:

Just so you know, you can reinstall manually and perform updates from the plugin tab, regardless of the status in CA.

I was aware, that I could install a plugin like that. I didn't know, that it would use the config I already have and could manage the stack I build before. But I installed it from your Git and it just works! Thank you ❤️

4 hours ago, nadbmal said:

I cannot get auto-update to work. When it's all set up and it runs at night I always end up with "toomanyrequests" errors, so Compose Manager Plus has to be doing something terrible to trigger this.

Doesn't happen with containers that are non-compose (updated through the CA auto-updater).

For example, my Jellyfin stack that has one container (Jellyfin) got this error tonight:

I'll take a closer look, would you be willing to open an issue on GitHub to track this?

plugin is still blacklisted today, is there any hope getting it back?

2 hours ago, mdastous said:

plugin is still blacklisted today, is there any hope getting it back?

Yes, we are waiting for Squid to merge the PR. This could take a while, in the meantime you can install and update manually from the plugins tab of Unraid. There are directions available in the first post and on GitHub.

I have version 2026.04.24  but unraid doesnt offer update to latest v2026.05.31 from GitHub.

Enables you to spin up services like SeaFile (App, Redis, SQL) or Discourse (App, Redis, SQL), or even Wazuh (Manager, Indexer, Dashboard) in a single compose file, not having to worry about dependencies, updates or anything else.

compose-to-containernet v2026.06.03a

• Converts custom Docker networks to network_mode: container: (shared network namespace)

• Auto-detects main service (most ports + most dependencies)

• Rewrites service hostname references to 127.0.0.1 in environment variables and URLs

• Adds depends_on: service_started for correct startup ordering

• Parameterizes images, volumes, and ports with ${VAR:-default} (override via .env, works without one)

• Moves stray ports from supporting services to the main service

• Flags mounted config files and external env files for manual hostname review

• Detects port conflicts between services sharing a namespace

• Preserves original values as # was: comments

• Skips services that already have network_mode set

• Validates output is valid YAML before writing

On 6/2/2026 at 3:55 PM, Samsonight said:

Converting Docker Compose custom networks to container networking on Unraid

The problem

Most Docker Compose files use custom networks so containers can talk to each other by name (e.g., app calls db instead of an IP address). On normal Linux, this just works.

On Unraid, custom networks are a headache:

• Unraid's Docker UI doesn't know about them

• They don't survive reboots unless you hack the go file

• Containers on custom networks sometimes can't reach the host or LAN

• The Compose Manager plugin creates/destroys them, but Unraid's native Docker tab gets confused

The solution: container networking

Instead of giving containers their own private network, you stack them into one container's network — exactly like how VPN containers (Gluetun) already work on Unraid.

(there are other implementations but they are just made by people stuck in the non-containerized mutable old ways).

Docker Documentation

Networking overview

Learn how networking works from the container's point of view

The conversion recipe:

1. Pick the "main" container — the one users actually connect to (the web UI, the app). This one gets normal bridge networking and port mappings.

2. For every other container in the stack
   
   replace:

   networks:

   - mynetwork

   
   with:

   network_mode: container:main-container-name
   
   

3. Change hostnames to localhost — since all containers now share one network namespace:

   
   replace:

   DB_HOST=db

   REDIS_HOST=redis

   
   with:

   DB_HOST=127.0.0.1

   REDIS_HOST=127.0.0.1

4. Delete the networks: block at the bottom of the compose file entirely.

5. Move all port mappings to the main container — since only it owns the network, only it can expose ports.

What breaks and how to fix it

• Two containers bind the same internal port: Reconfigure one to use a different port via env var

• Startup order matters (DB must be up before app): Most apps retry on their own; compose depends_on still works

• Main container restarts: Supporting containers briefly lose networking, reconnect automatically

What you can't convert

• Stacks where containers need separate IPs (macvlan, multiple web servers each needing port 80) — rare in homelab

• Multi-stack communication (reverse proxy in stack A needs to reach app in stack B) — use host ports instead

• Network segmentation (frontend can't reach database) — nobody does this at home

That's it

For 95% of compose stacks on Unraid (Seafile, Immich, Paperless, Nextcloud, any app + database + cache combo), the conversion is: pick the main container, attach everything else to it, change hostnames to 127.0.0.1, delete the networks block. Five minutes of editing, zero custom network problems.

Example

# Converted to container networking (main: app)# Supporting services share network via: network_mode: container:app## === CHANGES MADE ===#   [app] DB_HOST=db#        -> DB_HOST=127.0.0.1#   [app] REDIS_URL=redis://cache:6379#        -> REDIS_URL=redis://127.0.0.1:6379#services:app:
    image: myapp:latest
    ports:
    - 8080:80
    environment:
    # was: DB_HOST=db
    - DB_HOST=127.0.0.1
    # was: REDIS_URL=redis://cache:6379
    - REDIS_URL=redis://127.0.0.1:6379
    depends_on:
    - db
    - cachedb:
    image: mariadb:10.11
    environment:
    - MYSQL_ROOT_PASSWORD=secret
    volumes:
    - /mnt/user/appdata/myapp/db:/var/lib/mysql
    # was: networks: [custom]  -- converted to container networking
    network_mode: container:appcache:
    image: redis:7
    volumes:
    - /mnt/user/appdata/myapp/redis:/data
    # was: networks: [custom]  -- converted to container networking
    network_mode: container:app

On 6/2/2026 at 4:36 PM, Samsonight said:

IF... one where to ALSO automate conversion (even optionally) to produce hints and starting point examples of any existing compose file needed... in the spirit of lowering adoption threshold...

Usage: python3 compose-to-containernet.py <compose-file.yml> — only needs PyYAML.

The test suite is self-contained, anyone can clone:

for f in tests/*.yml; do python3 compose-to-containernet.py "$f"; done

to see the output for themselves.

(as used in the previous example section)

compose-to-containernet.py

Edited June 3Jun 3 by Samsonight
conversion features

@Samsonight I think your AI agent is posting to the wrong topic. This topic is for support when using the Compose Manager Plus plug-in. Maybe posting it under Guides would be better?

Edited June 6Jun 6 by Cino

1 minute ago, Cino said:

@Samsonight I think your AI agent is posting to the wrong topic. This topic is for support when using the Compose Manager Plus plug-in. Maybe a posting it under Guides would be better?

@Cino hardly, with it the compose manager actually becomes functional and compatible ❤️But your human agent clearly hasn't thought about what are the biggest adoption thresholds for both the plug-in and Unraid, letting both drift behind the alternatives. I find it mesmerising someone complains about a fully stand-alone supplementary functionality (poc) boosting the plug-in itself (include it, its free), there is no competition, it is the first thing users run into trying to get even the most rudimentary compose to lift. Please don't follow Unraid in their cargo culting, if containers was implemented properly we wouldn't need to build plugins like this to begin with. 🤠

Edited June 3Jun 3 by Samsonight
clarification

2 hours ago, mdastous said:

I have version 2026.04.24  but unraid doesnt offer update to latest v2026.05.31 from GitHub.

I had the beta installed, and when I went to update today from the Action Center, it wouldn't update because it was tagged as blacklisted. However, when I searched for the plugin in CA, it showed that I had the normal version with the tag installed but not the latest version.

I then proceeded to uninstall the beta plugin to try to install the normal version. After uninstalling, the search only returned the beta version with the blacklist tag, so I couldn't reinstall. I then went to the Plugins page > Install Plugin tab > entered the following URL https://raw.githubusercontent.com/mstrhakr/compose_plugin/main/compose.manager.plg > wait for installation to finish.

It installed 2026.05.31 without any issues.

This is now fixed! Thank you @elibosley