Montaje de Immich como Alternativa a Google Photos: Guía Definitiva para Sysadmins

Google Photos es la experiencia más pulida del mercado para organizar fotos y videos en la nube. Búsqueda por rostro, mapa geográfico, “recuerdos” del día de hoy hace cinco años, subida automática desde el celular. La uso, lo admito. El problema no es técnico, es de soberanía. Google escanea cada foto para entrenar sus modelos, vende espacio adicional cuando pasas el umbral gratuito, y un cambio unilateral en los términos de servicio puede dejarte sin acceso a años de recuerdos.

Immich es la alternativa open source que replica casi todo eso en tu propio servidor: subida automática desde el celular (iOS + Android), reconocimiento de caras, mapa, búsqueda por objeto y fecha, integración con Nginx como reverse proxy y TLS automático con Let’s Encrypt. Esta guía cubre el montaje desde cero en Docker con almacenamiento persistente, la app móvil, los gotchas de configuración que no documentan y cómo migrar desde Google Photos sin perder las fechas originales.

---

Por qué Immich manda a Google Photos a su propio servidor

Google Photos es la experiencia más pulida del mercado para organizar fotos y videos en la nube: búsqueda por rostro, mapa geográfico, “recuerdos” del día de hoy hace cinco años, y subida automática desde el celular. El problema no es técnico, es de soberanía. Google escanea cada foto para mejorar sus modelos, vende espacio adicional cuando pasas el umbral gratuito, y un cambio unilateral en los términos de servicio puede dejarte sin acceso a años de recuerdos. Immich resuelve exactamente esa frustración: misma experiencia de producto, pero corriendo en tu propio hardware.

Immich es un servidor self-hosted de fotos y videos escrito en TypeScript (backend) y Dart con Flutter (app móvil), mantenido por un equipo con dos ingenieros a tiempo completo y patrocinado por FUTO. A octubre de 2026 va por la versión v3.3.1 (publicada el 8 de octubre), con más de 11.000 commits en GitHub, releases quincenales y un ritmo de desarrollo comparable al de proyectos comerciales grandes. El repositorio oficial es github.com/immich-app/immich y la documentación está en docs.immich.app.

Esta guía asume un servidor Linux 64-bit (Ubuntu, Debian, Fedora, Arch o derivados) con Docker Engine v25+ y Docker Compose v2. Si vienes de Nextcloud o de PhotoPrism y quieres entender las diferencias antes de invertir una tarde migrando, sigue leyendo. Si solo quieres la receta rápida, salta a la sección de instalación.

Qué trae Immich que Google Photos no puede ofrecer

El punto no es solo “es privado”. Es que al correr en tu servidor, Immich tiene acceso a recursos que Google Photos nunca usará: tu GPU, tu almacenamiento barato, tu NAS, y tus modelos de machine learning locales. La versión v3 trae tres primicias técnicas que ningún servicio comercial iguala todavía.

• Reconocimiento facial 100% local: el contenedor immich-machine-learning corre modelos CLIP y de detección de rostros sin enviar nada a la nube. Entrena los embeddings en tu biblioteca y los almacena en una columna vectorial de Postgres (pgvector) que soporta búsqueda por similitud en milisegundos sobre cientos de miles de fotos.
• Búsqueda en lenguaje natural: escribe “fotos del cumpleaños de María en el patio” o “playa con el perro al atardecer” y la consulta se vectoriza con el mismo modelo CLIP, devolviéndote los embeddings más cercanos. Funciona porque el modelo entiende la semántica, no solo palabras clave.
• Hardware acceleration plug-in: dos archivos hwaccel.ml.yml y hwaccel.transcoding.yml permiten activar CUDA, ROCm, OpenVINO, ARM NN, NVENC, QuickSync o VA-API con un cambio de tres líneas. Una Raspberry Pi 5 con el modelo ARM NN y un servidor con una RTX 3060 corriendo CUDA dan resultados de indexado mediblemente distintos.

Lo que Google Photos sí hace mejor y Immich todavía no: integración con servicios de Google (Drive, Gmail, Maps), búsqueda por eventos del calendario y “Smart Select” automático para collage. Si dependes de cualquiera de esas funciones, Immich todavía no es reemplazo total; para todo lo demás (backup automático, timeline, búsqueda semántica, compartir con familia), la paridad ya está.

Requisitos hardware y software antes de empezar

El README oficial dice 6 GB de RAM mínimo y 8 GB recomendado, con la advertencia de que en 4 GB hay que desactivar machine learning. Esos números vienen del perfil de uso típico: indexar 50.000 fotos lleva ~5 GB de RAM porque cada embedding CLIP ocupa unos 50 KB en memoria y el modelo se mantiene cargado. El techo realista para una familia con 200.000 fotos es 12 GB.

Sobre almacenamiento, Immich genera thumbnails y transcodifica videos en calidades intermedias que suman entre el 10 % y el 20 % del tamaño original de tu biblioteca. Si tu colección es de 500 GB, planifica 600 GB mínimo en disco. La base de datos Postgres vive en DB_DATA_LOCATION, ocupa entre 1 GB y 3 GB, y debe estar en SSD local: Immich lo dice en rojo en los requisitos y por buenas razones, porque Postgres con I/O lento hace que cada subida tarde 10 veces más.

Sobre CPU: amd64 necesita la microarquitectura x86-64-v2 desde v3, lo que cubre cualquier CPU de 2012 o posterior (Intel Ivy Bridge, AMD Piledriver en adelante). Si tu CPU es más vieja, la última versión compatible es v2.7.5, que ya no recibe actualizaciones de seguridad. En arm64 no hay restricción equivalente y funciona en Raspberry Pi 4 y 5, Orange Pi 5, y similares.

Sobre filesystem: EXT4, ZFS, BTRFS, XFS o APFS funcionan. NTFS y exFAT no, ni en Windows nativo ni en WSL con directorios montados desde /mnt. Si tienes que correr Immich allí, monta el volumen de Postgres como Docker volume y no como bind mount.

Instalación paso a paso con Docker Compose

Immich publica con cada release un docker-compose.yml y un example.env en su página de GitHub. El truco que ahorra horas es descargar los archivos desde la URL latest/download: esa dirección siempre apunta a la versión más reciente, así que no tienes que editar URLs manualmente cada vez que sale un patch.

# Crear directorio de instalación
mkdir -p ~/services/immich
cd ~/services/immich
# Bajar compose y plantilla de variables de entorno
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

Antes de levantar los contenedores hay que editar tres líneas en .env. La primera es UPLOAD_LOCATION, el directorio donde vivirán tus originales. Ponlo en un disco con espacio de sobra y, sobre todo, que entre en tu plan de backups: si ese disco se rompe sin copia, pierdes la biblioteca completa. La segunda es DB_PASSWORD, que por defecto es postgres: cámbialo a una cadena aleatoria de 32 caracteres usando solo letras y dígitos (el parser de Docker no maneja bien caracteres especiales aquí).

# Generar password aleatorio con pwgen (instalar si no está)
sudo apt install -y pwgen
pwgen -s 32 1
# Salida ejemplo: 8Kj3mN9pQ2vR7wX5yT4cF6hB1aZ0sDLe
# Editar .env para fijar DB_PASSWORD y UPLOAD_LOCATION
sed -i 's|^DB_PASSWORD=postgres|DB_PASSWORD=8Kj3mN9pQ2vR7wX5yT4cF6hB1aZ0sDLe|' .env
sed -i 's|^UPLOAD_LOCATION=./library|UPLOAD_LOCATION=/mnt/fotos/immich-library|' .env
sed -i 's|^IMMICH_VERSION=v3|IMMICH_VERSION=v3.3.1|' .env
sed -i 's|^# TZ=Etc/UTC|TZ=America/Mexico_City|' .env

El tercer cambio importante es IMMICH_VERSION: el valor por defecto es v3, que es una etiqueta flotante que toma siempre la última release mayor de la rama 3.x. Para entornos de producción conviene fijar la versión exacta (v3.3.1 ahora), porque así un docker compose pull no te actualiza el sistema sin querer. La migración entre versiones de Immich corre automática al levantar los contenedores, pero los downgrades no están soportados: si una release te rompe algo, vuelves al backup de la base de datos.

Una vez guardados los cambios, levanta el stack:

# Levantar los 4 contenedores (servidor, ML, postgres, redis)
docker compose up -d
# Ver progreso del primer arranque (tarda 2-4 min mientras Postgres inicializa)
docker compose logs -f immich-server
# Esperar a ver "Listening on 0.0.0.0:2283"

Si todo salió bien, abre http://tu-servidor:2283 en el navegador. La primera cuenta que crees será el administrador: Immich no tiene usuario root ni reset por línea de comandos, así que guarda bien esa contraseña.

El stack de cuatro contenedores y por qué están separados

El docker-compose.yml oficial levanta cuatro servicios que se ven mucho pero tienen razones técnicas claras para estar aislados. La tabla resume qué hace cada uno y por qué no conviene fusionarlos.

Servicio	Imagen	Función	Puerto
immich-server	ghcr.io/immich-app/immich-server	Web UI, API REST, endpoint de backup móvil, transcodificación de video	2283
immich-machine-learning	ghcr.io/immich-app/immich-machine-learning	Embeddings CLIP, detección de rostros, búsqueda semántica	3003 (interno)
redis	valkey/valkey:9	Job queues (colas de trabajos), caché, pub/sub de eventos	interno
database	ghcr.io/immich-app/postgres:14-vectorchord	Metadatos, embeddings vectoriales, usuarios, álbumes	5432 (interno)

La separación entre immich-server e immich-machine-learning es la decisión arquitectónica clave. Permite escalar ML de forma independiente cuando una biblioteca crece: una familia con 100.000 fotos puede mantener el servidor con 2 GB de RAM y darle 6 GB al contenedor de ML. Los modelos CLIP cargados ocupan entre 1 GB y 2 GB de RAM, y se benefician enormemente de GPU/NPU. Si tienes una NVIDIA con compute capability ≥ 5.2 y driver ≥ 545, agregar aceleración es un cambio de tres líneas en el YAML.

# Descargar override de aceleración ML para NVIDIA
wget -O hwaccel.ml.yml https://github.com/immich-app/immich/releases/latest/download/hwaccel.ml.yml
# Editar docker-compose.yml: cambiar el tag de la imagen y descomentar extends
sed -i 's|ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}|ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}-cuda|' docker-compose.yml
sed -i 's|  # extends:|  extends:|' docker-compose.yml
sed -i 's|  #   file: hwaccel.ml.yml|    file: hwaccel.ml.yml|' docker-compose.yml
sed -i 's|  #   service: cpu|    service: cuda|' docker-compose.yml
# Reconstruir y reiniciar
docker compose up -d

La aceleración por GPU para ML reduce el tiempo de indexado inicial de una biblioteca de 50.000 fotos de unas 8 horas en CPU a ~45 minutos con una RTX 3060. Para transcodificación de video, el flujo es idéntico con hwaccel.transcoding.yml y backends NVENC, VA-API o RKMPP. Si tu hardware es modesto, no actives nada: Immich funciona 100 % en CPU, solo tarda más.

Configurar el backup automático desde el celular

La app móvil (Flutter, disponible en App Store y Play Store) es la mitad del valor de Immich. Sin ella, es solo un visor web bonito. La instalación es trivial, pero hay tres detalles que diferencian una configuración correcta de una que deja cabos sueltos.

# Instalar Immich desde la tienda oficial del sistema operativo
# Android: https://get.immich.app/android  (F-Droid también lo distribuye)
# iOS: https://get.immich.app/ios
# Configurar la app después de instalar:
# 1. URL del servidor: http://IP-LAN:2283 dentro de casa
#                     https://fotos.tudominio.com si ya tienes reverse proxy
# 2. Crear la cuenta admin (la del paso anterior)
# 3. Settings -> Backup -> habilitar 'Backup via Wi-Fi only' (recomendado)
# 4. Settings -> Backup -> seleccionar álbum "Camera Roll" como origen
# 5. Settings -> Backup -> activar 'Background backup'

El primer backup de una biblioteca grande puede tardar horas o días, dependiendo de tu ancho de banda y la velocidad de Immich para generar thumbnails. La app muestra el progreso por álbum y permite reanudar si el Wi-Fi se corta. El algoritmo de deduplicación es por hash SHA-1 del contenido, no por nombre de archivo: dos versiones de la misma foto tomadas con segundos de diferencia se suben ambas y se distinguen por timestamp EXIF.

Para migrar la biblioteca completa de Google Photos, el camino recomendado es Google Takeout: pide un export desde takeout.google.com, elige solo “Google Photos” para no descargar gigabytes de correo y Drive, y descarga los ZIPs resultantes. Immich detecta correctamente los archivos con metadata JSON que Takeout añade junto a cada foto, preservando el timestamp original, el álbum y la geolocalización. Para bibliotecas enormes (más de 500 GB), sube por lotes desde el navegador web; el cliente immich-cli permite automatizar la subida por terminal y paralelizar.

Backup y recuperación 3-2-1: porque no hay nada igualable

Este es el punto donde el 90 % de los autoalojados mete la pata. Immich es almacenamiento de fotos: si tu servidor muere sin backup, pierdes años de recuerdos. No es un blog o un wiki donde puedes reconstruir: es data única, irremplazable. La regla 3-2-1 (3 copias, 2 medios, 1 off-site) no es opcional.

# Backup diario de la base de datos a las 2 AM (configurable en Admin -> Jobs)
# Por defecto Immich dumpea a $UPLOAD_LOCATION/backups y conserva los últimos 14 dumps
# Backup manual antes de un upgrade (o cualquier cambio de versión)
docker exec -t immich_postgres pg_dump 
  --clean --if-exists 
  --dbname=immich 
  --username=postgres | gzip > /mnt/backups/immich_db_$(date +%Y%m%d).sql.gz
# Backup de la biblioteca (originales + thumbnails + transcodificaciones)
rsync -avz --delete 
  /mnt/fotos/immich-library/ 
  /mnt/backups/immich-library-mirror/
# Sincronizar el mirror a un proveedor externo (Backblaze B2, Wasabi, S3)
rclone sync /mnt/backups/immich-library-mirror/ 
  b2:mi-cuenta-backup/immich-library/ 
  --transfers 4 --checkers 8 
  --log-file=/var/log/rclone-immich.log

La trampa más común: hacer backup solo de la base de datos o solo de los archivos. La base de datos sin archivos te deja con metadatos apuntando a la nada. Los archivos sin base de datos te dejan con una carpeta organizada por fecha de subida pero sin reconocimiento facial, sin álbumes, sin estrellas, sin mapa. Necesitas ambos, siempre juntos.

El job automático de Immich corre cada noche a las 2 AM y conserva 14 dumps por defecto, número ajustable en Admin → Jobs → Database backup. Para bibliotecas grandes, conviene complementar ese dump con un snapshot semanal completo de UPLOAD_LOCATION y subirlo a un proveedor de storage frío (Backblaze B2 a USD 6/TB-mes es la mejor relación precio/volumen del mercado en 2026).

Exponer Immich por HTTPS con Traefik o Nginx Proxy Manager

Si solo quieres Immich en tu LAN local, no necesitas nada de esto: conecta la app móvil a http://IP-LAN:2283 y listo. El problema aparece cuando quieres subir fotos desde una red externa (4G/5G del celular, oficina, hotel): la app necesita HTTPS con un certificado válido, y para eso necesitas un reverse proxy.

La opción más limpia en stacks Docker es Traefik. Immich debe vivir en la raíz de un subdominio dedicado (fotos.tudominio.com) y no bajo un sub-path como tudominio.com/fotos, porque la app móvil no soporta paths arbitrarios en la URL.

# Ejemplo de configuración Traefik para Immich (en docker-compose.yml)
# Pegar dentro del servicio 'immich-server', manteniendo la config que ya tienes:
#   labels:
#     - "traefik.enable=true"
#     - "traefik.http.routers.immich.rule=Host(`fotos.tudominio.com`)"
#     - "traefik.http.routers.immich.entrypoints=websecure"
#     - "traefik.http.routers.immich.tls.certresolver=letsencrypt"
#     - "traefik.http.services.immich.loadbalancer.server.port=2283"
#   networks:
#     - traefik-proxy
# CRÍTICO: Traefik v3 tiene timeout por defecto de 60s, INSUFICIENTE para subir
# fotos grandes. Subir a 10 min en la config estática de Traefik:
#   entryPoints:
#     websecure:
#       address: ":443"
#       transport:
#         respondingTimeouts:
#           readTimeout: 600s
#           idleTimeout: 600s

Con Nginx Proxy Manager el equivalente es agregar client_max_body_size 50000M; y proxy_request_buffering off; en la config avanzada del proxy host, junto con timeouts de 600 segundos. Sin esto, las subidas de fotos sobre 50 MB fallan silenciosamente o dejan la app mostrando “uploading 99 %” durante minutos antes de cortar.

Si tu biblioteca es sensible (y toda biblioteca de fotos lo es), considera mantener Immich accesible solo vía VPN (WireGuard o Tailscale) en lugar de exponerlo a internet pública. La app móvil se conecta igual a un nombre DNS privado que a uno público, y reduces la superficie de ataque a cero.

Troubleshooting: errores comunes y cómo resolverlos

La curva de aprendizaje de Immich tiene tres o cuatro tropiezos clásicos. La mayoría se resuelven en cinco minutos si sabes dónde mirar.

# Error 1: "unknown shorthand flag: 'd' in -d" al hacer docker compose up -d
# Causa: tienes docker-compose v1 (binario python) en lugar de docker compose v2
# Fix: desinstalar docker-compose v1 e instalar el plugin compose
sudo apt remove docker-compose
sudo apt install docker-compose-plugin
docker compose version  # debe decir "Docker Compose version v2.x"
# Error 2: "permission denied" abriendo .env
# Causa: permisos inseguros o propiedad/owner inesperado en el archivo
chmod 600 .env
chown $USER:$USER .env
# Error 3: la app móvil no encuentra el servidor
# Causa típica: IP cambió (DHCP del router) o firewall local bloqueando 2283
# Fix 1: fija IP estática por DHCP reservation en el router
# Fix 2: abre el puerto en el firewall del servidor
sudo ufw allow 2283/tcp
sudo ufw reload
# Error 4: "Health check failed" en docker compose ps para immich-server
# Causa: el contenedor sigue arrancando (Postgres tarda), espera 5 minutos
docker compose logs immich-server --tail 50
# Si llevas >10 min así, revisa si DB_PASSWORD tiene caracteres especiales
# (el parser de .env rompe con '$', '&', '#', etc.)
# Error 5: el indexado ML se queda al 0% eternamente
# Causa: no hay RAM suficiente y el contenedor muere silenciosamente
docker stats immich_machine_learning
# Si ves memoria al límite, edita docker-compose.yml y agrega:
#   deploy:
#     resources:
#       limits:
#         memory: 4G

Si después de revisar todo esto Immich sigue sin arrancar, el log del contenedor database es tu mejor amigo: docker compose logs database --tail 100. Casi todos los problemas con el servidor caen en una de tres categorías: variable de entorno mal escrita en .env, bind mount apuntando a un directorio con permisos incorrectos, o Redis/Postgres sin terminar de inicializar en el primer arranque.

Cuándo NO usar Immich y alternativas honestas

Immich no es la opción correcta en todos los casos. Si tu biblioteca es pequeña (menos de 5.000 fotos), el costo de operar Immich no se justifica: una cuenta gratuita en Google Photos o iCloud resuelve mejor y sin dedicar una tarde al setup. Si necesitas sincronización bidireccional con clientes Photos/Mac de Apple y tu biblioteca vive casi exclusivamente en iCloud, Immich va a pelearse con iCloud en cosas raras: mejor Nextcloud con la app de Nextcloud Photos, que sí integra con iOS.

Si tu presupuesto de RAM está limitado y quieres algo más ligero, PhotoPrism ocupa ~500 MB en lugar de los 4 GB mínimos de Immich, pero su reconocimiento facial es más lento y la búsqueda semántica está en beta desde hace años. En Raspberry Pi 4 (4 GB de RAM), PhotoPrism funciona; Immich no, ni con ML desactivado. Para el caso intermedio (MiniPC x86 con 8 GB), Immich sigue ganando.

Si tu objetivo es reemplazar Google Photos por algo igual de simple y no quieres aprender Docker, Jellyfin (servidor multimedia) + sincronización con Syncthing hacia un VPS barato es un setup más crudo pero menos piezas que mantener. Es la solución honesta para quien solo quiere backup automático de fotos sin meterse en ML, reconocimiento facial ni PostgreSQL con pgvector.

Resumen y decisión final

Si tienes un servidor Linux con 8 GB de RAM o más, una biblioteca de fotos que vale la pena proteger y tolerancia a mantener un servicio Docker con sus actualizaciones mensuales, Immich es la mejor alternativa open source a Google Photos en 2026. La instalación toma 30 minutos con la receta de esta guía, el backup automático móvil funciona sin tocar nada después del primer setup, y la búsqueda por rostro + semántica te hace redescubrir fotos olvidadas.

Si vienes de Nextcloud o PhotoPrism, vale la pena probar Immich en una biblioteca paralela antes de migrar. El comando immich-cli upload --recursive mueve bibliotecas enteras, y la importación desde Google Takeout preserva metadatos. Los downsides reales son tres (8 GB de RAM mínimo, requisito de CPU x86-64-v2 desde v3, y dependencia de Docker Compose v2), y para stacks modernos ninguno es un blocker.

Empieza por instalar el stack con la receta de la sección de instalación, configura el backup automático del celular, y deja indexar la biblioteca durante la noche. Al día siguiente vas a tener una vista de fotos idéntica a Google Photos pero corriendo en tu servidor, sin publicidad, sin análisis de contenido, y con la libertad de cambiar de software mañana sin perder nada.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux