Raspberry Pi 5 : plateforme de services auto-hébergés

Le contexte

Je voulais disposer d’un serveur compact, silencieux et peu énergivore pour héberger des services réellement utilisés au quotidien. Contrairement à un laboratoire construit pour une démonstration ponctuelle, cette plateforme doit rester disponible, lisible et simple à maintenir.

Le Raspberry Pi 5 héberge aujourd’hui quinze conteneurs. Certains services fonctionnent seuls, tandis que d’autres — comme Immich ou Nextcloud — reposent sur plusieurs composants applicatifs et bases de données.

L’objectif

Construire une petite plateforme d’exploitation personnelle capable de répondre à quatre besoins :

• centraliser plusieurs services dans des stacks Docker Compose ;
• surveiller leur disponibilité et les ressources de l’hôte ;
• consulter rapidement les journaux des conteneurs ;
• conserver un accès maîtrisé depuis le réseau local ou à distance.

Les services hébergés

La plateforme regroupe plusieurs usages complémentaires :

• réseau : AdGuard Home pour le DNS et le filtrage ;
• sécurité : Vaultwarden pour la gestion personnelle des mots de passe ;
• données : Nextcloud pour le stockage et la synchronisation ;
• photos : Immich et ses composants associés ;
• médias : Jellyfin ;
• exploitation : Dockge, Uptime Kuma, Netdata, Dozzle et un tableau de bord central.

Conteneurisation et administration

Les services sont décrits avec Docker Compose puis administrés depuis Dockge. Cette organisation permet de distinguer chaque stack, de retrouver sa configuration et de redémarrer ou mettre à jour un service sans intervenir sur l’ensemble de la plateforme.

Le tableau de bord central est accessible sur le réseau local et via Tailscale. Il sert de point d’entrée unique vers les outils d’exploitation et les applications personnelles.

Une supervision à trois niveaux

J’ai volontairement séparé trois besoins qui sont souvent confondus :

• Uptime Kuma vérifie si un service répond et conserve son historique de disponibilité ;
• Netdata mesure la santé du Raspberry Pi : processeur, mémoire, stockage, réseau et processus ;
• Dozzle centralise les journaux Docker et permet de passer rapidement d’un conteneur à l’autre lors d’un diagnostic.

Cette combinaison permet de répondre successivement à trois questions : le service est-il accessible, l’hôte manque-t-il de ressources, et que disent les journaux ?

Sauvegarde : état réel du chantier

Le conteneur Backrest est installé pour piloter des sauvegardes Restic, mais cette partie n’est pas encore considérée comme opérationnelle. La stratégie de sauvegarde, la rétention et surtout un scénario de restauration doivent encore être configurés puis testés avant de pouvoir parler de sauvegarde en production.

Je préfère donc présenter ce point comme un travail en cours plutôt que comme une garantie non vérifiée.

Le résultat

Cette plateforme me permet d’exploiter des services concrets tout en travaillant la conteneurisation, la supervision, le réseau et le diagnostic. Les outils ne sont pas installés pour remplir une liste : chacun répond à un besoin identifiable dans l’exploitation quotidienne.

Les prochaines étapes

• finaliser la stratégie Restic/Backrest et effectuer une restauration complète ;
• formaliser un schéma simple des flux et des dépendances ;
• documenter la procédure de reprise de la plateforme ;
• consolider la routine de mise à jour et de contrôle des services.

Ce que j’en retiens

Auto-héberger un service ne consiste pas seulement à le démarrer. Il faut aussi pouvoir constater qu’il ne répond plus, comprendre pourquoi, restaurer ses données et expliquer comment il dépend du reste de l’environnement.