ZimaOS dashboard HTTPS does not automatically secure every Docker app. Apps listening on their own ports need native HTTPS or a reverse proxy. A random GitHub repository URL is also not a valid ZimaOS App Store source—the repository must follow the current store protocol.
The April 2026 source thread combined these two beginner questions. The clean answer is to separate them: reverse proxy for app TLS, compatible store or custom Compose for missing software.
Why Dashboard HTTPS Does Not Secure Apps
The ZimaOS HTTPS setting protects the dashboard hostname. A Docker app on http://SERVER:8080 remains a separate service. The HTTPS reverse proxy guide explains the boundary.
Use a Reverse Proxy for App HTTPS
https://app.example.com
↓
Reverse proxy / TLS
↓
http://app-container:portNginx Proxy Manager or Caddy can terminate TLS and forward to an app.
Local HTTPS and Public HTTPS Are Different
For LAN-only use, internal DNS and a local CA can work. Public domains need valid certificates and deliberate remote-access/security rules.
Why a Raw GitHub URL Gives an Error
The App Store expects compatible store output, not arbitrary application source code.
Current ZimaOS App Store Protocol
The current ZimaOS App Store developer guide defines a v2 store with store-config.json, supported-languages.json, an Apps/ tree, and generated dist/ output.
For One App, Use Custom Compose
If you only need one project, creating a whole store is unnecessary. Import or create Docker Compose with correct ports, volumes, and x-casaos metadata. The current Docker Compose and x-casaos reference documents the format.
Watch Ports 80 and 443
Reverse proxies commonly want 80/443, which may already be used by ZimaOS. Check ownership before deployment.
Choose the Reverse-Proxy Name Before You Configure TLS
Decide whether users will open app.home.arpa, a private domain, or a public domain. Certificates validate names, so configuring TLS before deciding DNS names often leads to warnings and duplicate proxy entries.
Do Not Proxy an App You Cannot Reach Directly
Before adding a proxy host, open the backend app at its normal HTTP address. If http://SERVER:PORT is already broken, adding HTTPS will only hide the original problem behind a proxy error.
Use One App Package Before Building a Whole Store
A third-party store is useful when you maintain many applications for repeated installation. For a single missing app, custom Compose is simpler to test, update, and audit. Only build a repository when you need catalog distribution, metadata, assets, and repeatable updates.
Validate Compose Before Publishing
Current ZimaOS developer docs expect valid Docker Compose plus the top-level x-casaos metadata. Test the Compose stack first, then add catalog metadata; do not debug container runtime and store packaging at the same time.
Keep the Proxy Admin Interface Private
If you deploy Nginx Proxy Manager or another reverse proxy, the administrative UI should stay on the LAN or a private VPN. Public traffic should reach only the proxy's intended HTTP/HTTPS listeners, not the management port.
Likewise, do not expose a private app merely because you now have a valid certificate. TLS protects transport; it does not replace authentication or network access control.
FAQ
Does ZimaOS HTTPS cover all apps?
No. Each app endpoint needs its own HTTPS or a reverse proxy.
Can I add any GitHub repository to the App Store?
No. It must be a compatible store or an app packaged as Compose.
Do I need a public domain for local HTTPS?
No. Internal DNS and trusted local certificates can work.
What is the easiest way to install one missing app?
Use a current custom Docker Compose app.
