Le HTTPS du tableau de bord ZimaOS ne sécurise pas automatiquement toutes les applications Docker. Les applications qui écoutent sur leurs propres ports ont besoin d’un HTTPS natif ou d’un proxy inverse. L’URL aléatoire d’un dépôt GitHub n’est pas non plus une source valide pour l’App Store ZimaOS : le dépôt doit respecter le protocole actuel de la boutique.
Le fil source d’avril 2026 réunissait ces deux questions de débutants. La réponse claire consiste à les séparer : un proxy inverse pour le TLS des applications, une boutique compatible ou un fichier Compose personnalisé pour les logiciels absents.
Pourquoi le HTTPS du tableau de bord ne sécurise pas les applications
Le réglage HTTPS de ZimaOS protège le nom d’hôte du tableau de bord. Une application Docker accessible via http://SERVER:8080 reste un service distinct. Le guide du proxy inverse HTTPS explique cette distinction.
Utiliser un proxy inverse pour le HTTPS des applications
https://app.example.com
↓
Proxy inverse / TLS
↓
http://app-container:portNginx Proxy Manager ou Caddy peuvent gérer la terminaison TLS et transmettre les requêtes à une application.
Le HTTPS local et le HTTPS public sont différents
Pour un usage limité au réseau local, un DNS interne et une autorité de certification locale peuvent convenir. Les domaines publics nécessitent des certificats valides ainsi que des règles réfléchies d’accès distant et de sécurité.
Pourquoi une URL GitHub brute génère une erreur
L’App Store attend un contenu compatible avec le format de la boutique, et non le code source arbitraire d’une application.
Protocole actuel de l’App Store ZimaOS
Le guide destiné aux développeurs de l’App Store ZimaOS actuel définit une boutique v2 comprenant store-config.json, supported-languages.json, une arborescence Apps/ et un contenu dist/ généré.
Pour une seule application, utiliser Compose personnalisé
Si vous n’avez besoin que d’un seul projet, créer toute une boutique est inutile. Importez ou créez un fichier Docker Compose avec les ports, les volumes et les métadonnées x-casaos appropriés. La référence actuelle sur Docker Compose et x-casaos documente ce format.
Surveiller les ports 80 et 443
Les proxys inverses utilisent généralement les ports 80 et 443, qui peuvent déjà être occupés par ZimaOS. Vérifiez quel service les utilise avant le déploiement.
Choisir le nom du proxy inverse avant de configurer le TLS
Décidez si les utilisateurs ouvriront app.home.arpa, un domaine privé ou un domaine public. Les certificats valident les noms ; configurer le TLS avant de choisir les noms DNS entraîne souvent des avertissements et des entrées de proxy en double.
Ne proxifiez pas une application que vous ne pouvez pas joindre directement
Avant d’ajouter un hôte proxy, ouvrez l’application backend à son adresse HTTP habituelle. Si http://SERVER:PORT ne fonctionne déjà pas, l’ajout du HTTPS ne fera que masquer le problème initial derrière une erreur du proxy.
Utiliser un seul paquet d’application avant de créer toute une boutique
Une boutique tierce est utile lorsque vous gérez de nombreuses applications destinées à être installées régulièrement. Pour une seule application absente, un fichier Compose personnalisé est plus simple à tester, à mettre à jour et à auditer. Ne créez un dépôt que si vous avez besoin d’une distribution sous forme de catalogue, de métadonnées, de ressources et de mises à jour reproductibles.
Valider Compose avant la publication
La documentation actuelle destinée aux développeurs ZimaOS exige un Docker Compose valide ainsi que les métadonnées x-casaos au niveau racine. Testez d’abord la pile Compose, puis ajoutez les métadonnées du catalogue ; ne déboguez pas simultanément l’exécution des conteneurs et l’empaquetage pour la boutique.
Garder l’interface d’administration du proxy privée
Si vous déployez Nginx Proxy Manager ou un autre proxy inverse, l’interface d’administration doit rester accessible uniquement depuis le réseau local ou un VPN privé. Le trafic public doit atteindre uniquement les écouteurs HTTP/HTTPS prévus du proxy, et non le port de gestion.
De même, n’exposez pas une application privée simplement parce que vous disposez maintenant d’un certificat valide. Le TLS protège le transport ; il ne remplace ni l’authentification ni le contrôle des accès réseau.
FAQ
Le HTTPS de ZimaOS couvre-t-il toutes les applications ?
Non. Chaque point d’accès d’application a besoin de son propre HTTPS ou d’un proxy inverse.
Puis-je ajouter n’importe quel dépôt GitHub à l’App Store ?
Non. Il doit s’agir d’une boutique compatible ou d’une application empaquetée avec Compose.
Ai-je besoin d’un domaine public pour le HTTPS local ?
Non. Un DNS interne et des certificats locaux approuvés peuvent convenir.
Quelle est la manière la plus simple d’installer une application absente ?
Utiliser une application Docker Compose personnalisée et à jour.
