Installer Immich prend quatre étapes et deux fichiers récupérés directement chez le projet. Depuis la version 3, annoncée le 1er juillet 2026, le conteneur d’intelligence artificielle exige un processeur de niveau x86-64-v2 : une machine ancienne, ou une machine virtuelle mal configurée, échouera après une installation qui semblait pourtant réussie. Une commande vous donne la réponse avant même de commencer.
L’essentiel
Commande clé :docker compose up -ddans le dossier contenantdocker-compose.ymlet.env
Accès :http://adresse-du-serveur:2283
Prérequis : 6 Go de RAM (8 recommandés), 2 cœurs (4 recommandés), base de données sur SSD local
Version couverte : branche v3, via la variableIMMICH_VERSION=v3
Distributions : toute distribution Linux 64 bits disposant de Docker Engine et du plugin Compose
Vérifié le 14 août 2026 — procédure conforme à la documentation officielle Immich consultée à cette date. Les commandes de vérification du processeur ont été exécutées et testées ; les commandesdocker composesont conformes à la documentation officielle.
Ce qu’Immich fait, et ce qu’il ne remplace pas
Immich est une galerie photo auto-hébergée. Vos photos et vos vidéos restent sur votre serveur, l’application mobile les sauvegarde automatiquement, et l’interface web offre la reconnaissance faciale, la recherche par contenu et l’affichage sur carte. Le projet est publié sous licence AGPL v3 et son usage est gratuit, sans limite de stockage autre que celle de votre disque.
La méthode recommandée pour installer Immich est Docker Compose. D’autres voies existent — Kubernetes, Portainer, Unraid, un script d’installation expérimental — mais toutes reposent sur les images Docker officielles. C’est donc le chemin décrit ici.
Une précision qui évite un malentendu coûteux : Immich n’est pas une solution de sauvegarde. C’est une galerie qui centralise vos médias. Si le serveur brûle et que vous n’avez aucune copie ailleurs, vos photos disparaissent avec lui. La section consacrée à la sauvegarde explique quoi copier, dans quel ordre, et pourquoi la sauvegarde intégrée ne suffit pas.
Docker et le plugin Compose doivent être installés avant de commencer. Si ce n’est pas fait, la procédure complète pour les quatre familles de distributions est détaillée dans notre guide pour installer Docker sur Linux.
Vérifier que votre machine peut faire tourner Immich v3
Cette section est la seule du tutoriel qui puisse vous faire renoncer. Elle prend deux minutes, et elle vous en économise beaucoup.
Le contrôle processeur que la plupart des guides oublient
Depuis la version 3, le conteneur d’apprentissage automatique d’Immich exige que les processeurs x86 atteignent le niveau de microarchitecture x86-64-v2. La cause est une montée de version de numpy, une bibliothèque interne. La conséquence est concrète : sur un processeur plus ancien, le serveur démarre, l’interface web répond, mais le conteneur d’intelligence artificielle redémarre en boucle et la reconnaissance faciale ne fonctionne jamais.
Cette commande donne le verdict :
# Vérifier si le processeur atteint le niveau x86-64-v2 requis par Immich v3
if ! LC_ALL=C /lib64/ld-linux-x86-64.so.2 --help 2>/dev/null | grep -q "x86-64-v"; then
echo "Test indisponible sur ce système : utilisez la méthode de repli ci-dessous"
elif LC_ALL=C /lib64/ld-linux-x86-64.so.2 --help | grep -q "x86-64-v2 (supported"; then
echo "Processeur compatible avec Immich v3"
else
echo "Processeur trop ancien pour Immich v3"
fi
Le premier test vérifie que la machine sait répondre à la question, avant de rendre un verdict. Sans cette précaution, une distribution ancienne renvoie « processeur trop ancien » sur un processeur parfaitement compatible : la section interrogée n’existe pas, et un test naïf confondrait cette absence avec un échec. La locale est forcée avec LC_ALL=C parce que le filtre porte sur un mot anglais.
Vous pouvez aussi lire la sortie brute, plus parlante :
LC_ALL=C /lib64/ld-linux-x86-64.so.2 --help | grep "x86-64-v"
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
La mention (supported, searched) en face de x86-64-v2 est ce qui compte. Les niveaux sans cette mention ne sont pas gérés par votre processeur.
Cette méthode repose sur une fonctionnalité de la glibc apparue en version 2.33. Sur une distribution plus ancienne — Debian 10, Ubuntu 18.04, CentOS 7 — utilisez la vérification par les instructions du processeur, qui fonctionne partout :
# Méthode de repli : SSE4.2 fait partie des instructions exigées par x86-64-v2
LC_ALL=C grep -qE '^flags.*\bsse4_2\b' /proc/cpuinfo && echo "Instructions x86-64-v2 présentes"
Si le verdict est négatif, deux situations se présentent. Sur une machine physique, le processeur est trop ancien : les deux sources officielles situent le seuil entre 2010 et 2012 selon la page consultée, ce qui explique pourquoi la commande vaut mieux qu’une date. Aucun réglage ne changera ce verdict. Rester sur Immich v2.7.5, dernière version compatible x86-64-v1, est possible mais cette branche n’est plus maintenue : aucun correctif de sécurité, et une application mobile à figer sur la même version.
Sur une machine virtuelle, le problème vient très souvent du type de processeur émulé. Un hyperviseur configuré avec un type générique masque les instructions du processeur réel. Sous Proxmox, le réglage se trouve dans les options processeur de la machine virtuelle, et notre guide pour installer Proxmox VE détaille la configuration d’une VM saine. Changez le type de processeur, redémarrez la machine virtuelle, relancez la commande.
Mémoire, processeur et espace disque
| Ressource | Minimum officiel | Recommandé | Ce qui arrive en dessous |
|---|---|---|---|
| RAM | 6 Go | 8 Go | Envois de fichiers instables ; à 4 Go, il faut désactiver l’apprentissage automatique |
| Processeur | 2 cœurs | 4 cœurs | Traitement des miniatures très lent |
| Stockage | Taille de la bibliothèque | + 10 à 20 % | Les miniatures et les vidéos ré-encodées occupent cet espace supplémentaire |
| Base de données | SSD local | SSD local | Lenteurs générales, voire corruption sur partage réseau |
Le seuil de 6 Go écarte plusieurs machines souvent citées. La documentation ne donne pas de verdict par modèle, mais appliqué au Raspberry Pi ce seuil exclut les Pi 4 en 2 ou 4 Go pour un usage confortable. Seuls les modèles 64 bits disposant d’au moins 8 Go méritent d’être envisagés, et sans accélération matérielle le traitement initial d’une grande bibliothèque prend un temps considérable.
Droits nécessaires
Les commandes de préparation — créer un dossier, télécharger les fichiers — s’exécutent avec votre compte utilisateur. Les commandes docker nécessitent en revanche un accès au démon Docker. Vérifiez lequel s’applique à vous :
docker info >/dev/null 2>&1 && echo "Accès Docker sans sudo" || echo "Ajoutez votre utilisateur au groupe docker, ou préfixez par sudo"
Si l’accès manque, l’erreur est explicite : permission denied while trying to connect to the Docker daemon socket. Ajoutez alors votre compte au groupe docker, ou préfixez uniquement les commandes docker par sudo.
Avertissement — N’exécutez pas l’ensemble du tutoriel en root. Les dossiers de configuration et la bibliothèque appartiendraient alors à root, et votre compte ne pourrait plus les lire — ce qui casserait la sauvegarde automatique mise en place plus loin. Ajouter un compte au groupe
dockerlui accorde par ailleurs un accès équivalent à root sur la machine : c’est un choix à faire en connaissance de cause.
Où placer la base de données
Avertissement — La documentation officielle est explicite : les partages réseau ne sont pas supportés pour la base de données. NFS, SMB, iSCSI monté à distance, dossier synchronisé : tous exposent à des lenteurs et à une corruption des données. La base doit vivre sur un disque local, idéalement un SSD. Elle occupe généralement entre 1 et 3 Go.
Si votre stockage est un disque mécanique, la documentation prévoit un réglage dédié. Décommentez la ligne DB_STORAGE_TYPE: 'HDD' dans le service database du fichier Compose. Les réglages internes de la base seront adaptés à ce type de support.
Quatre systèmes de fichiers sont incompatibles : NTFS, exFAT, FAT et FAT32 ne gèrent pas les propriétaires et les permissions dont PostgreSQL a besoin. Le symptôme est sans ambiguïté au démarrage : data directory has wrong ownership. Sous WSL, un dossier de l’hôte monté depuis /mnt échoue également, même sur un système de fichiers compatible ; la parade officielle consiste à basculer DB_DATA_LOCATION sur un volume nommé.
Plutôt que de vous fier à la liste, interrogez directement le support visé. Remplacez le chemin par le dossier que vous comptez utiliser pour DB_DATA_LOCATION :
findmnt -no FSTYPE --target /chemin/vise
ext4
Une réponse ext4, xfs, btrfs ou zfs convient. Une réponse ntfs, exfat, vfat, fuseblk, nfs ou cifs ne convient pas. Cette commande ne modifie rien et ne demande aucun privilège.
Sur un NAS Synology, l’installation passe par Container Manager et suit une logique différente de celle décrite ici. Le projet héberge une documentation Synology, maintenue par la communauté et non par l’équipe.
Étape 1 : récupérer les deux fichiers officiels
Créez un dossier de travail, puis téléchargez le fichier Compose et le modèle de configuration depuis la dernière version publiée :
# Créer le dossier qui contiendra la configuration
mkdir ./immich-app
cd ./immich-app
# Récupérer le fichier Compose de la dernière version
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
# Récupérer le modèle de configuration et le renommer en .env
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env
Vérifiez que les deux fichiers sont bien présents et non vides :
wc -c docker-compose.yml .env
Deux tailles non nulles confirment que le téléchargement a abouti. Un fichier à 0 octet signale une redirection ou une coupure réseau : relancez la commande wget correspondante.
Ne recopiez pas un fichier Compose trouvé sur un blog ou un forum, même récent. La composition de la pile change à chaque version majeure, et un fichier daté fera échouer le démarrage ou installera des composants qui ne sont plus maintenus.
Étape 2 : configurer le fichier .env
Le fichier téléchargé contient six variables actives et une septième en commentaire. Quatre méritent votre attention :
| Variable | Rôle | Valeur recommandée | Conséquence d’une erreur |
|---|---|---|---|
UPLOAD_LOCATION | Emplacement des photos et vidéos | Un dossier neuf, sur un volume avec de l’espace | Bibliothèque écrite au mauvais endroit, disque saturé |
DB_DATA_LOCATION | Emplacement de la base | Un dossier local sur SSD | Lenteurs, risque de corruption sur partage réseau |
IMMICH_VERSION | Version utilisée | v3 | Un numéro de version inexistant provoque manifest unknown au téléchargement |
DB_PASSWORD | Mot de passe interne de la base | Chaîne aléatoire, lettres et chiffres uniquement | Mot de passe tronqué ou altéré, base inaccessible |
Le contenu par défaut ressemble à ceci :
# Emplacement des fichiers envoyés
UPLOAD_LOCATION=./library
# Emplacement de la base de données. Les partages réseau ne sont pas supportés
DB_DATA_LOCATION=./postgres
# Fuseau horaire, à décommenter et adapter
# TZ=Etc/UTC
# Version d'Immich utilisée
IMMICH_VERSION=v3
# Mot de passe de la base, à changer
DB_PASSWORD=postgres
# Les valeurs ci-dessous n'ont pas besoin d'être modifiées
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
La valeur v3 est un métatag : elle suit automatiquement la dernière version de la branche 3. Épingler un numéro précis est possible, à condition qu’il existe réellement — un tag inventé fait échouer le téléchargement des images.
La documentation recommande de limiter le mot de passe aux caractères A-Za-z0-9, sans caractère spécial ni espace, pour éviter les problèmes d’interprétation par Docker. Deux caractères sont particulièrement traîtres dans un fichier .env : le # ouvre un commentaire et tronque la valeur, le $ déclenche une substitution de variable. Le mot de passe transmis n’est alors pas celui que vous avez écrit, sans aucun avertissement. L’utilitaire pwgen génère des chaînes conformes. Pour contrôler ce qui est réellement transmis :
docker compose config | grep POSTGRES_PASSWORD
Décommentez enfin la ligne TZ= et remplacez la valeur par votre fuseau, par exemple Europe/Paris. Cette variable sert de repli quand le fuseau ne peut pas être déduit des métadonnées d’une photo, et fixe l’heure des journaux et des tâches planifiées.
Étape 3 : démarrer les conteneurs
Depuis le dossier contenant vos deux fichiers :
docker compose up -d
La commande est bien docker compose, en deux mots. L’ancienne commande docker-compose est abandonnée et n’est plus supportée par Immich. Le premier démarrage télécharge plusieurs gigaoctets d’images et prend du temps.
Contrôlez ensuite l’état de la pile :
docker compose ps
Quatre conteneurs doivent apparaître. Voici ce que chacun fait :
| Conteneur | Image | Rôle |
|---|---|---|
immich_server | ghcr.io/immich-app/immich-server | Interface web, API, traitement des médias |
immich_machine_learning | ghcr.io/immich-app/immich-machine-learning | Reconnaissance faciale et recherche par contenu |
immich_redis | docker.io/valkey/valkey:9 | File d’attente des tâches |
immich_postgres | ghcr.io/immich-app/postgres | Base de données, avec l’extension vectorielle VectorChord |
Deux détails de ce tableau permettent de dater un tutoriel d’un coup d’œil. La file d’attente utilise désormais Valkey, pas Redis. Et la base repose sur VectorChord, l’extension qui a remplacé pgvecto.rs. Un guide qui affiche encore redis:6.2-alpine ou tensorchord/pgvecto-rs décrit une pile qui n’existe plus.
Étape 4 : créer le compte administrateur
Ouvrez http://adresse-du-serveur:2283 dans un navigateur, puis cliquez sur le bouton « Getting Started ».
Immich ne possède aucun identifiant par défaut. Le premier compte enregistré devient automatiquement l’administrateur, et c’est lui qui pourra ensuite créer les autres utilisateurs. Choisissez donc un mot de passe solide dès cette étape, puisque ce compte contrôlera l’ensemble de l’instance.
Vérifier que l’installation fonctionne
Trois contrôles suffisent à valider l’installation.
Les quatre conteneurs sont en bonne santé :
docker compose ps
La colonne d’état doit indiquer Up et, pour les conteneurs qui en disposent, la mention healthy. Un conteneur affichant Restarting signale un problème : la section des erreurs courantes explique comment lire les journaux pour l’identifier.
L’envoi fonctionne : depuis l’interface web, envoyez une photo. Elle doit apparaître dans la vue principale en quelques secondes.
Le traitement suit : dans l’administration, l’onglet des files de tâches montre les travaux en cours. Après un premier envoi, plusieurs files doivent s’activer, notamment la génération des miniatures et l’analyse par apprentissage automatique. Si cette dernière reste vide alors que les autres avancent, revenez à la vérification du processeur.
Accéder à Immich en HTTPS depuis l’extérieur
Le port 2283 sert l’interface en HTTP, sans chiffrement. Tant que vous restez sur votre réseau local, cela suffit. Dès que vous voulez consulter vos photos depuis l’extérieur, exposer ce port directement revient à faire circuler vos identifiants en clair sur Internet.
La solution consiste à placer un reverse proxy devant Immich. La procédure complète, certificat Let’s Encrypt compris, est détaillée dans notre guide sur Nginx Proxy Manager. Vous y créerez un hôte proxy pointant vers l’adresse interne du serveur Immich sur le port 2283.
Trois exigences du projet méritent d’être connues avant de configurer ce proxy, parce qu’elles produisent des pannes déroutantes :
| Réglage | Symptôme s’il manque |
|---|---|
| Taille maximale du corps de requête très élevée | Les photos passent, les vidéos échouent |
| Prise en charge des WebSockets | Le tableau de bord affiche le serveur hors ligne |
| Servir Immich à la racine d’un domaine | Interface cassée si vous utilisez un sous-chemin |
Le dernier point est une interdiction, pas une préférence : Immich ne peut pas être servi sur un sous-chemin du type domaine.fr/photos. Prévoyez un sous-domaine dédié.
Sauvegarder réellement ses photos
Avertissement — Immich intègre une sauvegarde de base de données, et elle induit en erreur. La documentation officielle le signale explicitement : cette sauvegarde ne contient que les métadonnées et les informations des comptes. Les photos et les vidéos, stockées dans
UPLOAD_LOCATION, ne sont pas incluses. Une restauration depuis cette seule sauvegarde vous rendra une bibliothèque vide de tout contenu.
Deux points changent la manière de construire votre sauvegarde. D’abord, les sauvegardes automatiques de la base sont écrites dans le sous-dossier backups de UPLOAD_LOCATION : copier ce dossier embarque donc déjà les exports de la base, et il faut en tenir compte dans le calcul de l’espace nécessaire.
Ensuite, l’ordre compte. La méthode la plus sûre consiste à arrêter le serveur pendant la copie :
docker compose stop immich-server
# lancer ici la copie de UPLOAD_LOCATION
docker compose start immich-server
Si l’arrêt n’est pas envisageable, sauvegardez la base d’abord, les fichiers ensuite. Dans l’ordre inverse, la base restaurée référencera des fichiers absents de la copie, et les médias concernés apparaîtront cassés. Notre guide pour automatiser des sauvegardes avec rsync et crontab couvre la mise en place de cette copie régulière.
Mettre à jour Immich, et le piège du passage en version 3
La mise à jour tient en une commande, exécutée dans le dossier de configuration :
docker compose pull && docker compose up -d
Les anciennes images peuvent ensuite être supprimées avec docker image prune.
Le passage d’une version 2 à une version 3 demande plus d’attention. La variable IMMICH_VERSION doit d’abord passer à v3 dans le fichier .env. Les changements de rupture documentés sont les suivants :
| Changement | Effet | À faire |
|---|---|---|
| pgvecto.rs supprimé | DB_VECTOR_EXTENSION=pgvecto.rs déclenche une erreur | Migrer vers VectorChord avant la mise à jour |
IMMICH_MACHINE_LEARNING_PING_TIMEOUT retirée | Remplacée par un réglage de l’interface d’administration | Reporter la valeur dans la configuration système |
MACHINE_LEARNING_PRELOAD__CLIP retirée | Scindée en deux variables distinctes | Utiliser les variantes __TEXTUAL et __VISUAL |
MACHINE_LEARNING_PRELOAD__FACIAL_RECOGNITION retirée | Scindée en deux variables distinctes | Utiliser les variantes __DETECTION et __RECOGNITION |
| Ancienne timeline mobile supprimée | L’affichage hérité disparaît de l’application | Signaler tout problème sur la nouvelle timeline |
À cela s’ajoute une règle permanente d’Immich, indépendante de la v3 : le serveur n’est compatible qu’avec sa propre version majeure. Mettez donc à jour les applications mobiles avant le serveur.
Sauvegardez la base avant toute migration. Le retour à une version antérieure n’est pas supporté, même à l’intérieur d’une version mineure.
Désinstaller Immich ou revenir en arrière
Arrêter et supprimer les conteneurs, en conservant les données :
docker compose down
Cette commande laisse intacts vos dossiers UPLOAD_LOCATION et DB_DATA_LOCATION. Vous pouvez relancer l’instance plus tard avec docker compose up -d et tout retrouver.
L’option -v ajoute la suppression des volumes nommés. Avec le fichier Compose officiel, un seul est concerné, celui qui met en cache les modèles d’apprentissage automatique. Vérifiez-le avant d’agir plutôt que de me croire sur parole :
docker compose config --volumes
Si cette commande liste autre chose que model-cache, par exemple parce que vous avez placé la base dans un volume nommé, l’option -v détruira aussi ces données.
Pour effacer réellement la bibliothèque et la base, utilisez les chemins de votre propre configuration plutôt que des valeurs écrites en dur :
Avertissement — Les commandes suivantes détruisent définitivement votre bibliothèque et votre base de données, sans confirmation ni corbeille. Affichez d’abord les chemins, relisez-les, et assurez-vous d’avoir une copie ailleurs si ces photos comptent.
# Afficher les chemins réellement configurés avant toute suppression
grep -E '^(UPLOAD_LOCATION|DB_DATA_LOCATION)=' .env
Recopiez ensuite les deux chemins à la main dans la commande de suppression :
# Remplacer les deux chemins par ceux affichés ci-dessus
rm -rf /chemin/de/votre/bibliotheque /chemin/de/votre/base
Ne chargez pas le fichier .env dans votre terminal pour automatiser cette étape. Un fichier .env n’est pas un script shell : les caractères $ y sont interprétés comme des variables, et un accent grave y déclenche l’exécution d’une commande. Une valeur contenant $HOME deviendrait un chemin différent de celui que vous avez écrit, juste avant un rm -rf. Sur une commande irréversible, la recopie manuelle est la seule méthode sûre.
Erreurs courantes
Le premier réflexe devant un conteneur en échec est de lire ses journaux :
docker compose logs --tail=100 immich-machine-learning
unknown shorthand flag: 'd' in -d
Votre version de Docker est trop ancienne, ou vous utilisez le paquet fourni par la distribution plutôt que celui de Docker. Le cas est fréquent avec le paquet docker.io d’Ubuntu 22.04. Suivez la procédure d’installation officielle de Docker Engine pour votre distribution, en désinstallant d’abord les anciennes versions.
can't set healthcheck.start_interval
Votre Docker Engine est antérieur à la version 25. Le fichier Compose actuel de la branche v3 ne contient plus cette directive : si vous rencontrez ce message, vous utilisez un ancien fichier Compose. Récupérez celui de la dernière version, ou mettez à jour Docker Engine.
Le conteneur d’apprentissage automatique redémarre en boucle
Deux causes différentes produisent le même symptôme, et les journaux les distinguent :
| Dans les journaux | Cause | Solution |
|---|---|---|
SIGILL ou code 132 | Processeur incompatible x86-64-v2 | Reprendre la vérification du début de ce guide |
SIGKILL ou code 137 | Mémoire insuffisante | Ajouter de la RAM, ou désactiver l’apprentissage automatique |
Notez la différence entre SIGILL et SIGKILL : un seul caractère sépare deux diagnostics opposés.
La base refuse de démarrer ou se corrompt
Le message data directory has wrong ownership désigne un système de fichiers qui ne porte pas les permissions POSIX, typiquement NTFS, exFAT, FAT ou FAT32. Un partage réseau produit des symptômes voisins mais plus erratiques. Déplacez DB_DATA_LOCATION sur un disque local formaté en ext4, XFS, Btrfs ou ZFS.
Questions fréquentes
Immich est-il vraiment gratuit ?
Oui, installer Immich ne coûte rien. Le projet est publié sous licence AGPL v3 et l’intégralité des fonctionnalités est utilisable sans payer. Le projet vend des clés produit, mais elles servent à le soutenir financièrement et ne débloquent aucune fonctionnalité. Votre seule limite est l’espace disque de votre serveur.
Quelle est l’alternative à Immich ?
Nextcloud avec l’application Photos couvre un périmètre plus large, puisqu’il gère aussi fichiers, agenda et bureautique, mais son expérience photo est moins aboutie. PhotoPrism est plus proche fonctionnellement, avec une sauvegarde mobile moins mature. Le choix se fait sur ce point précis : si la sauvegarde automatique depuis le téléphone est votre besoin principal, Immich reste le plus abouti des trois.
Immich détecte-t-il les photos en double ?
Oui, mais avec deux limites à connaître. La détection s’appuie sur l’empreinte du fichier, ce qui la rend fiable même si les noms diffèrent, et l’interface propose une gestion des doublons qui vous laisse choisir la version à conserver. En revanche elle ne s’applique qu’aux bibliothèques d’envoi, et jamais entre deux comptes différents : le même fichier importé par deux utilisateurs compte pour deux médias distincts.
Peut-on installer Immich sur un NAS Synology ?
Oui, via Container Manager, mais la procédure diffère de celle décrite ici et le projet héberge une documentation communautaire dédiée à ce cas. Vérifiez avant tout que votre modèle dispose d’au moins 6 Go de mémoire, seuil que beaucoup de NAS grand public n’atteignent pas.
Combien d’espace disque faut-il prévoir ?
Comptez la taille de votre bibliothèque actuelle, majorée de 10 à 20 %. Ce supplément couvre les miniatures et les versions ré-encodées des vidéos que génère Immich. Ajoutez la place des exports de base de données, écrits dans le sous-dossier backups de votre bibliothèque, et prévoyez 1 à 3 Go pour la base elle-même sur un support distinct.
Conclusion
Installer Immich avec succès tient à trois décisions prises avant la première commande : un processeur de niveau x86-64-v2, une base de données sur disque local formaté en ext4 ou équivalent, et une stratégie de sauvegarde qui couvre les fichiers et pas seulement la base. Les quatre étapes d’installation ne posent aucune difficulté ; ce sont ces trois points qui séparent une instance stable d’une soirée perdue à comprendre pourquoi la reconnaissance faciale ne démarre jamais.
Le réflexe à conserver après l’installation : ne jamais exposer le port 2283 directement sur Internet, et lire les journaux avant de chercher une explication. La suite logique est de configurer Nginx Proxy Manager pour l’accès distant chiffré — ou, si vous préférez ne rien exposer du tout, d’atteindre Immich depuis n’importe où sans l’exposer via Tailscale — puis de mettre en place vos sauvegardes automatiques avant de confier vos souvenirs à votre serveur.
