Problem / Justification
Apps installed from the TrueNAS App Catalog currently lack a reliable and intuitive way to communicate with each other through the UI.
-
Setting “Expose port for inter-container communication” does not provide a usable path for other apps (e.g., reverse proxies) to reach the service.
-
The “Join Network” option requires a pre-existing Docker network that must already have at least one container attached, which is not possible to configure cleanly through the UI alone.
This limitation has been raised in multiple discussions since TrueNAS 24, but remains unresolved in TrueNAS 25.
Impact
Proper support for inter-app communication would significantly improve both usability and security for all TrueNAS users:
Benefits
-
Enables reverse proxy setups (e.g., nginx, Nginx Proxy Manager) without exposing service ports
-
Allows apps to communicate securely over internal Docker networks
-
Aligns TrueNAS Apps behavior with standard Docker Compose practices
-
Improves overall system security by encouraging least-exposure architecture
User Story
A typical user wants to run multiple apps (e.g., Immich + Nginx Proxy Manager) and expose only HTTPS (port 443) to the internet.
Expected workflow:
-
Install apps from App Catalog (e.g., Immich, Nginx Proxy Manager)
-
Set Immich to:
- Expose (not Publish)
-
In Nginx Proxy Manager:
- select Immich as an upstream service via container name or internal network
-
UI automatically ensures both apps share a common internal network
Result:
-
Immich is not exposed to LAN/WAN
-
Only nginx (port 443) is publicly accessible
-
Apps communicate securely via internal networking
Suggested Improvement
-
Allow users to:
-
Create and manage Docker networks directly in the UI
-
Attach multiple apps to shared networks without manual CLI steps
-
-
Ensure “Expose” mode actually enables inter-app communication
-
Provide a simple way to reference other apps (e.g., by service/container name)