Serveur

Accès à distance

Accéder à la maison depuis l’extérieur, en sécurité.

Règle de base : un serveur hébergé sur Internet n'a pas accès aux radios USB (coordinateur Zigbee, radio Thread, Bluetooth) ni au réseau local de votre maison (mDNS, IPv6 local de Matter, appareils MQTT et Wi-Fi). Les intégrations doivent donc tourner à la maison.

Les trois scénarios

1. Installation entièrement locale (déploiement actuel)

[Maison] Serveur My Habita (moteur, Zigbee2MQTT, Matter, MQTT, nginx) ── appareils

• Tout tourne à la maison : intégrations, automatisations, alarme, chauffage, historique, interface.
• Sans Internet, tout continue de fonctionner, sauf : les notifications vers ntfy.sh ou d'autres services externes, la vérification en ligne des certificats Matter (DCL, une copie hors ligne est embarquée), les mises à jour OTA Matter, et la synchronisation de l'heure (NTP). L'horloge de la VM reste juste à court terme.
• Accès uniquement depuis le réseau local.

2. Installation locale avec accès distant sécurisé (recommandé pour sortir de chez soi)

[Téléphone hors de la maison] ══ tunnel chiffré ══ [Maison] serveur My Habita

Rien ne change sur le fonctionnement : tout reste à la maison. Seul l'accès est étendu. Options, de la plus simple à la plus maîtrisée :

Avec un VPN, utilisez https:// et le certificat local (voir docs/exploitation.md). N'ouvrez jamais directement les ports 80, 443 ou 1883 sur Internet.

3. Serveur distant associé à une passerelle locale

[Hébergement distant] interface, tableau de bord, copie de l'historique   ⇄   [Maison] passerelle : intégrations, automatisations

• La passerelle locale reste indispensable : coordinateur Zigbee, Matter, MQTT local, et surtout automatisations, alarme et chauffage, pour continuer à fonctionner sans Internet.
• Le serveur distant ne serait qu'une vitrine (tableaux de bord, historique, notifications) reliée à la passerelle par un lien sortant chiffré (WireGuard, ou MQTT sur TLS avec pont de broker).
• Ce scénario n'est pas implémenté dans cette version. L'architecture s'y prête : API v1 et WebSocket, et Mosquitto sait faire des ponts entre brokers. Il n'apporte rien tant qu'un VPN (scénario 2) suffit.

Votre hébergement Plesk

Ce qui a été vérifié dans la documentation officielle (le 18/10/2026) :

• Plesk exécute les applications Node.js via Phusion Passenger. Passenger démarre l'application à la première requête et arrête les processus inactifs (5 min par défaut). Il impose un seul serveur HTTP, sans port libre.
• L'extension Docker n'existe que si l'administrateur Plesk l'a installée, en pratique sur un VPS ou un serveur dédié et non sur un hébergement mutualisé.
• Plesk ne documente ni la durée de vie des processus, ni les connexions sortantes, ni les ports sur un hébergement mutualisé : cela dépend de l'hébergeur.

Conséquences :

Avant tout projet sur Plesk, vérifiez sur votre offre :

1. la présence de l'extension Docker ou d'un accès SSH root ;
2. le maintien des processus Node.js (réglage passenger_min_instances, PassengerPoolIdleTime 0, non garanti selon les retours d'utilisateurs) ;
3. les connexions sortantes autorisées ;
4. les WebSocket à travers le proxy.

Plesk n'est pas une dépendance du déploiement actuel.

Ce qui continue de fonctionner sans Internet (scénarios 1 et 2)