HTTPS pulpitu ZimaOS nie zabezpiecza automatycznie każdej aplikacji Docker. Aplikacje nasłuchujące na własnych portach potrzebują natywnego HTTPS lub odwrotnego proxy. Losowy adres repozytorium GitHub nie jest też prawidłowym źródłem ZimaOS App Store — repozytorium musi być zgodne z aktualnym protokołem sklepu.
Wątek źródłowy z kwietnia 2026 r. połączył te dwa pytania początkujących użytkowników. Najlepiej je rozdzielić: odwrotne proxy zapewnia TLS aplikacji, a zgodny sklep lub niestandardowy Compose pozwala zainstalować brakujące oprogramowanie.
Dlaczego HTTPS pulpitu nie zabezpiecza aplikacji
Ustawienie HTTPS w ZimaOS chroni nazwę hosta pulpitu. Aplikacja Docker pod adresem http://SERVER:8080 pozostaje oddzielną usługą. Przewodnik po odwrotnym proxy HTTPS wyjaśnia tę granicę.
Użyj odwrotnego proxy do obsługi HTTPS aplikacji
https://app.example.com
↓
Odwrotne proxy / TLS
↓
http://app-container:portNginx Proxy Manager lub Caddy mogą zakończyć połączenie TLS i przekierować je do aplikacji.
Lokalne HTTPS i publiczne HTTPS to nie to samo
Do użytku wyłącznie w sieci LAN można użyć wewnętrznego DNS-u i lokalnego urzędu certyfikacji. Publiczne domeny wymagają ważnych certyfikatów oraz przemyślanych zasad zdalnego dostępu i bezpieczeństwa.
Dlaczego surowy adres URL GitHub powoduje błąd
App Store oczekuje zgodnych danych sklepu, a nie dowolnego kodu źródłowego aplikacji.
Aktualny protokół ZimaOS App Store
Aktualny przewodnik dla deweloperów ZimaOS App Store definiuje sklep w wersji v2 z plikami store-config.json, supported-languages.json, strukturą Apps/ oraz wygenerowanymi danymi wyjściowymi dist/.
W przypadku jednej aplikacji użyj niestandardowego Compose
Jeśli potrzebujesz tylko jednego projektu, tworzenie całego sklepu jest zbędne. Zaimportuj lub utwórz konfigurację Docker Compose z prawidłowymi portami, woluminami i metadanymi x-casaos. Aktualna dokumentacja Docker Compose i x-casaos opisuje ten format.
Zwróć uwagę na porty 80 i 443
Odwrotne proxy często potrzebują portów 80/443, które mogą być już używane przez ZimaOS. Przed wdrożeniem sprawdź, która usługa nimi zarządza.
Wybierz nazwę odwrotnego proxy przed skonfigurowaniem TLS
Zdecyduj, czy użytkownicy będą otwierać app.home.arpa, domenę prywatną czy publiczną. Certyfikaty weryfikują nazwy, dlatego konfigurowanie TLS przed ustaleniem nazw DNS często prowadzi do ostrzeżeń i zduplikowanych wpisów proxy.
Nie konfiguruj proxy dla aplikacji, do której nie możesz uzyskać bezpośredniego dostępu
Przed dodaniem hosta proxy otwórz aplikację backendową pod jej zwykłym adresem HTTP. Jeśli http://SERVER:PORT już nie działa, dodanie HTTPS tylko ukryje pierwotny problem za błędem proxy.
Użyj jednego pakietu aplikacji, zanim zbudujesz cały sklep
Sklep zewnętrzny jest przydatny, gdy utrzymujesz wiele aplikacji przeznaczonych do wielokrotnej instalacji. W przypadku jednej brakującej aplikacji niestandardowy Compose jest prostszy w testowaniu, aktualizowaniu i audytowaniu. Repozytorium warto budować dopiero wtedy, gdy potrzebujesz dystrybucji katalogu, metadanych, zasobów i powtarzalnych aktualizacji.
Sprawdź Compose przed publikacją
Aktualna dokumentacja dla deweloperów ZimaOS wymaga prawidłowego Docker Compose oraz metadanych x-casaos na najwyższym poziomie. Najpierw przetestuj stos Compose, a dopiero potem dodaj metadane katalogu; nie usuwaj jednocześnie usterek środowiska uruchomieniowego kontenerów i pakietowania sklepu.
Zachowaj prywatność interfejsu administracyjnego proxy
Jeśli wdrażasz Nginx Proxy Manager lub inne odwrotne proxy, jego interfejs administracyjny powinien pozostać dostępny wyłącznie w sieci LAN lub przez prywatną sieć VPN. Ruch publiczny powinien docierać tylko do przeznaczonych dla niego odbiorników HTTP/HTTPS proxy, a nie do portu zarządzania.
Nie udostępniaj też prywatnej aplikacji tylko dlatego, że masz już ważny certyfikat. TLS chroni transmisję, ale nie zastępuje uwierzytelniania ani kontroli dostępu do sieci.
FAQ
Czy HTTPS ZimaOS obejmuje wszystkie aplikacje?
Nie. Każdy punkt końcowy aplikacji potrzebuje własnego HTTPS lub odwrotnego proxy.
Czy mogę dodać dowolne repozytorium GitHub do App Store?
Nie. Musi to być zgodny sklep lub aplikacja spakowana jako Compose.
Czy do lokalnego HTTPS potrzebuję publicznej domeny?
Nie. Mogą wystarczyć wewnętrzny DNS i zaufane lokalne certyfikaty.
Jaki jest najłatwiejszy sposób instalacji jednej brakującej aplikacji?
Użyj aktualnej niestandardowej aplikacji Docker Compose.
