← Blogue

Héberger Immich soi-même pour sa photothèque

Railyard

5 juin 2026 · 8 min de lecture

Suivez ça sur votre propre serveur. Commencer gratuitement, sans carte

Google Photos sauvegarde votre photothèque gratuitement jusqu’à ce que ça ne le soit plus, et au moment où ça cesse d’être gratuit, chaque visage et chaque lieu où vos photos ont été prises sont aussi indexés sur du matériel que vous ne contrôlez pas. Immich est une alternative à code source ouvert qui fait le même travail (sauvegarde automatique depuis votre téléphone, chronologie, reconnaissance faciale, recherche par objet ou par lieu) comme application auto-hébergée : une image principale, un worker de machine learning pour les fonctions d’IA, Redis pour les tâches de fond, et Postgres avec une extension vectorielle pour la recherche. Ce guide met tout ça en place à partir d’un serveur vide, puis montre le raccourci en un clic si vous préférez ne pas gérer les conteneurs vous-même.

À la fin, vous aurez Immich accessible sur votre propre domaine en HTTPS, votre téléphone qui sauvegarde automatiquement, et un plan de sauvegarde pour les deux choses qui comptent vraiment : vos photos et la base de données qui les indexe.

Ce qu’il vous faut

  • Un serveur avec de la mémoire à revendre. Le worker de machine learning d’Immich (détection de visages, recherche d’objets) a besoin de vrai CPU et de vraie RAM en plus de l’application web et de la base de données, donc un Hetzner CX33 (4 vCPU, 8 Go de RAM, 80 Go NVMe) à 8,99 € par mois avant taxes est un point de départ plus sûr que le plus petit palier ; un serveur de taille semblable chez un autre fournisseur fonctionne de la même façon.
  • Un domaine ou sous-domaine avec un enregistrement DNS A que vous pouvez pointer vers le serveur (ce guide utilise photos.example.com).
  • L’application mobile Immich (iOS ou Android) une fois le serveur en ligne.
  • Un accès SSH et environ 20 minutes.

Étape 1 : provisionner le serveur et pointer le DNS

Créez le serveur sous Ubuntu 24.04 (ou toute distribution récente basée sur Debian), notez son adresse IPv4 publique, et créez un enregistrement DNS A :

photos.example.com.  A  203.0.113.20

Connectez-vous en SSH et mettez le système à jour :

ssh root@203.0.113.20
apt update && apt upgrade -y

Étape 2 : installer Docker

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
docker --version
docker compose version

Vous devriez voir une version du moteur Docker et une version de Compose v2.x, sans erreur.

Étape 3 : écrire le fichier d’environnement

La documentation officielle d’Immich pointe vers une paire docker-compose.yml et .env maintenue sur son dépôt GitHub ; ce guide utilise la version actuelle, Immich v3.3.5. Créez un répertoire de travail et le fichier .env :

mkdir -p /opt/immich && cd /opt/immich
UPLOAD_LOCATION=./library
DB_DATA_LOCATION=./postgres
DB_PASSWORD=change-this-to-a-random-alnum-string
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
IMMICH_VERSION=v3.3.5
TZ=America/Montreal

DB_PASSWORD a une vraie contrainte à connaître avant d’en générer un : la documentation d’Immich demande seulement des lettres et des chiffres, aucune ponctuation, puisque le mot de passe est intégré directement dans une chaîne de connexion. UPLOAD_LOCATION est l’endroit où vivent réellement chaque photo et chaque vidéo sur le disque, donc traitez ce chemin comme le seul répertoire de ce serveur que vous ne pouvez pas vous permettre de perdre.

Étape 4 : écrire le fichier Docker Compose

Ceci reproduit le fichier compose officiel d’Immich, avec Caddy ajouté devant pour le HTTPS :

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy-data:/data
      - caddy-config:/config

  immich-server:
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-v3.3.5}
    restart: always
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database

  immich-machine-learning:
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-v3.3.5}
    restart: always
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    environment:
      MACHINE_LEARNING_MODEL_REVISION: v2

  redis:
    image: docker.io/valkey/valkey:9
    restart: always
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep -q PONG || exit 1"]

  database:
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0
    restart: always
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: "--data-checksums"
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb

volumes:
  model-cache:
  caddy-data:
  caddy-config:

L’image de base de données n’est pas du Postgres ordinaire : c’est la version maison d’Immich avec les extensions vectorchord et pgvecto.rs déjà intégrées, ce qui rend la recherche par visage et par objet rapide à grande échelle. Ne la remplacez pas par une image postgres générique même si les variables d’environnement semblent identiques.

Validez avant de démarrer :

docker compose config

Étape 5 : écrire le Caddyfile

photos.example.com {
    reverse_proxy immich-server:2283

    request_body {
        max_size 10GB
    }
}

Le bloc request_body compte particulièrement ici : la limite de taille de requête par défaut de Caddy est confortable pour une page web mais pas pour une vidéo 4K venant d’un téléphone, donc sans l’augmenter, les téléversements de grosses vidéos échouent en cours de route avec une réinitialisation de connexion confuse plutôt qu’une erreur claire.

Étape 6 : démarrer la pile

docker compose up -d
docker compose ps

Vous devriez voir caddy, immich-server, immich-machine-learning, redis et database tous listés comme running. Suivez les journaux du serveur la première fois pour confirmer qu’il a terminé ses propres migrations de démarrage :

docker compose logs -f immich-server

Visitez https://photos.example.com ; vous devriez arriver sur l’écran de création de compte d’Immich avec un certificat HTTPS valide. Créez le premier compte, qui devient l’administrateur du serveur.

Étape 7 : connecter l’application mobile

Installez Immich depuis l’App Store ou le Play Store, ouvrez-la, et entrez l’URL de votre serveur (https://photos.example.com) à l’écran de connexion, puis connectez-vous avec le compte de l’étape 6. Activez la sauvegarde en arrière-plan dans les paramètres de l’application. Vous devriez voir votre pellicule commencer à se téléverser, visible comme un indicateur de progression dans l’application et comme de nouvelles photos apparaissant dans le tableau de bord web en une minute ou deux.

Étape 8 : sauvegarder ce qui compte vraiment

Deux choses ne peuvent pas être régénérées : la base de données Postgres (l’index : albums, visages, métadonnées) et le dossier library (les fichiers photo et vidéo eux-mêmes). Sauvegardez les deux, sur un horaire, ailleurs que sur ce serveur :

docker compose exec -T database pg_dumpall -U postgres | gzip > /opt/immich/backups/immich-db-$(date +%F).sql.gz
tar -czf /opt/immich/backups/immich-library-$(date +%F).tar.gz -C /opt/immich library

Copiez les deux fichiers hors du serveur (stockage objet, autre machine) via une tâche cron. Restaurer la base de données à partir d’un dump seul suffit à remettre l’application en marche ; restaurer le dossier library en même temps est ce qui fait que l’application restaurée affiche réellement vos photos à nouveau.

Étape 9 : mises à jour

Changez IMMICH_VERSION dans .env vers la nouvelle étiquette, puis :

docker compose pull
docker compose up -d

Immich publie des versions fréquentes, et l’application mobile et le serveur sont versionnés ensemble : si l’application affiche un avertissement de non-concordance de version après une mise à jour, mettez d’abord à jour l’application depuis son magasin, plutôt que de dépanner le serveur.

Le raccourci : faites-le avec Railyard

Tout ce qui précède, les quatre conteneurs, le fichier d’environnement, le proxy inverse, l’horaire de sauvegarde, est ce que le gabarit de pile Immich de Railyard met en place pour vous. Connectez un serveur, puis choisissez Immich dans le catalogue de gabarits : https://app.railyard.run/deploy?stack=immich. Railyard provisionne les quatre services ensemble, relie automatiquement les chaînes de connexion de la base de données et de Redis, et émet le certificat HTTPS pour votre domaine.

Une limite honnête à connaître : le worker de machine learning est gourmand en CPU et en mémoire de la même façon que dans la configuration manuelle, donc dimensionnez le serveur en conséquence plutôt que de prendre l’option la plus petite disponible, exactement comme à l’étape 1. Et une particularité que vous verrez dans les journaux de toute façon : le journal de démarrage d’Immich affiche toujours 127.0.0.1 pour un serveur lié à 0.0.0.0, ce qui est une substitution d’affichage propre au framework, pas un signe que quelque chose est mal configuré.

Une fois en marche, les sauvegardes de base de données couvrent le côté Postgres sur un horaire ; le volume library mérite quand même sa propre copie hors serveur, comme dans la configuration manuelle ci-dessus.

Dépannage

Le HTTPS ne s’émet jamais. Le DNS ne pointe pas encore vers le serveur. dig +short photos.example.com devrait retourner l’IP du serveur ; Caddy réessaie tout seul une fois que c’est le cas.

Les téléversements échouent en cours de route, surtout les vidéos. C’est presque toujours la limite de taille de requête de Caddy, couverte à l’étape 5. Confirmez que le bloc request_body est bien dans le Caddyfile actif avec docker compose exec caddy caddy fmt --overwrite /etc/caddy/Caddyfile suivi d’un redémarrage.

Le conteneur de machine learning est lent ou se fait tuer. Vérifiez docker stats pendant qu’une sauvegarde tourne. Si immich-machine-learning est bloqué à 100 % de CPU ou que le conteneur s’arrête, le serveur est sous-dimensionné pour des tâches de fond comme la reconnaissance faciale sur une grande photothèque ; un CX33 convient pour un usage normal, mais la première analyse complète d’une très grande photothèque existante profite de plus de ressources.

L’application mobile affiche une non-concordance de version. Immich lie assez étroitement la compatibilité entre l’application et le serveur. Mettez à jour celui qui est en retard, habituellement l’application, depuis son magasin.

La page de connexion se charge mais le compte admin ne se crée pas. Vérifiez docker compose logs database pour une migration échouée, habituellement causée par un DB_PASSWORD contenant un caractère hors de A-Za-z0-9 qui a cassé la chaîne de connexion dont l’étape 3 avertit.

FAQ

De combien d’espace de stockage ai-je vraiment besoin ? Autant que votre photothèque actuelle, plus une marge pour la croissance ; Immich ne compresse ni ne réencode les originaux par défaut, donc le volume library croît à peu près au même rythme que votre pellicule.

Plus d’une personne peut-elle utiliser la même instance ? Oui. Créez des comptes additionnels depuis le panneau d’administration ; chacun a sa propre photothèque et ses propres paramètres de partage, avec des quotas de stockage contrôlables par l’admin si vous le souhaitez.

Le worker de machine learning a-t-il besoin d’un GPU ? Non, il tourne sur CPU par défaut et c’est ce que ce guide met en place ; la documentation d’Immich couvre l’accélération matérielle optionnelle (NVIDIA, Intel, AMD) pour les grandes photothèques, ce qui échange plus de complexité de configuration contre une indexation plus rapide.

Qu’arrive-t-il si je perds le serveur sans sauvegarde ? Tout disparaît : les photos et l’index. L’étape 8 n’est pas optionnelle pour quoi que ce soit qui vous manquerait réellement.

Est-ce vraiment gratuit à faire tourner ? Le logiciel l’est, le serveur ne l’est pas ; un CX33 à environ neuf euros par mois est le vrai coût récurrent, sans frais par photo ou par gigaoctet superposé comme certains forfaits de stockage infonuagique.

Immich vous donne la majeure partie de ce qu’un service photo hébergé offre, sur du matériel que vous contrôlez, pour le prix d’un petit serveur plutôt qu’un abonnement qui grandit avec le nombre de photos que vous prenez. La configuration ici tient en un fichier d’environnement, un fichier compose et un proxy inverse ; à partir de là, c’est la même application sur votre téléphone, qui sauvegarde de la même façon, vers un serveur à votre nom plutôt qu’à celui de quelqu’un d’autre.

Pourquoi les gens choisissent Railyard pour ça

  • Votre propre compte infonuagique. Déployez sur DigitalOcean, Hetzner, Vultr, AWS, OVHcloud, ou n'importe quel serveur Linux par SSH, facturé directement par votre fournisseur, sans majoration.
  • Un prix fixe par équipe. L'offre gratuite est gratuite pour toujours : un serveur plus un serveur de base de données, trois applications, sans carte. Pro coûte 19 $ par mois pour jusqu'à cinq serveurs et un nombre illimité d'applications. Team coûte 49 $ par mois avec des serveurs illimités. Aucuns frais par application, par déploiement, par siège ou par gigaoctet.
  • Des gabarits en un clic. Déployez des applications open source, comme des bases de données, des outils d'analyse et des outils de développement, sur votre propre serveur en un clic.
  • Des bases de données gérées. Postgres, MySQL et Redis, avec des sauvegardes planifiées, vérifiées par restauration, et la récupération à un point dans le temps.
  • Déploiement par push. Déployez depuis GitHub, GitLab ou la CLI, avec HTTPS automatique et des mises en production sans interruption.

Sautez la configuration du serveur

Déployez Immich depuis le catalogue de gabarits sur Railyard, avec la base de données et le worker de machine learning déjà branchés.

Offre gratuite, sans carte, et 14 jours de Pro pour chaque nouvelle équipe. Prix fixe par équipe.