Yes, reverse proxying is possible on ZimaOS. The real limitation in this source is not Docker networking itself; it is the convenience layer around GUI-installed apps. Traefik works best when each service has deliberate labels, predictable Compose service names, and shared Docker networks. Those controls are much easier when the stack is authored in Compose than when an app was installed with a simplified GUI form.
The source reply therefore recommends Nginx Proxy Manager for most GUI-oriented ZimaOS users and Traefik for users willing to deploy the relevant applications with Compose. This is community guidance, not an IceWhale official reverse-proxy architecture.
Why Traefik Feels Awkward with GUI-Installed Apps
Traefik's strongest workflow is automatic Docker discovery through labels such as routers, services, entrypoints, and TLS rules. If the app UI does not expose arbitrary labels—or if container names are generated/awkward—Traefik loses much of that automation.
Compose Restores Full Control
Current ZimaOS 1.7 App Store 2.0 supports native YAML and ZimaOS developer documentation treats standard Docker Compose as the runtime configuration model. Compose lets you define:
- stable service names;
- custom networks;
- Traefik labels;
- explicit host/container ports;
- volumes and restart policy.
Use the current ZimaOS Compose model.
Why Nginx Proxy Manager Is Easier
Nginx Proxy Manager does not require every backend application to carry discovery labels. You can create proxy hosts manually and point them to a stable container name/IP or to the ZimaOS host plus the application's published port.
That manual configuration is less elegant at scale, but easier for a mixed environment containing App Store apps and custom Compose stacks.
Plan Ports 80 and 443 Before Starting the Proxy
ZimaOS's own WebUI and HTTPS configuration can occupy standard web ports. A reverse proxy cannot bind to the same host IP/port already used by another process.
Either move the ZimaOS WebUI to another port, use another interface/IP, or deliberately publish the proxy on different external ports.
Shared Docker Networks Avoid Unnecessary Host Hairpinning
If the proxy and target app share a user-defined Docker network, proxy directly to the service/container name and internal port. This keeps traffic inside Docker and avoids depending on published host ports.
For GUI apps where that network cannot be controlled cleanly, host-IP/published-port proxying can still work.
Proxying the ZimaOS Dashboard Is a Separate Choice
Do not point every proxy host back at the ZimaOS IP by default. Use that upstream only when you intentionally want to proxy the ZimaOS WebUI itself.
Reverse Proxy Does Not Automatically Make an App Safe to Expose
A public HTTPS certificate only encrypts transport. Sensitive apps may still need authentication, MFA, access-control middleware, IP restrictions, or VPN-only exposure.
ZimaOS Reverse Proxy FAQ
Is reverse proxying impossible on ZimaOS?
No. The source community reply says it is possible; the friction is mostly around GUI app metadata, networks, and occupied ports.
Which option is easier for mixed GUI apps?
Nginx Proxy Manager is generally easier because it can be configured manually without per-app Traefik labels.
When does Traefik make the most sense?
When the app stack is deployed with Compose so labels, service names, and networks are under your control.
