HTTPS für das ZimaOS-Dashboard sichert nicht automatisch jede Docker-App. Apps, die an eigenen Ports lauschen, benötigen natives HTTPS oder einen Reverse-Proxy. Eine beliebige URL zu einem GitHub-Repository ist außerdem keine gültige ZimaOS-App-Store-Quelle – das Repository muss dem aktuellen Store-Protokoll folgen.
Der Quell-Thread vom April 2026 kombinierte diese beiden Anfängerfragen. Die klare Antwort besteht darin, sie zu trennen: Reverse-Proxy für TLS der App, kompatibler Store oder benutzerdefiniertes Compose für fehlende Software.
Warum HTTPS für das Dashboard Apps nicht absichert
Die HTTPS-Einstellung von ZimaOS schützt den Hostnamen des Dashboards. Eine Docker-App unter http://SERVER:8080 bleibt ein separater Dienst. Der Leitfaden zum HTTPS-Reverse-Proxy erklärt diese Abgrenzung.
Reverse-Proxy für HTTPS der App verwenden
https://app.example.com
↓
Reverse-Proxy / TLS
↓
http://app-container:portNginx Proxy Manager oder Caddy können TLS beenden und Anfragen an eine App weiterleiten.
Lokales HTTPS und öffentliches HTTPS sind unterschiedlich
Für die ausschließliche Nutzung im LAN können internes DNS und eine lokale CA funktionieren. Öffentliche Domains benötigen gültige Zertifikate sowie bewusst konfigurierte Regeln für Fernzugriff und Sicherheit.
Warum eine unveränderte GitHub-URL einen Fehler verursacht
Der App Store erwartet kompatible Store-Ausgaben, nicht beliebigen Quellcode einer Anwendung.
Aktuelles ZimaOS-App-Store-Protokoll
Der aktuelle Entwicklerleitfaden für den ZimaOS App Store definiert einen Store der Version 2 mit store-config.json, supported-languages.json, einer Apps/-Struktur und generierten dist/-Ausgabedateien.
Für eine einzelne App benutzerdefiniertes Compose verwenden
Wenn Sie nur ein Projekt benötigen, ist die Erstellung eines vollständigen Stores unnötig. Importieren oder erstellen Sie eine Docker-Compose-Konfiguration mit den richtigen Ports, Volumes und x-casaos-Metadaten. Die aktuelle Referenz zu Docker Compose und x-casaos dokumentiert das Format.
Ports 80 und 443 beachten
Reverse-Proxys benötigen häufig 80/443, die möglicherweise bereits von ZimaOS verwendet werden. Prüfen Sie vor der Bereitstellung, welcher Dienst diese Ports belegt.
Den Namen des Reverse-Proxys vor der TLS-Konfiguration festlegen
Entscheiden Sie, ob Benutzer app.home.arpa, eine private Domain oder eine öffentliche Domain öffnen werden. Zertifikate validieren Namen. Wenn Sie TLS konfigurieren, bevor Sie die DNS-Namen festlegen, kommt es daher häufig zu Warnungen und doppelten Proxy-Einträgen.
Keine App weiterleiten, die Sie nicht direkt erreichen können
Öffnen Sie die Backend-App unter ihrer normalen HTTP-Adresse, bevor Sie einen Proxy-Host hinzufügen. Wenn http://SERVER:PORT bereits nicht funktioniert, wird das Hinzufügen von HTTPS das ursprüngliche Problem lediglich hinter einem Proxy-Fehler verbergen.
Vor dem Aufbau eines vollständigen Stores ein einzelnes App-Paket verwenden
Ein Drittanbieter-Store ist nützlich, wenn Sie viele Anwendungen für wiederholte Installationen verwalten. Für eine einzelne fehlende App ist benutzerdefiniertes Compose einfacher zu testen, zu aktualisieren und zu prüfen. Erstellen Sie ein Repository nur dann, wenn Sie Katalogverteilung, Metadaten, Assets und wiederholbare Updates benötigen.
Compose vor der Veröffentlichung validieren
Die aktuellen ZimaOS-Entwicklerdokumente erwarten gültiges Docker Compose sowie die Metadaten x-casaos auf oberster Ebene. Testen Sie zunächst den Compose-Stack und fügen Sie anschließend die Katalogmetadaten hinzu. Debuggen Sie nicht gleichzeitig die Container-Laufzeit und die Store-Paketierung.
Die Admin-Oberfläche des Proxys privat halten
Wenn Sie Nginx Proxy Manager oder einen anderen Reverse-Proxy bereitstellen, sollte die Verwaltungsoberfläche auf das LAN oder ein privates VPN beschränkt bleiben. Öffentlicher Datenverkehr sollte nur die vorgesehenen HTTP-/HTTPS-Listener des Proxys erreichen, nicht den Verwaltungsport.
Setzen Sie außerdem eine private App nicht allein deshalb dem öffentlichen Zugriff aus, weil Sie nun ein gültiges Zertifikat haben. TLS schützt die Übertragung; es ersetzt weder Authentifizierung noch Netzwerkzugriffskontrolle.
FAQ
Deckt HTTPS von ZimaOS alle Apps ab?
Nein. Jeder App-Endpunkt benötigt eigenes HTTPS oder einen Reverse-Proxy.
Kann ich jedes GitHub-Repository zum App Store hinzufügen?
Nein. Es muss sich um einen kompatiblen Store oder eine als Compose paketierte App handeln.
Benötige ich für lokales HTTPS eine öffentliche Domain?
Nein. Internes DNS und vertrauenswürdige lokale Zertifikate können funktionieren.
Wie installiere ich am einfachsten eine einzelne fehlende App?
Verwenden Sie eine aktuelle benutzerdefinierte Docker-Compose-App.
