Héberger PhotoPrism sur votre propre VPS

Là où Immich vise l'expérience cloud complète avec sauvegarde mobile temps réel, PhotoPrism privilégie l'indexation et l'organisation d'une photothèque existante, souvent volumineuse, posée sur un système de fichiers. Il analyse vos dossiers, classe les photos par labels (montagne, plage, voiture), détecte les visages, lit les EXIF et géocode les clichés. Tout cela s'exécute localement via TensorFlow embarqué. L'héberger sur un VPS a un double intérêt : centraliser des archives photo dispersées sur un disque accessible partout, et bénéficier d'un étiquetage automatique sans jamais transmettre les images à un service tiers. PhotoPrism fonctionne avec MariaDB pour de bonnes performances et lit directement un dossier originals que vous remplissez par WebDAV, rsync ou montage.

PhotoPrism est gourmand en mémoire dès que TensorFlow entre en jeu. Voici les seuils à respecter pour éviter les mauvaises surprises. Sans GPU et avec le moteur ML actif, comptez 2 Go de RAM minimum : en dessous, le processus d'indexation déclenche un OOM (out of memory) et le conteneur redémarre en boucle. Avec le ML pleinement actif (détection de visages, classification de scènes), 4 Go de RAM sont recommandés — c'est le palier confort pour une bibliothèque de 10 000 à 50 000 photos. Un vCPU minimum suffit pour naviguer, mais l'indexation initiale d'une grande archive tire parti de 2 à 4 cœurs : PhotoPrism distribue le travail via PHOTOPRISM_WORKERS. Le port par défaut est 2342 ; pensez à l'ouvrir temporairement pour un premier test avant de placer le reverse proxy. Côté stockage, provisionnez vos originals (la taille réelle de votre bibliothèque) plus 30 à 40 % pour les miniatures multi-résolutions, le cache et l'index MariaDB. Une bibliothèque de 100 Go d'originaux génère généralement entre 20 et 35 Go de données dérivées. Ajoutez une partition de swap de 2 Go minimum si votre VPS a moins de 4 Go de RAM : elle absorbe les pics d'indexation sans crash, au prix d'une légère lenteur.

PhotoPrism ne propose pas d'application native de sauvegarde automatique comme Immich, mais son interface PWA (Progressive Web App) est optimisée pour mobile : ajoutez-la à l'écran d'accueil depuis Safari (iOS) ou Chrome (Android) pour une expérience quasi-native. Pour la consultation et la recherche, c'est suffisant. Si vous souhaitez un accès hors réseau local, activez le HTTPS (voir l'étape reverse proxy) : la PWA ne s'installe qu'en contexte sécurisé. Pour la sauvegarde depuis le téléphone, la solution complémentaire habituelle est Syncthing ou rclone : configurez-les pour envoyer le dossier DCIM vers /opt/photoprism/originals sur le VPS, puis planifiez une ré-indexation automatique via un cron qui exécute docker compose exec -T photoprism photoprism index --cleanup.

Sur un VPS standard (pas de GPU dédié), TensorFlow tourne en mode CPU. Trois variables d'environnement permettent d'ajuster le rapport qualité/ressources. PHOTOPRISM_WORKERS contrôle le nombre de threads d'indexation parallèles — mettez-le au nombre de vCPU disponibles (2 ou 4) pour accélérer l'indexation initiale sans saturer le CPU. Sur un VPS à 1 vCPU, forcez-le à 1 pour éviter la contention. PHOTOPRISM_DISABLE_TENSORFLOW (valeur true) désactive entièrement le moteur ML : plus de classification automatique ni de détection de visages, mais l'indexation est significativement plus rapide pour l'indexation et la consommation RAM chute à moins d'1 Go. Utile pour une migration initiale d'une très grosse archive — réactivez ensuite le ML pour relancer l'analyse. PHOTOPRISM_DETECT_NSFW (valeur true) active le filtre de contenu inapproprié, au prix d'un passage supplémentaire du modèle sur chaque image : ne l'activez que si vous en avez réellement besoin, car il alourdit l'indexation. Pour les VPS entre 2 et 4 Go de RAM, la configuration recommandée est PHOTOPRISM_WORKERS=2, PHOTOPRISM_DETECT_NSFW=false et TensorFlow actif — vous obtenez le ML sans risque d'OOM.

OOM (Out of Memory) dès le démarrage ou pendant l'indexation. C'est la première erreur sur les VPS à 1 Go de RAM. La signature dans les logs Docker : Killed ou signal: killed sur le processus photoprism. Solution immédiate : ajouter du swap (fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile) et ajouter la ligne dans /etc/fstab pour le rendre persistant. Solution durable : passer à un VPS avec 2 Go minimum. Indexation interminable qui ne se termine jamais. Sur une bibliothèque de 50 000 photos sur un VPS à 2 vCPU, la première indexation complète (avec ML) peut prendre 6 à 24 heures. C'est normal. Suivez la progression dans les logs avec docker compose logs -f photoprism. Si le processus semble bloqué sans avancer depuis plus d'une heure, vérifiez l'utilisation CPU : docker stats photoprism. Si elle est à 0 %, redémarrez le service. Problèmes de permissions sur les volumes. PhotoPrism tourne avec l'UID 1000 par défaut. Si /opt/photoprism/originals appartient à root, l'accès échoue silencieusement. Corrigez avec chown -R 1000:1000 /opt/photoprism. Vérifiez aussi que le volume storage est inscriptible : c'est là que PhotoPrism écrit les miniatures et l'index local. L'interface charge mais les photos n'apparaissent pas. Vérifiez que l'indexation a bien été lancée (photoprism index) et non seulement le service démarré. L'import initial n'est pas automatique.

Une sauvegarde PhotoPrism efficace distingue trois composants aux besoins différents. Le dossier originals contient vos fichiers maîtres (JPEG, RAW, vidéos) : c'est l'irremplaçable. Sauvegardez-le en priorité avec une copie hors site — rclone sync /opt/photoprism/originals remote:backup/originals vers un stockage objet (Backblaze B2, S3) fonctionne bien et supporte les reprises incrémentales. Fréquence recommandée : quotidienne. Le dossier storage contient les miniatures générées, le cache et les données de sidecar. Il peut être entièrement reconstruit par une ré-indexation (photoprism index --force) : sauvegardez-le uniquement si vous voulez éviter de relancer une longue indexation après incident. Un snapshot hebdomadaire suffit. La base MariaDB stocke l'index des métadonnées, les albums, les labels manuels et les faces identifiées — tout le travail de curation que vous avez fait manuellement. Sauvegardez-la séparément avec un dump régulier : docker compose exec mariadb mysqldump -u photoprism -p photoprism > /opt/backup/photoprism-db-$(date +%Y%m%d).sql. Planifiez ce dump en cron et chiffrez-le avant l'envoi hors site. Si vous utilisez SQLite au lieu de MariaDB, copiez simplement le fichier .db après avoir arrêté PhotoPrism pour garantir la cohérence.