O HTTPS do painel do ZimaOS não protege automaticamente todas as aplicações Docker. As aplicações que escutam nas suas próprias portas precisam de HTTPS nativo ou de um proxy inverso. Um URL aleatório de um repositório do GitHub também não é uma fonte válida para a App Store do ZimaOS — o repositório tem de seguir o protocolo atual da loja.
O tópico de origem de abril de 2026 combinava estas duas perguntas de principiante. A resposta simples é separá-las: use um proxy inverso para o TLS da aplicação e uma loja compatível ou o Compose personalizado para software em falta.
Porque é que o HTTPS do painel não protege as aplicações
A definição de HTTPS do ZimaOS protege o nome de anfitrião do painel. Uma aplicação Docker em http://SERVER:8080 continua a ser um serviço separado. O guia de proxy inverso HTTPS explica esta separação.
Utilize um proxy inverso para o HTTPS da aplicação
https://app.example.com
↓
Proxy inverso / TLS
↓
http://app-container:portO Nginx Proxy Manager ou o Caddy podem terminar o TLS e encaminhar o tráfego para uma aplicação.
O HTTPS local e o HTTPS público são diferentes
Para utilização apenas na LAN, o DNS interno e uma AC local podem funcionar. Os domínios públicos precisam de certificados válidos e de regras de acesso remoto e segurança definidas de forma deliberada.
Porque é que um URL direto do GitHub apresenta um erro
A App Store espera dados de saída de uma loja compatível, não código-fonte arbitrário de uma aplicação.
Protocolo atual da App Store do ZimaOS
O atual guia do programador da App Store do ZimaOS define uma loja v2 com store-config.json, supported-languages.json, uma árvore Apps/ e dados de saída dist/ gerados.
Para uma aplicação, utilize o Compose personalizado
Se só precisa de um projeto, não é necessário criar uma loja completa. Importe ou crie um Docker Compose com as portas, os volumes e os metadados x-casaos corretos. A atual referência do Docker Compose e do x-casaos documenta o formato.
Tenha atenção às portas 80 e 443
Os proxies inversos utilizam frequentemente as portas 80/443, que podem já estar a ser utilizadas pelo ZimaOS. Verifique quem as controla antes da implementação.
Escolha o nome do proxy inverso antes de configurar o TLS
Decida se os utilizadores vão abrir app.home.arpa, um domínio privado ou um domínio público. Os certificados validam nomes, por isso configurar o TLS antes de decidir os nomes DNS conduz frequentemente a avisos e a entradas de proxy duplicadas.
Não faça proxy de uma aplicação à qual não consegue aceder diretamente
Antes de adicionar um anfitrião proxy, abra a aplicação de backend no seu endereço HTTP normal. Se http://SERVER:PORT já não funcionar, adicionar HTTPS apenas irá ocultar o problema original atrás de um erro do proxy.
Utilize primeiro um pacote de aplicação antes de criar uma loja completa
Uma loja de terceiros é útil quando mantém várias aplicações para instalações repetidas. Para uma única aplicação em falta, o Compose personalizado é mais simples de testar, atualizar e auditar. Crie um repositório apenas quando precisar de distribuição por catálogo, metadados, recursos e atualizações repetíveis.
Valide o Compose antes de publicar
A documentação atual para programadores do ZimaOS espera um Docker Compose válido, juntamente com os metadados x-casaos de nível superior. Teste primeiro a pilha Compose e só depois adicione os metadados do catálogo; não depure o ambiente de execução dos contentores e o empacotamento da loja ao mesmo tempo.
Mantenha privada a interface de administração do proxy
Se implementar o Nginx Proxy Manager ou outro proxy inverso, a interface de administração deve permanecer na LAN ou numa VPN privada. O tráfego público deve chegar apenas aos escutadores HTTP/HTTPS previstos do proxy, e não à porta de gestão.
Da mesma forma, não exponha uma aplicação privada apenas porque agora tem um certificado válido. O TLS protege o transporte; não substitui a autenticação nem o controlo de acesso à rede.
Perguntas frequentes
O HTTPS do ZimaOS abrange todas as aplicações?
Não. Cada endpoint de aplicação precisa do seu próprio HTTPS ou de um proxy inverso.
Posso adicionar qualquer repositório do GitHub à App Store?
Não. Tem de ser uma loja compatível ou uma aplicação empacotada como Compose.
Preciso de um domínio público para o HTTPS local?
Não. O DNS interno e certificados locais fidedignos podem funcionar.
Qual é a forma mais simples de instalar uma aplicação em falta?
Utilize uma aplicação Docker Compose personalizada atual.
