Enabling HTTPS for the ZimaOS dashboard does not automatically give Jellyfin, Vaultwarden, Nginx Proxy Manager, or every other Docker application an HTTPS address. That misunderstanding is exactly what started this February 2026 thread. The user had enabled HTTPS in ZimaOS Settings, saved the certificate generated for the ZimaOS interface, and tried to import it into Nginx Proxy Manager, but Jellyfin and NPM still did not behave as expected.
The thread ultimately reached a working community configuration: use Nginx Proxy Manager as the TLS termination point for individual applications, move the ZimaOS gateway away from ports 80 and 443 if those ports are needed by the reverse proxy, configure a hostname through DuckDNS, and issue a certificate for that hostname. The source user later posted a screenshot showing the proxy hosts online and summarized the result as working.
Understand the Three Separate HTTPS Layers
There are three different things that are easy to mix together:
- ZimaOS dashboard HTTPS protects the ZimaOS management interface itself.
- Application HTTP is the normal internal port used by an app such as Jellyfin.
- Reverse-proxy HTTPS is a public or local hostname that terminates TLS and forwards traffic to the app's internal HTTP port.
The certificate generated for the ZimaOS management UI is therefore not a universal certificate for every application. A reverse proxy needs a certificate whose hostname matches the address users actually open in the browser.
Use Nginx Proxy Manager as the HTTPS Front Door
The most reusable part of the community solution is the architecture rather than the exact 2026 port numbers. Nginx Proxy Manager receives HTTPS requests for hostnames such as jellyfin.example.net and forwards them to the local Jellyfin HTTP service. Jellyfin can continue listening on its normal internal port; it does not need to manage the public certificate itself.
Current Nginx Proxy Manager keeps this model: create a Proxy Host, specify the destination host and port, then attach an SSL certificate and optionally force SSL. For a new setup, follow the current Nginx Proxy Manager flow for proxy hosts and certificates rather than treating an old screenshot as a fixed UI contract.
Resolve Port 80 and 443 Conflicts Before Issuing Certificates
The source user discovered that the ZimaOS gateway was already using ports 80 and 443. That matters because a reverse proxy normally wants to listen on those standard ports. Their workaround was to change the ZimaOS gateway ports in /etc/casaos/gateway.ini, moving 80 to 85 and 443 to 444, then restart the gateway service.
Those exact edits came from the user, not from an IceWhale support reply in this thread. They should be treated as a historical community workaround, not a universal command sequence. Before changing dashboard ports, record the current URL, make sure you know how to reach ZimaOS afterward, and prefer the current ZimaOS UI when it provides a supported way to change the management port.
Why DuckDNS Helped the Source User
A certificate authority needs a hostname it can validate. The user configured DuckDNS, then used that hostname to request a certificate through Nginx Proxy Manager. That solved a different problem from “how do I reach the app?”: DNS supplied the name, while NPM supplied the HTTPS termination and forwarding.
Local-Only HTTPS Still Needs DNS That Resolves Locally
The original question was specifically about HTTPS inside the local network, not remote access. A domain name does not force traffic to leave the house. You can make a hostname resolve to the ZimaOS LAN address inside your network through local DNS or split DNS, then let Nginx Proxy Manager serve a trusted certificate for that hostname.
This is usually cleaner than browsing to a raw private IP and trying to make a public certificate match it. The certificate is validated for the hostname; your local DNS decides that the hostname should resolve to a private address.
A Self-Signed Certificate Is Another Option, but Trust Must Be Managed
One community reply suggested generating a certificate with OpenSSL and importing it into Nginx Proxy Manager. That can work for purely local use, but browsers and devices will not trust a self-signed certificate automatically. Every client that should show a clean HTTPS connection needs to trust the issuing certificate or local CA.
For a household with many phones, TVs, tablets, and apps, using a publicly trusted certificate for a hostname is often easier than manually installing a local CA everywhere.
Cloudflare Is an Alternative Architecture, Not a Requirement
Another participant said they used Cloudflare both inside and outside the home network. Cloudflare can be useful if the same hostname must work remotely, but the source question did not require public access. Do not add a tunnel simply because HTTPS is desired on the LAN.
Verify Each Layer Separately
- Confirm the application opens over its direct local HTTP address.
- Confirm the hostname resolves to the intended reverse proxy.
- Confirm Nginx Proxy Manager can reach the application's internal host and port.
- Attach the certificate only after plain proxy routing works.
- Then force HTTPS and test from more than one local client.
This order prevents a certificate problem from being confused with a Docker routing problem or a port conflict.
Local HTTPS on ZimaOS FAQ
Does the ZimaOS HTTPS toggle secure Jellyfin automatically?
No. It secures the ZimaOS management interface, not every Docker application.
Do I need a public domain for LAN-only HTTPS?
You need a hostname that your certificate matches. That hostname can resolve to a private LAN address inside your network.
Why did the source user move ZimaOS away from ports 80 and 443?
Nginx Proxy Manager needed the standard HTTP and HTTPS ports. The change was a community workaround for that installation.
Was the source setup confirmed working?
Yes. The original poster showed the NPM hosts online with certificates and said the setup worked.
