Por qué autoalojar Immich en un VPS
Sus fotos están entre los datos más sensibles que confía a una nube: rostros, lugares, hábitos, geolocalización. Immich reproduce la experiencia de Google Photos, aplicaciones móviles incluidas, pero sobre una infraestructura que le pertenece. Desde la versión 3.0.0, su stack se ha aligerado: la extensión de terceros pgvecto.rs se ha eliminado en favor de los índices HNSW nativos de PostgreSQL (pgvector), lo que reduce las dependencias y simplifica las copias de seguridad de la base de datos. Un VPS dedicado le permite aislar el exigente servicio de ML, dimensionar el almacenamiento según su fototeca y evitar que sus imágenes sirvan para entrenar modelos de terceros. Usted sigue siendo dueño del cifrado, de las copias de seguridad y del acceso.
Lo que aporta autoalojar Immich
- Copia de seguridad automática desde iOS y Android en cuanto se toma una foto, como una nube privada.
- Reconocimiento facial y búsqueda semántica ejecutados en su servidor, sin envío a terceros.
- Capacidad igual a la de su disco VPS: sin cuota impuesta, sin facturación por GB.
- Compartición de álbumes mediante un enlace seguro que usted controla y revoca en cualquier momento.
- Soporte multiusuario: cada miembro del hogar o del equipo tiene su biblioteca aislada.
- Metadatos EXIF, mapas y líneas de tiempo conservados localmente, sin explotación publicitaria.
Requisitos de hardware y software
Immich es el más exigente de esta serie por su servicio de machine learning. Cuente con 4 GB de RAM como mínimo, pero se recomiendan de 6 a 8 GB si el reconocimiento facial procesa una fototeca extensa. De 2 a 4 vCPU permiten digerir la indexación inicial sin bloquear la interfaz. El almacenamiento es el factor clave: prevea con holgura, porque una biblioteca familiar supera rápidamente los 100 GB; un VPS con disco ampliable es lo ideal. En cuanto al software: Docker y docker compose v2, un dominio (photos.votreentreprise.com) y suficiente espacio de swap para absorber los picos del modelo de ML durante la primera importación.
Desplegar Immich paso a paso
Preparar el VPS y el almacenamiento
Actualice el sistema, instale Docker y cree después un punto de montaje dedicado a los medios, por ejemplo
/mnt/photos, separado del disco del sistema. Active al menos 2 GB de swap para el servicio de machine learning.Obtener el compose oficial y el .env
Descargue el
docker-compose.ymly el archivoexample.envdel repositorio de Immich conwget. Renómbrelo a.envy defina despuésUPLOAD_LOCATION=/mnt/photos, la contraseña de la base de datos yDB_DATA_LOCATIONen un volumen persistente.Comprender los tres servicios (v3+)
Desde la versión 3.0.0, la stack arranca
immich-server,immich-machine-learningydatabase(PostgreSQL conpgvector). Redis ya no es un servicio separado — va integrado en el servidor Immich. La extensiónpgvecto.rsse ha eliminado: no utilice la antigua imagen de base de datosghcr.io/immich-app/postgres, sustituida por la imagen oficial de PostgreSQL 17 conpgvector.Arrancar la pila y crear el administrador
Ejecute
docker compose up -dy espere a que se descarguen las imágenes de ML, que son voluminosas. Abra el puerto2283a nivel interno y cree después la cuenta de administrador mediante el asistente web, antes de invitar a otros usuarios.Proteger con un reverse proxy y SSL
Coloque Caddy delante del servidor:
photos.votreentreprise.com { reverse_proxy immich-server:2283 }. Aumente el tamaño máximo de subida del proxy (client_max_body_sizeen Nginx), porque los vídeos pueden ser pesados; de lo contrario, los envíos desde el móvil fallan.Configurar la aplicación móvil
Instale Immich desde la App Store o la Play Store, indique
https://photos.votreentreprise.comcomo URL del servidor, inicie sesión y active después la copia de seguridad automática del carrete para replicar de forma continua sus nuevas fotos.
Durante la primera importación masiva, lance la generación de miniaturas y de embeddings de ML en un periodo de baja actividad y vigile la RAM con docker stats. Si el servicio de machine learning se satura, puede apuntarlo temporalmente al modelo más ligero en los ajustes y volver después a un modelo más preciso una vez terminada la indexación inicial. Así evita que el VPS se hunda bajo la carga de ese primer escaneo.
¿Poca RAM? Ejecute Immich sin el contenedor de IA
Si su VPS solo tiene de 2 a 4 GB de RAM, retire el servicio immich-machine-learning del archivo compose. Immich arranca perfectamente sin él: la copia de seguridad móvil, la línea de tiempo, los álbumes, la compartición, la vista de mapa y la búsqueda manual siguen funcionando todos — solo pierde el reconocimiento facial automático y la búsqueda inteligente en lenguaje natural. Vuelva a añadir el contenedor de machine learning más adelante, cuando pase a un VPS más grande, e Immich indexará en ese momento su biblioteca existente para la búsqueda por IA.
Resolver los errores de machine learning
El contenedor immich-machine-learning puede volverse inaccesible en silencio por dos motivos distintos: un error de red de Docker o una parada silenciosa por falta de memoria RAM. Los síntomas típicos son entradas como Machine learning request to 'http://immich-machine-learning:3003' failed: fetch failed en los registros del servidor, o tareas bloqueadas del tipo Unable to run job handler (AssetDetectFaces). El diagnóstico lleva menos de cinco minutos.
Diagnosticar y corregir el servicio de ML
Comprobar la red de Docker
Ejecute
docker network inspect immich_defaulty localice siimmich-servereimmich-machine-learningfiguran ambos en la listaContainers. Si falta uno, revise el camponetworksde sudocker-compose.yml: ambos servicios deben referenciar la misma red.Detectar un OOM silencioso
Ejecute
dmesg | grep -i oompara ver si el kernel ha matado un proceso. Cada OOM kill menciona el nombre del contenedor y la cantidad de memoria solicitada. Un resultado vacío no confirma la ausencia de un OOM si el sistema se ha reiniciado desde el incidente.Consultar los registros del contenedor de ML
Ejecute
docker logs immich-machine-learning --tail 50para observar las últimas líneas. Una parada limpia o un error de carga del modelo aparecerá ahí con más claridad que un OOM silencioso del kernel.Reiniciar el servicio de ML
Si la red es correcta y la RAM es suficiente, reinicie únicamente ese servicio con
docker compose restart immich-machine-learningy observe si las tareas se reanudan en los minutos siguientes mediantedocker logs -f immich-machine-learning.
VPS ≤ 2 GB: desactivar el machine learning
El servicio de ML acumula CLIP, el reconocimiento facial y el OCR, es decir, unos 2 GB de RAM en el pico. En un VPS con solo 2 GB, añada MACHINE_LEARNING_ENABLED=false a su archivo .env y reinicie después la pila con docker compose up -d. La copia de seguridad móvil, los álbumes y la búsqueda manual siguen funcionando. El reconocimiento facial y la búsqueda por IA se activarán en cuanto pase a un VPS con 4 GB de RAM o más.
Migrar de la v2.4.x a la v3.0.0: la ruta obligatoria
La versión 3.0.0 de Immich es una ruptura arquitectónica: pgvecto.rs desaparece y los índices vectoriales se reconstruyen de forma nativa con pgvector (HNSW). Esta reconstrucción es bloqueante — la base de datos recalcula todos los vectores de su fototeca antes de volver a poner el servidor en línea, lo que puede llevar de varios minutos a varias horas según el tamaño de la biblioteca. Antes de saltar directamente a la v3, debe pasar obligatoriamente por la versión 1.132.3: es el punto de bisagra que prepara la migración de los índices. Partir de una versión anterior sin pasar por ese hito provoca un error de migración de la base de datos y bloquea el arranque del servidor.
Procedimiento de actualización v2.4.x → v3
Hacer una copia de seguridad de la base de datos antes que nada
Antes de cualquier actualización, exporte la base con
docker exec -t immich_postgres pg_dumpall -c -U postgres > backup_immich_avant_v3.sql. Conserve también la carpetaUPLOAD_LOCATION. Una migración HNSW fallida a mitad de camino y sin copia de seguridad deja la base en un estado incoherente.Subir primero a la versión 1.132.3
Modifique
docker-compose.ymlpara utilizar la versiónv1.132.3(tag exacto) enimmich-serveryimmich-machine-learning. Ejecutedocker compose pull && docker compose up -d. Deje que el servidor arranque por completo y compruebe que los trabajos de fondo se reanudan sin error endocker logs immich-server.Pasar a la imagen oficial de PostgreSQL (solo v3)
La v3 utiliza la imagen oficial de PostgreSQL 17 con
pgvector, y ya no la imagen personalizadaghcr.io/immich-app/postgres. En eldocker-compose.ymlque se entrega con la v3, el serviciodatabaseapunta adocker.io/tensorchord/pgvecto-rs:pg14-v0.2.0sustituido porpostgres:17-bookwormcon la extensiónpgvector. Utilice el archivo compose oficial de la v3 y no recicle el archivo de la v2.Actualizar a la v3.0.0 y esperar la reindexación HNSW
Sustituya los tags por
v3.0.0y descargue las imágenes:docker compose pull && docker compose up -d. La migración HNSW arranca automáticamente en el primer lanzamiento. Durante esta fase, el servidor sigue disponible, pero la búsqueda inteligente y el reconocimiento facial quedan suspendidos. Siga el progreso endocker logs -f immich-server: una líneaFinished migrationconfirma el final. En una fototeca de 50 000 fotos, cuente entre 10 y 30 minutos según el número de vCPU asignados.Comprobar los trabajos de fondo tras la migración
Abra la interfaz web, vaya a Administración → Tareas y confirme que ningún trabajo está en estado de error. Si hay tareas
Smart SearchoFace Detectionbloqueadas, relánzelas desde la interfaz. Los nuevos vectores HNSW se recalculan una sola vez: las importaciones posteriores se indexan con normalidad.
Immich v2 frente a v3: lo que cambia en la práctica
Desplace la tabla
| Aspecto | v2.4.x | v3.0.0 |
|---|---|---|
| Extensión vectorial | `pgvecto.rs` (imagen personalizada) | `pgvector` HNSW nativo (PostgreSQL oficial) |
| Servicios Docker | 4 (server, ML, Redis, DB) | 3 (server, ML, DB — Redis integrado) |
| Actualización directa desde v2 | No — hay que pasar obligatoriamente por v1.132.3 | Sí desde v1.132.3 |
| Copia de seguridad de la base | Depende de la imagen personalizada | Compatible con `pg_dump` estándar |
| Reindexación al arranque | No | Sí (bloqueante, duración según el tamaño) |