Guía de Immich: tus fotos en tu propio servidor

Si tus fotos ya no caben en la cuenta de Google, Immich resulta tentador: guarda los originales en un servidor que controlas y ofrece búsqueda, álbumes y subida desde el móvil. Eso no elimina el trabajo de mantenerlo disponible y recuperar una copia. Antes de mover una biblioteca o cancelar nada, conviene comprobar tres gestos: encontrar una foto, compartirla y recuperar el original si desaparece del servidor.

Esta guía explica la instalación y las copias. Añadimos pruebas propias del 27 y el 29 de octubre de 2026 con una instancia aislada de Immich v3.1.0 y cuatro fotos con licencia abierta, no con la fototeca privada ni con Google Fotos. Sirve para ver qué funcionó y, sobre todo, qué queda sin demostrar.

¿Ya lo tienes instalado? Ve directamente a la prueba de uso, al ensayo de restauración completa o a qué guardar para recuperar tus fotos.

¿Prefieres verlo antes de instalar? En este vídeo de 2 minutos y medio seguimos una biblioteca pequeña: buscar una foto, compartir un álbum y comprobar que vuelven los originales tras restaurar. Es el mismo caso acotado que documentamos abajo, no una prueba de tu propia colección. Para repetirlo, empieza por los tres gestos de uso y revisa qué debes copiar.

[aff]Hay enlaces de afiliado más abajo: si compras algo desde ellos me llevo una pequeña comisión y a ti no te cuesta ni un céntimo más. En calidad de Afiliado de Amazon, obtengo ingresos por las compras adscritas que cumplen los requisitos aplicables.

Qué es Immich y qué te da

Immich (se pronuncia “emich”, es un juego con “image”) es software libre. Un equipo muy activo lo actualiza casi cada semana, así que da algo de vértigo al principio, pero la instalación base lleva tiempo siendo estable.

Lo que hace, en cristiano:

• Subida automática de los álbumes que elijas en el móvil, con condiciones de red y segundo plano que conviene comprobar en tu teléfono.
• Reconocimiento facial y búsqueda por IA: busca “playa”, “perro” o la cara de tu sobrina y los encuentra. Eso lo hace un contenedor aparte, en tu servidor, sin mandar nada fuera.
• Álbumes compartidos, líneas de tiempo, mapa por geolocalización, usuarios múltiples para toda la familia.
• Apps de iOS y Android, más una web para el escritorio.

No es un clon pixel a pixel de Google Photos, y conviene saberlo: al ser un proyecto en desarrollo rápido, de vez en cuando una actualización trae cambios que hay que leer antes de aplicar. A cambio, controlas dónde se guardan los originales; la disponibilidad y las copias pasan a depender de tu instalación.

Antes de migrar: tres gestos en una biblioteca de prueba

En el laboratorio cargamos cuatro imágenes de Wikimedia Commons en una instalación separada de Immich v3.1.0. No es una medida de precisión, velocidad ni experiencia con miles de fotos.

Encontrar. Escribimos «gato en sofá» en la búsqueda contextual: el gato apareció en primer lugar y pudimos abrir el original. La espera de la captura de vídeo se recortó; no medimos cuánto tardaría una fototeca grande en indexarse o responder.

Compartir. Añadimos esa foto a un álbum, lo compartimos con una segunda cuenta del laboratorio y lo abrimos en otro navegador a 390 px de ancho. La descarga del original devolvió HTTP 200 y el archivo coincidió por SHA-256 con la fuente. Es un navegador estrecho en la misma máquina/red, no la app de un teléfono ni acceso desde fuera de casa.

Recuperar un archivo (27 de octubre). Retiramos temporalmente un original de la instancia aislada. Su URL devolvió 404; al reponer ese archivo desde una copia, devolvió 200 y el SHA-256 volvió a coincidir. Es una prueba de recuperación de un archivo, no de la base de datos, álbumes, miniaturas o biblioteca entera. Si sólo tienes una copia y desaparece, la galería puede seguir mostrando una miniatura mientras el original ya no abre.

Decisión práctica: prueba estos tres gestos con unas cuantas fotos antes de migrar. Después ensaya una restauración completa en otra instancia, incluida la base de datos, y comprueba desde el dispositivo/red que realmente usarás fuera de casa. Hasta entonces, conserva la copia en Google Fotos u otro destino: la búsqueda acertada en cuatro fotos no demuestra que Immich lo sustituya con la misma comodidad.

De una copia a una biblioteca que vuelve a abrir

Prueba del 29 de octubre de 2026. Recuperar una foto suelta no respondía a la pregunta importante: si pierdes la instalación, ¿vuelven también los usuarios, el álbum y sus permisos? Restauramos la biblioteca de prueba de cuatro fotos en otra instancia de Immich v3.1.0, con base de datos, carpetas y puerto propios. No borramos la instalación de origen ni usamos fotos privadas.

La fuente estaba apagada. Copiamos su almacenamiento completo y abrimos una copia de su PostgreSQL para sacar un volcado lógico. Ese SQL se importó en una base de datos nueva, antes de arrancar el servidor de destino; los archivos se repusieron manteniendo las rutas internas. Así comprobamos algo distinto de reiniciar el mismo contenedor o devolver una foto a su carpeta.

Qué tuvo que volver, además de las miniaturas

• Las cuatro fotos originales. Las descargamos desde la instancia recuperada. Los cuatro SHA-256 coincidieron con las imágenes de origen y con los archivos de la copia: no sólo se veían, también conservaban los mismos bytes.
• Las dos cuentas. Iniciamos sesiones nuevas con el propietario y con el invitado. No reutilizamos una sesión del servidor anterior.
• El álbum y el acceso compartido. La segunda cuenta encontró el mismo álbum de una foto y pudo descargar su original.
• La separación entre usuarios. Esa cuenta no pudo descargar otra foto que no tenía compartida. Sin iniciar sesión tampoco se pudieron obtener el álbum privado ni su original.

Qué demuestra: la base, los originales, el álbum y los permisos de esta pequeña biblioteca se pudieron recuperar juntos. Qué no cubre: vídeos, bibliotecas externas, búsqueda por IA después de restaurar, miles de archivos ni acceso desde fuera de casa. Tampoco prueba protección ante la pérdida del disco: las copias de este ensayo estaban en la misma máquina. Una copia de seguridad real necesita otro destino.

Repite la comprobación con lo que tú guardarías

Prepara un destino vacío y separado; revisa los montajes antes de importar nada. Conserva la versión y la configuración de la copia y sigue las instrucciones oficiales de restauración que correspondan a esa versión. Nuestro ensayo usó el procedimiento de v3.1.0, no una actualización a la vez que la recuperación.

Después entra con una cuenta recuperada, abre un álbum y descarga originales, no sólo miniaturas. Si compartes con otra persona, comprueba también qué puede abrir y qué sigue privado. Añade un vídeo y una biblioteca externa si forman parte de tu uso. Anota lo que no se haya podido recuperar antes de decidir borrar la copia de otro servicio.

El criterio para confiar no es «el trabajo de copia terminó bien», sino «he recuperado lo que necesito en otra instalación». En este ensayo lo superaron cuatro fotos y un álbum; tu comprobación debe cubrir tu colección y el dispositivo con el que la usarás.

Qué hardware necesita de verdad

Los requisitos oficiales indican 2 núcleos y 6 GB de RAM como mínimo; 4 núcleos y 8 GB recomendados. Con 4 GB contemplan desactivar las funciones de aprendizaje automático. Esa memoria debe estar disponible para Immich, no ocupada por otros servicios.

Un mini PC con 16 GB puede ser un punto de partida, pero esa cifra no garantiza fluidez con cualquier fototeca. La importación inicial, los vídeos, la concurrencia de trabajos y los demás servicios cambian la carga. La prueba de cuatro fotos de esta guía no dimensiona una biblioteca grande. Desde Immich v3, el contenedor de aprendizaje automático en amd64 requiere x86-64-v2; en una máquina virtual revisa también el tipo de CPU que expones al invitado.

Si tu servidor es una Raspberry Pi 5 (que es ARM), Immich también corre; ahí sí conviene la de 8 GB y no exprimir la IA con bibliotecas enormes. Lo tratamos en la guía de la Raspberry Pi 5 como servidor casero.

Antes de comprar, prueba con un equipo compatible que ya tengas y observa la carga durante una importación representativa. Si necesitas otro, compara memoria disponible, almacenamiento y ampliación; ni la CPU ni la RAM por sí solas acreditan el ruido o cuántos servicios podrás sumar.

Intel N100 · unidad analizada

Beelink Mini S12 Pro — Intel N100, 16 GB

La unidad analizada lleva N100, 16 GB DDR4, SSD M.2 SATA de 512 GB y un puerto Gigabit. Sus pruebas no describen todas las revisiones llamadas S12 Pro. La oferta actual no está confirmada; consulta el aviso antes de decidir.

• +iGPU con QuickSync para formatos y software compatibles
• +16 GB de RAM en la configuración de referencia
• +Plataforma x86-64 para software compatible con esa arquitectura

• -La unidad analizada tiene un puerto Gigabit; no acredita la red del anuncio actual
• -Para máquinas virtuales, calcula la RAM disponible; confirma si la revisión lleva M.2 SATA o NVMe

≈ 359 €

26 sep 2026 · Referencia histórica · oferta actual sin confirmar

Oferta sin confirmar: el anuncio mezcla SSD de 500/512 GB y anuncia 2,5 GbE. Nuestra unidad analizada tiene SSD SATA de 512 GB y red Gigabit; no acreditamos que la variante vendida sea equivalente.

Ver aviso y alternativas →

Para elegir con criterio según tu presupuesto y ver qué RAM admite cada equipo, tienes la comparativa de mini PC con el filtro de memoria y almacenamiento.

Reserva espacio para originales, miniaturas y vídeos derivados, además de una copia en otro destino. La documentación recomienda SSD local para PostgreSQL, nunca un recurso de red, y un sistema de archivos con permisos y propietarios Unix. Separar DB_DATA_LOCATION de UPLOAD_LOCATION evita confundir los datos de la base con las fotos.

Cómo se organiza por dentro

Antes de instalar, ayuda entender las piezas, porque luego la copia de seguridad depende de saber qué es qué. Immich no es un programa, son cuatro contenedores Docker que trabajan juntos más una carpeta con tus archivos.

El immich-server es la web y la API: lo que ves y por donde suben las fotos. El contenedor de machine-learning hace el reconocimiento facial y la búsqueda. PostgreSQL guarda los metadatos (álbumes, caras, ajustes), Redis gestiona la cola de trabajos en segundo plano. Y aparte de todo eso, una carpeta en tu disco, UPLOAD_LOCATION, donde viven las fotos de verdad. Quédate con esto: la base de datos y las fotos son cosas separadas. Lo retomamos en la copia de seguridad.

Instalación con Docker Compose, paso a paso

Doy por hecho que ya tienes Docker y el plugin de Docker Compose instalados en el servidor. Si vienes de montar Plex o cualquier otro contenedor, ya lo tienes; si no, en la guía de servidor multimedia con Plex y Docker está el punto de partida.

La forma recomendada por el propio proyecto es descargar sus ficheros oficiales, no copiar y pegar un compose de un tutorial cualquiera (que envejece mal). Son cuatro pasos.

1. Crea la carpeta y baja los ficheros oficiales.

mkdir immich && cd immich
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

2. Edita el .env. Es un fichero de texto con las variables de configuración. Revisa estas variables antes de arrancar:

• UPLOAD_LOCATION: la ruta de tu disco donde se guardarán las fotos. Ponla en un sitio con espacio de sobra (un disco de datos, no el del sistema).
• DB_PASSWORD: una contraseña para la base de datos. Cámbiala por una tuya.
• DB_DATA_LOCATION: almacenamiento local para PostgreSQL, distinto de la carpeta de originales. No lo sitúes en un recurso de red.
• TZ: tu zona horaria, por ejemplo Europe/Madrid, para que las fechas cuadren.

3. Levanta los contenedores. Desde la misma carpeta:

docker compose up -d

Ojo: es docker compose (con espacio), la versión moderna. El viejo docker-compose con guion puede dar errores. La primera vez tarda un rato porque se descarga las imágenes.

4. Abre la web. En el navegador, http://IP-de-tu-servidor:2283. La primera cuenta que registres es la de administrador. Creas usuario, entras y ya está el servidor listo.

Para actualizar, lee primero las notas de la versión y haz una copia consistente de base de datos, archivos y configuración. Anota la versión anterior. Después, desde la carpeta:

docker compose pull
docker compose up -d

Tras actualizar, abre originales y revisa los trabajos pendientes. Conserva las imágenes y la copia anteriores hasta validar la actualización: cambiar sólo la imagen no revierte una migración de base de datos.

Las apps del móvil

Instala la app desde la App Store o la Play Store, introduce la dirección de tu servidor y selecciona los álbumes que quieres subir. Según la documentación de copia móvil, la subida se ejecuta al abrir o reanudar la app y periódicamente en segundo plano. Por defecto usa Wi-Fi; puedes cambiarlo en los ajustes. Estar conectado a una Wi-Fi no basta si el móvil no puede alcanzar el servidor.

En Android, la optimización de batería puede detener el trabajo en segundo plano. En iOS, activa la actualización en segundo plano y ten en cuenta que el sistema decide cuándo ejecutarla: Immich no puede prometer una subida inmediata. Si las fotos están sólo en iCloud, la app necesita descargarlas temporalmente, con consumo de espacio y datos.

Compruébalo con dos fotos de prueba: una con la app abierta y otra después de dejarla en segundo plano. Verifica en la web que puedes abrir los originales y revisa la cola del móvil. Es una comprobación que debes hacer en tu dispositivo; nuestro ensayo local no prueba el comportamiento de Android ni de iOS.

Para entrar desde fuera, una VPN con acceso limitado al servidor evita publicar directamente el puerto 2283. Un proxy inverso con HTTPS es otra arquitectura, pero sí expone un servicio público: exige actualizaciones, autenticación y configuración correctas. Primero prueba el acceso que hayas elegido con datos móviles; no des por comprobada la conexión remota porque funcione en la Wi-Fi de casa.

Backup de Immich: qué guardar y cómo recuperarlo

Actualizado el 29 de octubre de 2026. Que aparezca un fichero en backups no significa que tus fotos tengan otra copia. Immich genera volcados de la base de datos; copiar los originales a otro destino sigue siendo tarea tuya.

Lo que debe salir del servidor

• Base de datos: un volcado válido conserva rutas, usuarios, álbumes y metadatos. Los automáticos se guardan en UPLOAD_LOCATION/backups; la documentación indica una copia diaria y retención de 14 por defecto, pero comprueba tu programación real. Esa carpeta en el mismo disco no te protege si el disco muere.
• Archivos: la recomendación oficial es copiar UPLOAD_LOCATION completo. No te quedes solo con library: según la configuración, los originales también viven en upload. profile contiene las imágenes de perfil; thumbs y encoded-video son derivados que se pueden regenerar, a costa de tiempo y procesamiento. Si has repartido carpetas entre discos, incluye sus destinos reales.
• Bibliotecas externas: añade las carpetas originales que montaste aparte. No pasan a estar dentro de UPLOAD_LOCATION por aparecer en la galería. Conserva también los montajes y las rutas que Immich ve dentro del contenedor.
• Configuración: guarda el Compose, la versión de Immich y el .env de esa instalación junto al registro de la copia. El .env contiene secretos: protégelo con cifrado y acceso restringido, no lo pegues en una consulta de soporte.

Una copia de DB_DATA_LOCATION mientras PostgreSQL escribe no sustituye sin más a un volcado. Para esta guía, usa el backup de base de datos que genera Immich y copia los archivos con tu herramienta habitual, por ejemplo Restic o Borg. La guía de copias 3-2-1 explica cómo separar copia local, destino externo y prueba de recuperación.

Primero la base de datos, después los archivos

Si las fotos siguen entrando mientras copias, la base de datos y el disco pueden representar momentos distintos. La documentación de Immich recomienda detener immich-server durante la copia para evitar ese desfase. Planifica esa pausa: la app no podrá subir fotos mientras el servicio esté parado.

Si necesitas mantenerlo disponible, el orden recomendado es volcado de base de datos primero y archivos después. Así pueden quedar archivos posteriores al volcado que haya que volver a subir tras restaurar. Al hacerlo al revés, la base de datos puede apuntar a fotos que nunca llegaron a la copia. No son dos formas equivalentes de hacer lo mismo.

En la interfaz descrita por la documentación actual puedes pedir un volcado desde Administración → Colas de trabajos → Crear trabajo → Create Database Dump. Espera a que termine y comprueba qué fichero ha generado antes de copiarlo. Los nombres pueden cambiar con la versión o el idioma.

Un comando en verde no demuestra que haya backup

Un error fácil de pasar por alto: en Bash, pg_dump | gzip puede terminar con código cero aunque falle el volcado, porque por defecto manda el resultado del último comando. Esta prueba no toca Docker ni tus fotos:

bash -c 'false | gzip > /dev/null'
echo "$?"  # 0: gzip ha terminado, pero el primer comando falló

bash -o pipefail -c 'false | gzip > /dev/null'
echo "$?"  # 1: ahora se propaga el fallo

Ejecutado el 29 de septiembre: devuelve 0 y 1, respectivamente. Es una prueba del comportamiento de Bash, no una restauración de Immich. Si automatizas el volcado, activa pipefail y haz que el trabajo se detenga ante el error; no publiques una copia parcial como buena. Que gzip -t pase solo acredita que el archivo comprimido es legible, no que contenga una base de datos completa ni las fotos.

Ensaya la recuperación sin tocar la galería que usas

Prepara otra instancia con carpetas, base de datos y puerto propios. Trabaja sobre copias, nunca sobre los directorios de producción, y no conectes a ella la subida automática de los móviles.

1. Anota la fecha del volcado, la versión de Immich y qué carpetas entraron en esa copia. Empieza con la misma versión para no mezclar una recuperación con una actualización.
2. Lleva los archivos a la nueva UPLOAD_LOCATION y, si existen, restaura las bibliotecas externas con las mismas rutas internas. Comprueba que la instancia de prueba no tiene acceso de escritura a los originales.
3. Sigue las instrucciones de restauración de tu versión. La documentación actual ofrece restauración desde la pantalla inicial o desde Mantenimiento. Restaurar reemplaza la base de datos del destino: revisa la dirección del navegador antes de confirmar. Para volcados anteriores a v2.5.0, usa el selector de versiones de la documentación.
4. Entra con un usuario recuperado, abre un álbum, descarga una foto original y reproduce un vídeo. Incluye elementos antiguos y recientes respecto a la fecha de la copia; si usas bibliotecas externas, prueba también un archivo de ellas. Ver miniaturas no basta: podrían seguir visibles aunque falten originales.

Deja anotados fecha, copia utilizada, comprobaciones y fallos. Esta lista es un procedimiento para ensayar, no una promesa de que cualquier copia restaurará. Antes de borrar los originales de otro servicio, necesitas haber recuperado y abierto tus archivos desde el backup.

Tres cosas que se atascan (y cómo salir)

Ningún montaje sale perfecto a la primera. Los tropiezos más habituales con Immich, y por dónde tirar cuando pasan:

El contenedor de IA se reinicia. Revisa los registros y si Docker marca OOMKilled antes de atribuirlo a la RAM. Si confirma falta de memoria, reduce la concurrencia de los trabajos o libera recursos. Si aparece un error de instrucciones de CPU, comprueba el requisito x86-64-v2 y la configuración de la máquina virtual. Desactivar aprendizaje automático reduce necesidades, pero no corrige permisos, disco lleno o una CPU virtual mal configurada.

La app del móvil no encuentra el servidor. Empieza por comprobar la dirección. Comprueba que pones http:// (no https:// si no has montado certificado), la IP correcta de tu servidor en la red local y el puerto :2283. Si desde el navegador del móvil tampoco abre, comprueba si el servidor responde desde otro equipo y si los contenedores están arrancados. Revisa después dirección, puerto, cortafuegos y conectividad entre ambas redes: puede fallar el servicio o la ruta hasta él.

Una actualización rompió algo. Revisa los registros y las notas de esa versión antes de recrear contenedores. Un fallo de migración, permisos o disco lleno no se arregla necesariamente reiniciando. Conserva la copia anterior y no borres volúmenes para probar suerte; si necesitas recuperar, sigue el ensayo de restauración y las instrucciones de la versión correspondiente.

Antes de reinstalar, guarda el error y revisa su contexto con docker compose logs --tail=100. Contrasta permisos, espacio y cambios de versión con lo que indiquen esos registros. No borres volúmenes para intentar resolver un fallo de conexión.

Immich merece una prueba si quieres controlar tus originales y aceptar el mantenimiento. Empieza con una colección pequeña, ensaya el acceso y la recuperación completa, y configura la copia antes de borrar nada de la nube. Si la prueba no cubre el uso que necesitas, todavía no has ganado una alternativa cómoda.