Les benchmarks d'auto-hébergement d'Immich révèlent des besoins élevés en RAM et des exigences critiques de sauvegarde

Les passionnés d'auto-hébergement souhaitant remplacer Google Photos par Immich font face à des compromis matériels et opérationnels importants, selon une récente analyse de déploiement publiée le 30 octobre 2026. La revue souligne que si la plateforme open source offre de puissantes fonctionnalités d'apprentissage automatique, elle exige nettement plus de ressources système que les applications auto-hébergées légères typiques. Les utilisateurs doivent se préparer à une configuration complexe impliquant plusieurs conteneurs, des politiques de mots de passe strictes et des procédures de sauvegarde rigoureuses pour éviter toute perte de données.

Ce qui s'est passé

L'auteur a déployé Immich version 3 sur une station de travail équipée d'un processeur Intel Core Ultra 7 255H, de 30 Go de RAM et d'un stockage NVMe sous Ubuntu 24.04.5 LTS. L'objectif était de mesurer la consommation réelle de ressources de la pile, qui comprend le serveur principal, un service d'apprentissage automatique, VectorChord pour Postgres et Valkey. Contrairement à des outils plus simples comme Vaultwarden ou Uptime Kuma, qui fonctionnent dans quelques mégaoctets de mémoire, Immich s'est avéré être une application lourde. Le jeu de travail mesuré s'est stabilisé à environ 2,4 Go de RAM, avec des pics notables lors des tâches de traitement ML telles que la génération de miniatures et la création d'embeddings.

Au-delà de l'utilisation brute des ressources, le déploiement a révélé plusieurs pièges opérationnels pouvant casser l'installation ou compromettre la sécurité. L'auteur a noté que le fichier Docker Compose change fréquemment entre les versions en raison du cycle de développement rapide du projet. Simplement tirer les nouvelles images sans mettre à jour la configuration Compose peut entraîner des échecs. De plus, le composant de base de données n'est pas jetable ; il contient toutes les métadonnées, les albums, les données de reconnaissance faciale et l'historique des modifications. Cela rend indispensable des sauvegardes régulières du dossier bibliothèque et d'un dump Postgres avant d'importer de grandes collections de photos.

Détails clés

• Exigences mémoire : La pile nécessite au moins 4 Go de RAM disponible pour fonctionner de manière fiable, avec une utilisation de base d'environ 2,4 Go et des pics plus élevés lors des tâches ML.
• Complexité de la base de données : Postgres stocke des métadonnées critiques et ne peut pas être traité comme éphémère ; les utilisateurs doivent sauvegarder à la fois le dump de la base de données et le dossier bibliothèque.
• Restrictions de mots de passe : Les caractères spéciaux dans la variable d'environnement DB_PASSWORD cassent la chaîne de connexion, nécessitant des mots de passe alphanumériques uniquement malgré les avertissements standards.
• Volatilité de la configuration : Le fichier Docker Compose officiel est mis à jour fréquemment, ce qui impose un téléchargement frais pour chaque mise à niveau plutôt que simplement tirer de nouvelles images de conteneurs.
• Sécurité réseau : Les fonctions de sauvegarde mobile nécessitent HTTPS via un proxy inverse ou un tunnel sécurisé comme Tailscale, car exposer le service directement sur Internet est dangereux.
• Services optionnels : Le service d'apprentissage automatique peut être supprimé pour le matériel moins puissant, bien que cela désactive la recherche intelligente et les fonctionnalités de reconnaissance faciale.

Contexte

Immich a gagné en popularité comme alternative auto-hébergée à Google Photos, affichant plus de 115 000 étoiles GitHub. Il fournit des applications mobiles avec des capacités de sauvegarde automatique et utilise l'apprentissage automatique pour permettre la recherche en langage naturel, comme trouver des photos en décrivant « coucher de soleil sur l'eau ». Cette fonctionnalité repose sur la génération d'embeddings pour les images, un processus intensif en calculs comparé au simple stockage de fichiers. Alors que de nombreux outils auto-hébergés sont conçus pour tourner sur des serveurs privés virtuels minimaux, l'architecture d'Immich reflète la nature gourmande en ressources des services cloud commerciaux, déplaçant le coût des frais d'abonnement vers la capacité matérielle locale.

La distinction entre une visionneuse de galerie et une solution complète de sauvegarde est cruciale dans ce contexte. Google Photos offrait durabilité et redondance hors site, tandis qu'une instance Immich auto-hébergée représente un point unique de défaillance sauf si correctement sauvegardée. La règle de sauvegarde « 3-2-1 » — conserver trois copies des données, sur deux supports différents, dont une hors site — s'applique strictement ici. Sans une sauvegarde hors site de la base de données et de la bibliothèque, le serveur n'est qu'une seconde copie des données sur un matériel géré par l'utilisateur, et non un véritable filet de sécurité contre la panne matérielle ou les ransomwares.

Pourquoi c'est important

Pour les responsables IT et les développeurs gérant des infrastructures à petite échelle, comprendre le coût réel de l'auto-hébergement d'applications complexes est vital. Immich démontre que les logiciels « gratuits » entraînent souvent des coûts cachés en termes de spécifications matérielles et de charge de maintenance. Un VPS standard de 1 Go ou une option PaaS gratuite est insuffisant pour cette charge de travail. Les équipes envisageant de telles migrations doivent évaluer si leur matériel existant, tel qu'une VM Oracle gratuite avec 12 Go de RAM, peut soutenir la charge continue du traitement ML en arrière-plan et des opérations de base de données.

De plus, la discipline opérationnelle requise pour Immich dépasse celle des applications stateless plus simples. La nécessité de gérer les schémas de base de données, de traiter les changements cassants dans les fichiers de configuration et de sécuriser les canaux d'accès distants ajoute à la charge administrative. Pour les organisations ou particuliers ayant une disponibilité intermittente de labo domestique, le risque d'échecs de synchronisation des données augmente. Si le serveur est hors ligne lorsque les appareils mobiles tentent de se synchroniser, l'utilité de la sauvegarde est annulée. Cela rend Immich adapté uniquement aux environnements toujours actifs avec une connectivité électrique et réseau robuste.

Ce que vous pouvez faire

• Auditer les ressources matérielles : Assurez-vous que votre serveur dispose d'au moins 4 Go de RAM libre et d'un stockage NVMe suffisant avant de commencer le déploiement.
• Mettre en œuvre des sauvegardes strictes : Configurez des scripts automatisés pour effectuer à la fois des opérations pg_dump et des sauvegardes au niveau fichier du dossier bibliothèque vers un emplacement hors site.
• Sécuriser l'accès distant : Utilisez un proxy inverse avec des certificats TLS valides ou un outil de réseau maillé comme Tailscale pour activer les sauvegardes mobiles sans exposer les ports sur Internet public.
• Suivre les protocoles de mise à niveau : Téléchargez toujours le dernier fichier Docker Compose officiel depuis le tag de release spécifique lors des mises à niveau, plutôt que de compter sur des configurations en cache.
• Valider les identifiants : Utilisez uniquement des caractères alphanumériques pour les mots de passe de base de données afin d'éviter les erreurs d'analyse de la chaîne de connexion lors de la configuration initiale.
• Envisager la réduction d'échelle : Si vous tournez sur du matériel limité, désactivez le service d'apprentissage automatique pour réduire l'utilisation de la RAM, en acceptant la perte des capacités de recherche intelligente.