Comment auto-héberger Homepage en 2026 : hôtes autorisés, widgets et configuration

Il existe deux versions de « faire fonctionner Homepage » : un conteneur existe, ou le service remplit réellement sa fonction. Seule la seconde compte. Ici, la preuve consiste à charger les services et les favoris, à appeler plusieurs widgets actifs, à tester la recherche et à redémarrer après avoir modifié un fichier de configuration YAML.

Homepage sert à cela : fournir une page de démarrage avec des widgets actifs pour les services auto-hébergés. Le déploiement doit préserver les éléments qui permettent ce comportement ; un port, un volume et un certificat sont des prérequis, pas le résultat.

Choisir la topologie Homepage viable la plus simple

Un schéma utile de Homepage montre la route publique, le port privé 3000, la limite des données persistantes et toutes les dépendances nécessaires. Indiquez quelles flèches transportent des identifiants et lesquelles correspondent à du trafic utilisateur ordinaire. La dépendance externe de Homepage consiste en une configuration en lecture seule et des identifiants pour les widgets de services facultatifs. Testez le DNS sortant, TLS et le comportement des fournisseurs sans publier un autre service entrant.

Prouvez le schéma avec une action réelle : chargez les services et les favoris, appelez plusieurs widgets actifs, testez la recherche et redémarrez après avoir modifié un fichier de configuration YAML. Les principaux points de pression viennent probablement de la multiplication des appels des widgets, de la lenteur des API en aval, de la résolution DNS et de la fréquence d’actualisation du tableau de bord dans le navigateur ; surveillez ce parcours plutôt que de considérer toutes les requêtes HTTP comme équivalentes.

Mettre Homepage à niveau sans deviner

La première métrique opérationnelle utile pour Homepage est sa capacité à charger les services et les favoris, à appeler plusieurs widgets actifs, à tester la recherche et à redémarrer après la modification d’un fichier de configuration YAML. Associez-la aux signaux de saturation liés à la multiplication des appels des widgets, à la lenteur des API en aval, à la résolution DNS et à la fréquence d’actualisation du tableau de bord dans le navigateur. Une probe limitée au processus ne doit pas appeler de dépendances coûteuses ni redémarrer le conteneur parce qu’un service en amont est momentanément indisponible.

Traitez les mises à niveau comme des changements de données, car les clés de configuration et les intégrations de widgets peuvent évoluer ; validez donc le YAML et le comportement des fournisseurs avant de mettre à jour l’image. Épinglez les versions, répétez la procédure sur un état restauré et conservez l’ancienne image jusqu’à ce qu’un rollback reste possible. Lorsque l’hôte est rejeté ou qu’une indentation YAML empêche le chargement de la configuration, conservez les logs précédant le redémarrage ; ils contiennent généralement le message indiquant la cause.

Procédure d’acceptation de production pour Homepage

Avant l’arrivée des utilisateurs réels, préparez une fiche de mise en production pour Homepage. Elle doit indiquer l’image épinglée, le port 3000, l’origine canonique, les chemins persistants et le responsable de la configuration en lecture seule ainsi que des identifiants pour les widgets de services facultatifs. Joignez le résultat attendu de cette transaction : charger les services et les favoris, appeler plusieurs widgets actifs, tester la recherche et redémarrer après avoir modifié un fichier de configuration YAML.

Utilisez cette fiche après un remplacement normal et après une restauration complète. La récupération n’est validée que si les services, les favoris, les widgets et les ressources personnalisées sont rétablis et que tous les widgets critiques gèrent visiblement les défaillances des services en aval. Recueillez également une courte trace des ressources couvrant la multiplication des appels des widgets, la lenteur des API en aval, la résolution DNS et la fréquence d’actualisation du tableau de bord dans le navigateur ; conservez-la avec la mise en production afin que les futures évolutions de capacité soient comparées à la même charge.

Incluez une défaillance contrôlée : refusez temporairement le chemin de test utilisé par la configuration en lecture seule et les identifiants des widgets de services facultatifs. Vérifiez que Homepage signale le problème à la bonne limite, rétablissez la condition valide et relancez la transaction. Cela vérifie la visibilité des erreurs, et pas seulement le succès, et empêche une interface apparemment saine de dissimuler un worker, un callback ou une connexion à une base de données défaillant.

Rendre le démarrage de Homepage reproductible

Utilisez le conteneur comme un runtime remplaçable, et non comme l’emplacement de référence.

docker run -d \
  --name homepage \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v homepage-data:/app/config \
  -e HOMEPAGE_ALLOWED_HOSTS=home.example.com \
  ghcr.io/gethomepage/homepage:latest

Autorisez et vérifiez le chemin sortant ou côté client requis par la configuration en lecture seule et les identifiants des widgets de services facultatifs. Inspectez l’utilisateur du conteneur, les chemins accessibles en écriture et le listener exposé avant de publier le service. Exécutez l’action complète — charger les services et les favoris, appeler plusieurs widgets actifs, tester la recherche et redémarrer après avoir modifié un fichier de configuration YAML — puis enregistrez la référence exacte de l’image qui a produit ce résultat.

Séparer les conteneurs remplaçables des données persistantes

L’ensemble de récupération durable comprend les fichiers de configuration, les favoris, les services et les ressources personnalisées. Montez /app/config avant l’amorçage, écrivez des exemples de données inoffensifs et remplacez le conteneur pour prouver que ce chemin est réellement persistant. Un volume protège les données contre le remplacement du conteneur, mais pas contre la perte de l’hôte, une suppression accidentelle ou une corruption au niveau de l’application.

Effectuez des sauvegardes qui tiennent compte de la source de données : utilisez des dumps logiques pour les bases de données actives lorsque nécessaire et ne copiez les fichiers qu’à partir d’un état cohérent. Conservez une copie chiffrée ailleurs que sur l’hôte Homepage. Le critère d’acceptation d’une restauration est précis : les services, les favoris, les widgets et les ressources personnalisées sont rétablis, et tous les widgets critiques gèrent visiblement les défaillances des services en aval. Le guide des sauvegardes testées par restauration explique pourquoi la réussite d’une tâche ne suffit pas.

Domaines, en-têtes du proxy et port 3000

Le navigateur, le client API et Homepage doivent utiliser une seule origine. Pour y parvenir, définissez les hôtes autorisés pour le domaine exact et le nom d’hôte du proxy. Préservez l’hôte et le protocole d’origine tout en empêchant l’accès au port 3000 comme adresse publique concurrente.

Le guide de dépannage d’un site inaccessible aide à distinguer une route injoignable d’une application qui répond. Cette distinction est importante ici : l’hôte est rejeté ou l’indentation YAML empêche le chargement de la configuration. Seul le premier problème se corrige par des changements au niveau de l’ingress ; le second nécessite d’inspecter les logs, l’état ou la charge de travail de Homepage.

Décisions de sécurité propres à Homepage

N’appliquez pas automatiquement les hypothèses de sécurité d’un tutoriel local. Le problème propre à Homepage est de committer des clés d’API de widgets dans un dépôt public. En production, définissez donc précisément les hôtes autorisés et conservez les clés d’API des widgets dans l’environnement ou une configuration adossée à des secrets, plutôt que dans un dépôt public.

HOMEPAGE_ALLOWED_HOSTS contrôle le comportement, pas la confidentialité ; validez son type et sa valeur, et stockez séparément les véritables identifiants Homepage. Limitez les accès au système de fichiers et au réseau, protégez les endpoints de configuration et définissez des limites d’upload, de requêtes ou d’exécution autour de la multiplication des appels des widgets, de la lenteur des API en aval, de la résolution DNS et de la fréquence d’actualisation du tableau de bord dans le navigateur.

Là où Dockup simplifie le travail pour Homepage

Pour Homepage, Dockup est particulièrement utile à la frontière entre une image et un service durable. Il conserve la route vers le port 3000, TLS, les valeurs secrètes et le stockage lors des remplacements de conteneurs, que le calcul soit assuré par Dockup ou par votre serveur associé.

Terminez avec les connaissances propres à l’application : définissez les hôtes autorisés pour le domaine exact et le nom d’hôte du proxy ; autorisez et vérifiez la configuration en lecture seule ainsi que les identifiants des widgets de services facultatifs ; puis exécutez cette vérification : chargez les services et les favoris, appelez plusieurs widgets actifs, testez la recherche et redémarrez après avoir modifié un fichier de configuration YAML. Conservez le résultat comme contrôle de déploiement afin que la prochaine mise à jour de l’image soit évaluée sur son comportement plutôt que sur l’état du conteneur.

Foire aux questions

De quoi Homepage a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Homepage sur le port 3000 via une seule origine HTTPS. La dépendance externe pour la diffusion consiste en une configuration en lecture seule et des identifiants pour les widgets de services facultatifs. Ne considérez pas Homepage comme prêt tant que vous ne pouvez pas charger les services et les favoris, appeler plusieurs widgets actifs, tester la recherche et redémarrer après avoir modifié un fichier de configuration YAML.

Quelles données de Homepage doivent figurer dans une sauvegarde ?

Rendez /app/config persistant et incluez les fichiers de configuration, les favoris, les services et les ressources personnalisées dans le même manifeste de récupération. Une restauration Homepage complète n’est validée que lorsque les services, les favoris, les widgets et les ressources personnalisées sont rétablis et que tous les widgets critiques gèrent visiblement les défaillances des services en aval.

Homepage nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Homepage et conservez le port 3000 sur la route interne. Appliquez correctement le paramètre Homepage : définissez les hôtes autorisés pour le domaine exact et le nom d’hôte du proxy. Pour Homepage, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transmission et garantit la cohérence du comportement client sensible à l’origine.

Comment tester une mise à niveau de Homepage ?

Restaurez l’état actuel de Homepage dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les clés de configuration et les intégrations de widgets peuvent évoluer ; validez donc le YAML et le comportement des fournisseurs avant de mettre à jour l’image. Conservez l’ancienne image Homepage jusqu’à ce que les limites de migration des données et de rollback soient comprises.