La version bêta de ZimaOS 1.7 a modifié la façon dont l’URL Web d’une tuile d’application pouvait être éditée : les utilisateurs pouvaient modifier le protocole, le port et le chemin, mais le nom d’hôte était lié à l’adresse du tableau de bord ZimaOS. Cela n’empêchait pas Nginx Proxy Manager ni le DNS local de fournir indépendamment un domaine personnalisé.
À l’époque, une réponse de l’équipe IceWhale confirmait que la modification du nom d’hôte n’était pas disponible dans l’éditeur visuel et indiquait que l’équipe prévoyait de la rétablir. La version actuelle de ZimaOS 1.7.1 améliore les paramètres de port des URL Web Docker et la gestion des URL, mais son journal des modifications publié n’indique pas explicitement que la modification arbitraire du nom d’hôte dans le formulaire visuel a été rétablie.
Ce qui a réellement changé avec la version bêta 1.7
L’utilisateur disposait d’une configuration DNS locale et d’un proxy inverse, par exemple https://app.example.net/. Dans l’éditeur de la version bêta, la tuile de l’application ne pouvait plus être configurée pour ouvrir ce nom d’hôte personnalisé.
Une reproduction publiée par la communauté a montré que la définition manuelle de x-casaos.hostname pouvait rester présente dans le YAML, tandis que le formulaire et la tuile de l’application continuaient d’utiliser l’adresse IP du tableau de bord. Le personnel d’IceWhale a ensuite confirmé que le champ visuel du nom d’hôte était temporairement indisponible.
Votre proxy inverse peut toujours utiliser le domaine personnalisé
La limitation décrite dans le fil de discussion concernait l’URL ouverte par la tuile d’application de ZimaOS, et non la possibilité pour Nginx Proxy Manager, AdGuard Home ou une autre pile DNS/proxy inverse d’acheminer un nom d’hôte personnalisé vers le port publié de l’application.
Si votre proxy redirige déjà un domaine vers la bonne adresse IP ZimaOS et le port de l’application, maintenez ce chemin de proxy séparé du paramètre de la tuile du tableau de bord. Le guide du proxy inverse HTTPS de ZimaOS présente cette architecture.
Ce que confirme ZimaOS 1.7.1
Le journal des modifications de ZimaOS 1.7.1 officiel mentionne une configuration plus flexible des ports d’URL Web ainsi qu’une meilleure gestion des URL Docker. Il ne documente pas spécifiquement le rétablissement de l’ancien éditeur de nom d’hôte.
La référence actuelle des métadonnées des applications ZimaOS documente port_map, scheme et index pour les URL d’accès aux applications. Testez l’éditeur stable actuel avant de reconstruire une configuration de proxy existante en vous basant sur un ancien comportement de la version bêta.
Devez-vous revenir à une version antérieure depuis la version bêta ?
Pour ce problème précis, les conseils publiés sur le forum recommandaient de ne pas se précipiter vers une restauration, puisque les domaines personnalisés continuaient de fonctionner via le proxy inverse. Aujourd’hui, la meilleure première étape consiste à passer à la version stable actuelle de ZimaOS, à sauvegarder la configuration des applications et à vérifier le comportement des tuiles d’application sur cette version.
Si vous importez ou corrigez un fichier YAML d’application, le guide Docker Compose personnalisé constitue une référence plus sûre que la copie inchangée d’une solution de contournement datant de la version bêta.
