I am looking into figuring out the proper way to do inter-app communication in TrueNAS 25.04 while using the official iX Apps, if it is at all possible.
I installed some apps that have their own Web UI, but they also have to communicate with each other. I was able to get them to communicate with each other by putting in the NAS IP along with the PORT that it is exposed to, but of course, I can’t determine the appropriate way to get them to communicate internally to each other while keeping external access.
Is it possible using the official iX applications? Or is this something that will truly need to be done by doing a custom YAML or something of the sort?
I am not 100% sure, but I don’t think the Dragonify YAML would work anymore either, since it’s not on 24.10. I didn’t attempt it, but before trying something that I haven’t found confirmed, I just wanted to ask first.
I would PREFER to keep it as the official iX apps, so it’s easy to see app status and updates, etc.
In that feature request is comment with a link to a script from a community member that afaik establishes inter app communication by internal dns names
Yep, and thats what i mean. I saw that but it looked like only reports of it working in 24.10. I am unsure if there is current support for inter-app communication that is solid, or if there is anything in beta. Thats all.
Im still very new to TrueNAS, so my experience is slim.
@JohniFi I was going to do the same as you when the option for networks was introduced in the apps, but because when you choose a network for an app TrueNAS stops creating its default network, I decided to wait until a way is introduced in the GUI to create a network (of course you can create networks in the terminal) and in the meantime stick with Dragonify.
Edit: keep in mind that the order with which apps start may affect the (default) networks available, and may cause an app to fail to start.
Dragonify does not add each app to each other’s network, it creates a new “apps-internal” network and adds all apps to that, although there is a fork which lets you manually pick which apps will connect to which network.
By the way, both this post and the one where you posted your steps where created before the Networks option was added to app configuration .
@psxlover Thanks for your reply. But in my case NPM still got it’s own network (“ix-nginx-proxy-manager_default” in my case) even after adding additional networks as described in my post. And even if that was not the case, I actually don’t need the npm-network for this to work, because in a reverse proxy scenario I just want to connect each app with the reverse proxy (individually). That “individually” is also the biggest difference to the dragonify approach that creates a potential threat vector (if they all share the same network), because now all apps can communicate with each other when really it would be enough if the reverse proxy can talk to each one individually.
I realize that this thread here is maybe not exactly the right place for my solution but when I tried to find a solution for my reverse proxy scenario I stumbled over a hand full of these threads (like this one) and none solved my problem without dragonify-“hacking”. So I just wanted to help others with similar search algorithm results
Just make sure that if there is an app that you don’t want to be active by default (like I do for example with Filebrowser app), you use a dedicated/manual network for both that app and NPM app instead of using the app’s default, because if the apps is not enabled the network is not created on boot, and then NPM fails to start because of the missing network.
Good to know. But I could not replicate this issue. I stopped my “metube” app and rebooted TrueNAS. But the network “ix-metube_default” was still there in docker network ls even without the app running and also my “Nginx Proxy Manager” came online just fine and did it’s work for all other Proxy Hosts (of course leading to “502 Bad Gateway” when trying to open MeTube). After restarting MeTube manually, NPM resolved it just fine straight away.
Did I miss something or did they just fixed your issue already in 25.10.3.1?
.