Combien de RAM et d’espace disque faut-il à Immich ?

De combien de RAM Immich a-t-il besoin ?

Immich demande 6 Go de RAM (mémoire vive) au minimum selon sa documentation, et 8 Go sont recommandés, avec 2 cœurs CPU au minimum et 4 pour une installation confortable. Cette valeur couvre toute la stack, car Immich utilise quatre conteneurs et non une seule application. La consultation d’une bibliothèque déjà importée consomme peu de ressources. La mémoire est surtout utilisée lors de l’importation, et principalement par un conteneur que vous pouvez désactiver.

[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

Ces valeurs sont celles publiées sur la page des prérequis d’Immich en août 2026. Il s’agit de recommandations de dimensionnement, pas d’une vérification indiquant que le logiciel peut démarrer avec cette quantité de mémoire. Immich démarre avec moins de ressources. Sur un serveur moins puissant, ce qui change est le nombre de tâches en arrière-plan qui peuvent se terminer et le comportement d’une importation lorsque la mémoire vient à manquer.

Il existe une véritable limite matérielle. Immich version 3 et ultérieure nécessite un x86-64-v2 sur les hôtes amd64, ce qui concerne la plupart des processeurs vendus depuis environ 2012. Sur du matériel plus ancien, le conteneur échoue au démarrage au lieu de fonctionner plus lentement.

Si vous n’avez pas encore effectué l’installation, commencez par l’installation complète d’Immich sur un VPS avec Docker Compose, puis revenez ici pour dimensionner le serveur.

Où va la mémoire : quatre conteneurs

Le fichier Compose officiel démarre quatre services. Chacun a un profil mémoire différent, donc un total masque l’information utile.

immich-server sert l’interface web et l’API, et exécute aussi les workers de tâches en arrière-plan. Deux workers résident dans ce même conteneur. api traite les requêtes du navigateur et de l’application mobile. microservices exécute les files d’attente, notamment la génération des miniatures et l’encodage vidéo. Les variables IMMICH_WORKERS_INCLUDE et IMMICH_WORKERS_EXCLUDE séparent ces deux composants dans des conteneurs distincts. Vous pouvez ainsi attribuer sa propre limite mémoire à la partie la plus consommatrice, sans limiter celle qui sert vos photos.

database est une image PostgreSQL 14 avec l’extension VectorChord intégrée. Elle contient toutes les métadonnées et un vecteur de recherche par asset. La documentation d’Immich fixe à ce service le seul minimum explicite de la stack : si vous appliquez des limites de ressources Docker, la base de données nécessite au moins 2 GB. La même page indique que la base de données doit se trouver sur un stockage SSD local, et jamais sur un partage réseau, car les recherches dans les vecteurs et les index effectuent de petites lectures aléatoires. Un volume réseau transforme donc chacune d’elles en aller-retour réseau. Si le choix du plan en dépend, la différence entre un stockage SSD NVMe et SATA sur un VPS est plus importante ici que partout ailleurs dans cette stack.

redis exécute l’image Valkey et contient les files d’attente des tâches. C’est de loin le plus petit des quatre, car il stocke des enregistrements de tâches plutôt que des données de photos.

immich-machine-learning est le service qui détermine la taille de votre plan. Il charge les modèles pour la recherche intelligente, la détection des visages et la reconnaissance de texte, et un modèle chargé reste résident en mémoire. MACHINE_LEARNING_MODEL_TTL vaut 300 par défaut : un modèle est donc déchargé après cinq minutes sans requête, puis relu depuis le volume /cache à la requête suivante. Lors d’un import massif, il ne s’écoule jamais cinq minutes sans requête. Les modèles restent donc chargés du premier asset au dernier.

Ce qui change pendant un import

Un serveur Immich au repos est silencieux. Les imports sont la principale cause de surcharge sur les petits serveurs, car l’envoi d’un seul asset met en file toute une chaîne de jobs, et plusieurs queues s’exécutent en même temps.

L’extraction des métadonnées lit l’en-tête du fichier et consomme peu de ressources. La génération des thumbnails est plus coûteuse. Immich produit trois thumbnails par asset : un placeholder thumbhash flouté, un aperçu WebP et un thumbnail JPEG, auxquels s’ajoute un thumbnail pour chaque visage détecté. Chacun de ces jobs décode une image, et la concurrence des jobs détermine le nombre d’images décodées simultanément. La concurrence transforme le coût limité de chaque job en charge généralisée pour le serveur. C’est pourquoi la FAQ d’Immich recommande de réduire cette valeur en premier sur une machine aux ressources limitées. Définissez la concurrence des queues lourdes à 1 dans Administration, Settings, Job Settings.

Les assets vidéo ajoutent le transcodage. Chaque job de transcodage est un processus FFmpeg distinct, avec sa propre consommation mémoire. Il utilise tous les threads CPU que vous lui autorisez.

Smart search envoie chaque nouvel asset au conteneur de machine learning afin de calculer un vecteur d’embedding. La détection des visages exécute un second modèle sur la même image. Lors du premier import d’une photothèque existante, ces deux queues traitent chaque asset que vous possédez, pendant plusieurs heures. C’est le moment où la consommation mémoire est la plus élevée sur toute l’installation. Cela ne se produit qu’une seule fois.

Pourquoi la reconnaissance des visages et des objets nécessite le plus de RAM

La gestion des visages comporte deux tâches. La détection des visages exécute un modèle dans le conteneur de machine learning et repère les cadres. La reconnaissance faciale regroupe ensuite ces détections pour identifier les personnes, puis interroge l’index vectoriel dans Postgres. Une grande bibliothèque sollicite donc les deux services successivement : le conteneur de modèles pendant la détection, puis la base de données pendant le regroupement.

Quatre paramètres modifient ce que le conteneur de machine learning conserve en mémoire.

• Le modèle de visages. Immich fournit buffalo_l par défaut, et la FAQ recommande buffalo_s sur un petit serveur. Il s’agit d’un modèle plus petit. Il utilise donc moins de mémoire et s’exécute plus rapidement, au prix d’une moins bonne précision sur les visages de petite taille ou vus de profil.
• Le nombre de workers. MACHINE_LEARNING_WORKERS vaut 1 par défaut. Chaque worker est un processus distinct qui charge sa propre copie des modèles. Le passer à 2 double donc à peu près la mémoire résidente occupée par les modèles. Laissez-le à 1, sauf si vous disposez de RAM en quantité suffisante.
• La taille des lots. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION limite le nombre de visages traités simultanément. Un lot est conservé en mémoire dans son ensemble. Une photo de groupe avec quarante visages consomme donc plus de mémoire qu’un portrait.
• Les types de modèles réellement exécutés. La recherche intelligente, la détection des visages et la reconnaissance de texte chargent chacune leurs propres modèles. La désactivation des fonctions que vous n’utilisez pas, dans Administration, Settings, Machine Learning Settings, libère définitivement la mémoire correspondante, et pas uniquement entre les imports.

Il existe également MACHINE_LEARNING_MODEL_ARENA, documenté comme préallouant la mémoire CPU afin d’éviter la fragmentation, et activé par défaut. Modifiez ce paramètre en dernier. Son effet dépend de l’allocateur mémoire utilisé. La seule manière fiable de l’évaluer consiste donc à surveiller docker stats avant et après la modification.

Trois profils détaillés : 2 GB, 4 GB et 8 GB

[
  {
    "label": "2 GB VPS",
    "server_limit_mb": 768,
    "db_limit_mb": 768,
    "ml_limit_mb": 0,
    "redis_limit_mb": 128,
    "notes": "machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 1280,
    "ml_limit_mb": 1024,
    "redis_limit_mb": 192,
    "notes": "machine learning on, job concurrency 1, buffalo_s"
  },
  {
    "label": "8 GB VPS",
    "server_limit_mb": 2048,
    "db_limit_mb": 2048,
    "ml_limit_mb": 2560,
    "redis_limit_mb": 256,
    "notes": "everything on at default settings"
  }
]

Considérez ces valeurs comme des limites à saisir dans Compose, et non comme une mesure de la consommation d’Immich. Une limite est un plafond. Elle ne réserve aucune ressource et ne réduit pas la taille d’un service. Elle détermine quel service le kernel arrête lorsque le serveur manque de mémoire. Il vaut mieux que cette décision soit prise par vous plutôt que par le mécanisme de score du kernel.

Le serveur de 2 GB : supprimer le conteneur de machine learning

2 GB est inférieur au minimum documenté de 6 GB. Il s’agit donc d’un compromis, qu’il faut présenter comme tel. Commentez l’ensemble du service immich-machine-learning dans docker-compose.yml, ou laissez-le fonctionner et désactivez tous les modèles sous Administration, Settings, Machine Learning Settings. Supprimer le conteneur est l’option la plus efficace, car un modèle désactivé laisse tout de même un processus Python en mémoire.

Vous conservez les importations, les albums, le partage, la sauvegarde mobile, les miniatures et la recherche par date, lieu et nom de fichier. Vous perdez la recherche par description, le regroupement automatique des visages par personne et la reconnaissance de texte dans les images.

Les quatre limites totalisent environ 1.7 GB, ce qui laisse environ 300 MB à l’hôte. Notez que la limite de 768 MB pour la base de données est inférieure au seuil documenté de 2 GB. C’est précisément le compromis imposé par 2 GB. C’est pourquoi Postgres est le service qui risque le plus d’être arrêté ici.

Le premier problème concerne l’importation, pas la navigation. Une bibliothèque contenant quelques dizaines de milliers de photos reste utilisable une fois l’importation terminée, car l’affichage d’une page consiste en une requête de métadonnées et une lecture de fichier. Sur le même serveur, l’importation d’un grand nombre de vidéos provoquera du swap, car le transcodage et la file de génération de miniatures ont besoin de mémoire au même moment. Limitez chaque file de tâches lourdes à une concurrence de 1 et ajoutez un fichier swap.

Le serveur de 4 GB : machine learning activé, une tâche à la fois

4 GB est la plus petite configuration où l’activation de la reconnaissance des visages et des objets est pertinente. Limitez le conteneur de machine learning à 0 MB, activez la reconnaissance faciale avec buffalo_s et définissez une concurrence de 1 pour la génération de miniatures, la détection des visages et la recherche intelligente.

Le premier traitement d’une bibliothèque existante prendra plusieurs heures, et plus d’une journée pour une grande bibliothèque. Il s’agit d’une limite liée au CPU, et non à la mémoire. Ajouter de la RAM ne raccourcira donc pas ce traitement.

Ici, le premier problème concerne le conteneur de machine learning pendant ce traitement massif initial. Sans limite, il grossit pendant qu’une tâche de transcodage consomme elle aussi davantage de mémoire, puis le kernel arrête le plus gros des deux. Vous voyez Exited (137) dans docker ps -a, ainsi qu’un conteneur redémarré, tandis que la file d’attente a discrètement pris davantage de retard depuis votre dernière vérification.

Le serveur de 8 GB : la recommandation documentée

8 GB avec 4 cœurs correspond à la recommandation d’Immich. Tous les traitements fonctionnent alors avec les paramètres par défaut : recherche intelligente, détection des visages, reconnaissance de texte et transcodage, avec la concurrence par défaut. Les bibliothèques de plus de cent mille éléments restent confortables dans cette configuration. La contrainte se déplace de la mémoire vers la vitesse du disque, car la base de données utilise toute la journée l’index vectoriel et les requêtes de métadonnées.

Définissez malgré tout les limites. Sur un serveur disposant de marge, elles empêchent une file d’attente qui s’emballe de faire tomber la base de données avec elle. Si vous comparez cette configuration aux options plus petites, ce qu’un VPS coûte réellement selon la quantité de mémoire fait généralement de l’offre 8 GB la solution la moins coûteuse pour éviter les réglages permanents.

Limiter la mémoire par service avec les limites Compose

Ne modifiez pas docker-compose.yml pour cela. Ce fichier est remplacé à chaque mise à niveau par wget. Placez les limites dans docker-compose.override.yml, à côté de celui-ci. docker compose les fusionne automatiquement.

services:
  immich-server:
    deploy:
      resources:
        limits:
          memory: 1024M
  immich-machine-learning:
    deploy:
      resources:
        limits:
          memory: 1024M
          cpus: '1.5'
  database:
    deploy:
      resources:
        limits:
          memory: 1280M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

docker stats doit maintenant afficher votre plafond dans la colonne MEM USAGE / LIMIT, au lieu de la mémoire totale de l’hôte. Si la colonne de limite affiche toujours la taille totale de l’hôte, le fichier d’override n’a pas été pris en compte. Vérifiez le nom du fichier et exécutez docker compose config pour afficher le résultat fusionné.

Une limite trop basse transforme un service lent en service arrêté. Augmentez-la si un conteneur redémarre en boucle. Les mécanismes sont expliqués plus en détail dans la définition de limites mémoire par service dans Docker Compose, notamment pourquoi deploy fonctionne avec Compose v2 en dehors de Swarm.

Comment désactiver ou déplacer le conteneur de machine learning

Sur un petit serveur, déplacer ce conteneur ailleurs est la modification la plus importante que vous puissiez apporter. Immich permet de l’exécuter sur une autre machine. Créez ce fichier sur le deuxième hôte, qui peut être un ordinateur de bureau allumé uniquement le soir :

name: immich_remote_ml
services:
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    restart: always
    ports:
      - 3003:3003
volumes:
  model-cache:

docker compose up -d
curl -s http://localhost:3003/ping

Accédez ensuite à Administration, Settings, Machine Learning Settings dans l’interface web, cliquez sur Add URL, puis saisissez http://<host>:3003. Conservez la même version sur les deux hôtes, car la documentation d’Immich indique que les différences de version entre les deux provoquent des bugs et une instabilité.

Ce port transmet vos photos à l’autre machine sans chiffrement. Gardez donc cette connexion sur un réseau privé ou faites-la passer par un tunnel WireGuard entre les deux hôtes. N’exposez jamais le port 3003 sur Internet.

Si le problème vient du principe même d’un conteneur de modèles résident, c’est également une bonne raison de comparer les différences entre PhotoPrism et Immich concernant les services qu’ils exécutent en permanence avant de choisir une taille de formule.

De quel espace disque une bibliothèque Immich a-t-elle besoin ?

Il n’existe pas de multiplicateur unique, car quatre éléments différents augmentent à des rythmes différents. Voici le calcul pour une bibliothèque de 50,000 photos et 500 vidéos courtes.

[
  {
    "label": "Originals: 50,000 photos at 4 MB",
    "gb": 200
  },
  {
    "label": "Originals: 500 videos at 120 MB",
    "gb": 60
  },
  {
    "label": "Thumbnails and encoded video at 15%",
    "gb": 39
  },
  {
    "label": "Postgres database",
    "gb": 3
  },
  {
    "label": "Machine learning model cache",
    "gb": 2
  }
]

Les valeurs 200 Go de photos et 60 Go de vidéos sont des hypothèses. Remplacez-les par vos propres moyennes avant d’acheter du matériel, car la vidéo détermine ce chiffre : une minute de vidéo prise avec un téléphone est plus volumineuse qu’une centaine de photos.

find /srv/immich/upload -type f -printf '%s\n' \
  | awk '{n++; s+=$1} END {printf "%d files, %.1f MB average\n", n, s/n/1048576}'

La ligne 39 Go est le seul ratio publié par Immich : les miniatures générées et les vidéos transcodées ajoutent en moyenne 10 à 20 % à la taille de la bibliothèque. Il s’agit d’une plage, car le résultat dépend de la proportion de vos fichiers vidéo qui doivent être réencodés pour assurer la compatibilité avec les navigateurs. Une bibliothèque composée de fichiers JPEG se situe généralement vers le bas de cette plage.

La base de données occupe 3 Go, ce qui correspond presque à un coût fixe. Immich indique que les fichiers de base de données occupent généralement 1 à 3 Go, car ils contiennent des métadonnées et des vecteurs de recherche, pas des pixels. Le cache des modèles occupe 2 Go et augmente si vous activez plusieurs modèles ou si vous en testez différents. La FAQ signale précisément ce volume comme un consommateur d’espace pour cette raison.

Les cinq lignes représentent un peu plus de 300 Go au total. Un volume de 500 Go laisse donc une marge de croissance, contrairement à un volume de 250 Go. Surveillez cette répartition avec :

grep UPLOAD_LOCATION .env
du -sh /srv/immich/*

Six dossiers se trouvent sous UPLOAD_LOCATION. upload et library contiennent les originaux, thumbs contient les aperçus et les miniatures de visages, encoded-video contient les copies réencodées, profile contient les avatars et backups contient les dumps automatiques de la base de données. Seuls upload, library et profile sont irremplaçables, car tout le reste peut être régénéré à partir de ces éléments.

Deux points surprennent souvent. Les fichiers supprimés sont d’abord déplacés dans la corbeille et continuent d’occuper leur espace jusqu’à ce que celle-ci soit vidée. Un nettoyage important ne libère donc aucun espace le jour même. Ensuite, un dump de la base de données ne contient que les métadonnées. Il ne sert à rien sans les fichiers :

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

Associez cette sauvegarde à une copie au niveau des fichiers des originaux vers un emplacement situé hors du serveur. C’est précisément le rôle des sauvegardes restic d’un VPS vers un stockage hors serveur.

Le transcodage utilise le CPU, pas la RAM

Ajouter de la RAM n’accélérera pas le transcodage. Immich utilise FFmpeg pour le transcodage. Sur un VPS standard, le CPU décode et encode chaque image. Même lorsque l’accélération matérielle est disponible, Immich indique que seul l’encodage est accéléré. Le CPU effectue donc toujours le décodage logiciel et le tone mapping.

L’accélération matérielle nécessite le fichier Compose supplémentaire hwaccel.transcoding.yml ainsi qu’un périphérique à transmettre, avec NVENC, Quick Sync, RKMPP ou VAAPI. La plupart des offres VPS ne fournissent aucun de ces éléments. Prévoyez donc une utilisation du CPU.

Le réglage important concerne le nombre de threads. Dans Administration, Settings, Video Transcoding Settings, une valeur de 0 utilise tous les cœurs. Une seule vidéo peut alors bloquer l’interface web sur une offre à 2 cœurs. Définissez cette valeur sur 1 ou 2, comme le recommande la FAQ d’Immich. Le transcodage sera lent, mais il ne perturbera plus le service.

Pourquoi un import en thrashing du swap ressemble à un blocage

C’est le problème que l’on interprète le plus souvent à tort. Quand Immich n’a plus de mémoire, deux cas sont possibles, mais un seul ressemble à une panne.

Sans swap, le kernel tue un processus. Le conteneur redémarre en quelques secondes. Dans le navigateur, la file de tâches se bloque donc brièvement, puis reprend. Les éléments permettant de le confirmer se trouvent dans docker ps -a :

docker ps -a --filter name=immich
docker inspect immich_machine_learning | grep -i oomkilled
sudo dmesg -T | grep -i -E 'out of memory|oom-kill'

Exited (137) indique que le processus a été tué avec le signal 9. 137 correspond à 128 plus 9. Une valeur OOMKilled de true confirme qu’il a été tué par manque de mémoire, et non à la suite d’un crash.

Avec le swap, rien n’est tué et aucune erreur ne s’affiche. Le kernel commence à déplacer des pages vers le disque. L’import ralentit d’un facteur 10, et l’interface web cesse de répondre dans un délai normal. Tous les conteneurs fonctionnent. Tous les health checks peuvent encore réussir. Cela ressemble à un blocage. À ce stade, on redémarre souvent le serveur, ce qui fait perdre la progression de la file et ne change rien.

free -m
vmstat 1 5

Des valeurs non nulles persistantes dans les colonnes si et so de vmstat signifient que la machine lit et écrit continuellement dans le swap : c’est la définition du thrashing. La ligne free -m correspondant à Swap utilisé augmente en même temps.

Ajoutez tout de même du swap sur une machine de 2 GB ou 4 GB. Un import lent que vous pouvez diagnostiquer vaut mieux qu’un conteneur tué dont vous ne pouvez pas déterminer la cause :

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Corrigez ensuite la cause. Réduisez la concurrence des tâches à 1, limitez la mémoire du conteneur de machine learning ou déplacez-le sur un autre hôte. Le swap vous donne le temps de le faire. Il ne constitue pas une solution à lui seul.

FAQ

Puis-je exécuter Immich sur un VPS de 2 GB ?

Oui, si le service immich-machine-learning est commenté dans docker-compose.yml et si la concurrence des tâches est définie sur 1. Cette configuration est inférieure au minimum documenté de 6 GB. Considérez-la donc comme un compromis connu. Vous conservez les téléversements, les albums, le partage, la sauvegarde mobile et la recherche par date, lieu et nom de fichier. Vous perdez la recherche par description, le regroupement automatique des visages en personnes et la reconnaissance de texte dans les images. Ajoutez un fichier swap de 2 GB afin qu’un pic lors d’une importation ralentisse le serveur au lieu de provoquer l’arrêt d’un conteneur.

Pourquoi mon importation Immich s’arrête-t-elle sans message d’erreur ?

Deux causes différentes peuvent sembler identiques dans le navigateur. Soit un conteneur a été arrêté par manque de mémoire. Dans ce cas, docker ps -a affiche Exited (137) et le conteneur a déjà redémarré. Soit l’hôte utilise le swap. Dans ce cas, tous les conteneurs sont toujours en cours d’exécution, mais tout est simplement très lent. vmstat 1 5 permet de les distinguer : des valeurs non nulles persistantes dans les colonnes si et so indiquent une utilisation du swap. Dans les deux cas, réduisez la concurrence des tâches pour la génération des miniatures, la détection des visages et la recherche intelligente.

Que signifie le code de sortie 137 dans les journaux Immich ?

137 correspond à 128 plus le signal 9. Le processus a donc été arrêté avec SIGKILL. En pratique, cela signifie qu’une limite de mémoire a été atteinte : soit la limite propre au conteneur, soit la mémoire disponible de l’hôte a été épuisée. Vérifiez avec docker inspect immich_machine_learning | grep -i oomkilled. Une valeur de true confirme que le kernel l’a arrêté par manque de mémoire. free -m et sudo dmesg -T | grep -i oom-kill indiquent ensuite s’il s’agissait de la limite du conteneur ou de celle de l’hôte entier. Le conteneur de machine learning est généralement concerné, car il contient habituellement le processus le plus volumineux.

De quel espace disque Immich a-t-il besoin par photo ?

Prévoyez la taille du fichier original plus 10 à 20 %. Immich indique que les miniatures générées et les vidéos transcodées augmentent en moyenne la taille de la bibliothèque de 10 à 20 %. La base de données elle-même occupe généralement 1 à 3 GB, même pour une bibliothèque volumineuse. Les vidéos déterminent réellement l’espace total nécessaire. Mesurez donc la taille moyenne de vos propres fichiers avant de choisir une offre, au lieu d’appliquer un multiplicateur au nombre de photos.

Ai-je besoin d’un GPU pour Immich ?

Non. Chaque composant d’Immich fonctionne sur CPU. Une carte graphique accélère l’inférence des modèles dans le conteneur de machine learning et l’encodage vidéo, mais aucun des deux n’est indispensable. La plupart des offres VPS n’en proposent pas. Sur du matériel limité au CPU, définissez le nombre de threads de transcodage sur 1 ou 2, utilisez le modèle de détection des visages buffalo_s et laissez la première importation complète s’exécuter pendant la nuit.