Comment auto-héberger Grocy en 2026 : données d’inventaire, fuseau horaire et sauvegardes

Considérez Grocy comme un petit système, et non comme une image Docker. L’objectif de Grocy côté utilisateur est clair : gérer l’inventaire domestique, les courses, les tâches et le matériel. Le déploiement n’est acceptable que lorsque vous pouvez remplacer les identifiants de connexion par défaut, ajouter un produit, enregistrer un achat et une consommation, scanner un code-barres et déclencher un rappel de tâche ou de date d’expiration.

Cette distinction permet d’identifier le problème que les opérateurs rencontrent après les tests locaux : la base de données SQLite ne peut pas être modifiée ou les tâches planifiées utilisent le mauvais fuseau horaire. Elle permet également de définir un plan de sauvegarde et de mise à niveau suffisamment précis pour être testé.

Ports, processus et services privés

Un schéma utile de Grocy montre la route publique, le port privé 80, la frontière des données persistantes et toutes les exigences complémentaires. Indiquez quelles flèches transportent des identifiants et lesquelles correspondent à un trafic utilisateur ordinaire. L’exigence du runtime local est un volume de configuration durable et, éventuellement, l’accès à un périphérique de lecture de codes-barres. Dimensionnez et surveillez cette ressource avec le conteneur au lieu d’exposer un service réseau sans rapport.

Validez le schéma avec une action réelle : remplacez les identifiants de connexion par défaut, ajoutez un produit, enregistrez un achat et une consommation, scannez un code-barres et déclenchez un rappel de tâche ou de date d’expiration. La charge provient probablement des écritures SQLite, des images importées, des tâches planifiées et du trafic des appareils domestiques ; surveillez ce chemin au lieu de traiter toutes les requêtes HTTP de la même manière.

Surveillez la charge de travail, pas uniquement le conteneur

Observez les opérations effectuées par Grocy : écritures SQLite, images importées, tâches planifiées et trafic des appareils domestiques. Définissez les limites en prévoyant une marge pour ces opérations et évitez une liveness probe qui les mettrait en concurrence. Le contrôle opérateur doit toujours tenter de remplacer les identifiants de connexion par défaut, d’ajouter un produit, d’enregistrer un achat et une consommation, de scanner un code-barres et de déclencher un rappel de tâche ou de date d’expiration selon une planification.

Pour les mises à jour, gardez à l’esprit que les migrations de la base de données Grocy et les extensions personnalisées doivent être répétées sur un répertoire de configuration copié. Déployez la version candidate sur une copie restaurée et répétez le test connu. Si la base de données SQLite ne peut pas être modifiée ou si les tâches planifiées utilisent le mauvais fuseau horaire, utilisez les logs du runtime et la requête réseau réelle pour déterminer quelle hypothèse a changé.

Ce qui doit être validé avant l’arrivée de vraies données Grocy

Une gate de production pour Grocy doit pouvoir être exécutée par une personne qui n’a pas réalisé le déploiement. Fournissez-lui la version épinglée, un compte de test non sensible et la tâche suivante : remplacer les identifiants de connexion par défaut, ajouter un produit, enregistrer un achat et une consommation, scanner un code-barres et déclencher un rappel de tâche ou de date d’expiration. Si les instructions nécessitent un accès shell non documenté, le service n’est pas encore prêt sur le plan opérationnel.

Répétez cette gate après avoir remplacé uniquement le conteneur. Restaurez ensuite la base de données, les fichiers importés, les recettes et la configuration dans une infrastructure vierge, puis vérifiez que le stock, les recettes, les tâches, le matériel et l’historique sont restaurés et que le prochain rappel planifié utilise la bonne date. Mesurez les écritures SQLite, les images importées, les tâches planifiées et le trafic des appareils domestiques pendant les deux exécutions réussies ; les différences inattendues révèlent souvent l’absence d’un cache, d’un index, d’un worker ou d’un montage de données.

Ajoutez un exercice de panne : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette frontière : la base de données SQLite ne peut pas être modifiée ou les tâches planifiées utilisent le mauvais fuseau horaire. Grocy doit produire une erreur utile, préserver l’état existant et récupérer lorsque la condition valide est rétablie. Enregistrez les horodatages et les lignes de log pertinentes, après avoir masqué les secrets. Ces éléments constituent la référence pour la prochaine modification de l’image ou de la configuration.

Créez un conteneur Grocy remplaçable

Utilisez une commande qui expose chaque choix important. Cette configuration de base lie Grocy à la loopback de l’hôte, ajoute les montages de données connus et fournit le premier paramètre requis. Confirmez l’exigence locale avant l’exposition : un volume de configuration durable et, éventuellement, l’accès à un périphérique de lecture de codes-barres.

docker run -d \
  --name grocy \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v grocy-data:/config \
  lscr.io/linuxserver/grocy:latest

Remplacez les tags flottants par une version testée ou un digest. Après le démarrage, inspectez docker logs --tail 200 grocy et confirmez que le processus écoute sur le port 80. Exécutez ensuite l’action d’acceptation Grocy ; une réponse de la page racine ne permet pas de prouver que le scénario complet fonctionne : remplacer les identifiants de connexion par défaut, ajouter un produit, enregistrer un achat et une consommation, scanner un code-barres et déclencher un rappel de tâche ou de date d’expiration.

Concevez la restauration de Grocy avant le lancement

Protégez les données de Grocy avant d’optimiser son conteneur. L’ensemble requis comprend la base de données, les fichiers importés, les recettes et la configuration. Montez /config avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Si plusieurs stockages doivent rester cohérents, documentez l’ordre dans lequel les écritures sont suspendues et les sauvegardes effectuées.

Conservez des copies en dehors du serveur de déploiement et chiffrez les éléments contenant des identifiants ou du contenu privé. La récupération est réussie lorsque le stock, les recettes, les tâches, le matériel et l’historique sont restaurés et que le prochain rappel planifié utilise la bonne date. La différence entre un montage persistant et une copie indépendante est expliquée dans stockage persistant et snapshots.

Testez Grocy depuis l’extérieur du serveur

Choisissez le hostname Grocy définitif avant que les utilisateurs n’enregistrent des callbacks ou des paramètres client, puis publiez l’interface via HTTPS et configurez le bon fuseau horaire. La route de la plateforme doit terminer TLS une seule fois et cibler le port privé 80.

Exécutez la transaction d’acceptation depuis l’extérieur. Si le client n’atteint jamais Grocy, utilisez la checklist de validation SSL pour vérifier le DNS et le certificat. Si la requête atteint Grocy mais que la base de données SQLite ne peut pas être modifiée ou que les tâches planifiées utilisent le mauvais fuseau horaire, cessez de modifier les redirections du proxy et inspectez plutôt la frontière spécifique à l’application.

Choisissez la frontière de confiance de Grocy

Modélisez les menaces liées à l’action effectuée par Grocy, et pas seulement à son formulaire de connexion. Dans ce cas, l’erreur à haut risque consiste à conserver les identifiants de connexion par défaut après la configuration initiale. Implémentez cette frontière : supprimez les identifiants par défaut, choisissez le bon fuseau horaire et limitez les données domestiques aux utilisateurs prévus.

Grocy ne nécessite aucun secret de bootstrap obligatoire dans cette configuration de base ; protégez plutôt son véritable compte administrateur ou l’authentification en amont. Ne résolvez pas une erreur de permissions en exécutant le conteneur en tant que root ou en montant largement l’hôte. Les limites de ressources font également partie de la conception de sécurité lorsque les utilisateurs peuvent déclencher des écritures SQLite, des images importées, des tâches planifiées et du trafic d’appareils domestiques.

Un déploiement Dockup nécessite toujours un test d’acceptation Grocy

Dockup peut prendre en charge les composants remplaçables de la plateforme : acheminer le trafic vers le port 80, fournir le domaine et le certificat, injecter les secrets, attacher le stockage persistant et connecter Grocy à des services gérés ou attachés en privé. Cela peut être réalisé sur l’infrastructure Dockup ou sur un serveur que vous rattachez.

Le travail d’acceptation Grocy reste explicite. Après le déploiement en un clic, publiez l’interface via HTTPS et configurez le bon fuseau horaire, confirmez l’exigence locale — un volume de configuration durable et, éventuellement, l’accès à un périphérique de lecture de codes-barres — puis exécutez ce scénario : remplacez les identifiants de connexion par défaut, ajoutez un produit, enregistrez un achat et une consommation, scannez un code-barres et déclenchez un rappel de tâche ou de date d’expiration. Cette séparation est intentionnelle : Dockup supprime les tâches répétitives de configuration de l’infrastructure sans prétendre que les rôles applicatifs, les identifiants des fournisseurs ou la stratégie de restauration se choisissent seuls.

Foire aux questions

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

Acheminez le conteneur Grocy sur le port 80 via une origine HTTPS unique. L’exigence du runtime local est un volume de configuration durable et, éventuellement, l’accès à un périphérique de lecture de codes-barres. Ne considérez pas Grocy comme prêt tant que vous ne pouvez pas remplacer les identifiants de connexion par défaut, ajouter un produit, enregistrer un achat et une consommation, scanner un code-barres et déclencher un rappel de tâche ou de date d’expiration.

Quelles données Grocy doivent figurer dans une sauvegarde ?

Conservez /config et incluez la base de données, les fichiers importés, les recettes et la configuration dans le même manifeste de récupération. Une restauration Grocy propre n’est réussie que lorsque le stock, les recettes, les tâches, le matériel et l’historique sont restaurés et que le prochain rappel planifié utilise la bonne date.

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

Utilisez HTTPS pour l’origine publique de Grocy et conservez le port 80 sur la route interne. Appliquez correctement le paramètre Grocy : publiez l’interface via HTTPS et configurez le bon fuseau horaire. Pour Grocy, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transfert et garantit un comportement cohérent des clients dépendant de l’origine.

Comment tester une mise à niveau de Grocy ?

Restaurez l’état actuel de Grocy dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de la base de données Grocy et les extensions personnalisées doivent être répétées sur un répertoire de configuration copié. Conservez l’image Grocy précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.