Immich ha madurado muchísimo, pero no lo trataría como una aplicación cualquiera. Si lo usas para probar self-hosting, da igual. Actualizas, rompes, reinstalas y aprendes algo. Si lo usas para guardar fotos familiares, vídeos del móvil y recuerdos que no puedes volver a descargar, la cosa cambia bastante.
Ahí Immich deja de ser “otro contenedor” y pasa a ser una pieza delicada de casa.
No lo digo para meter miedo. Lo digo porque me parece una de las mejores alternativas reales a Google Photos y precisamente por eso conviene usarlo bien. El entusiasmo inicial suele ser instalarlo, importar fotos, activar la app móvil y disfrutar de una interfaz que, por fin, no parece un proyecto abandonado. La parte aburrida viene después: actualizarlo durante meses, leer notas de versión, cuidar PostgreSQL, vigilar almacenamiento y tener claro cómo volver atrás si algo sale mal.
Esa parte aburrida es la que separa un experimento bonito de un servicio doméstico de verdad.
Lo primero: saber qué estás protegiendo#
Antes de hablar de actualizar, hay que separar las piezas. Immich no es una caja mágica. Normalmente tienes al menos cuatro componentes con valor distinto:
- Los originales de fotos y vídeos.
- La base de datos PostgreSQL.
- Las miniaturas, cachés y resultados de machine learning.
- La configuración del despliegue.
Los originales son lo sagrado. La base de datos también importa mucho porque contiene usuarios, álbumes, relaciones, metadatos, estado de importación y bastante estructura interna. Las miniaturas son cómodas, pero se pueden regenerar. La configuración importa porque te permite reconstruir el servicio sin jugar a adivinar variables de entorno.
Esta distinción cambia cómo actualizo. No necesito tratar todo igual. Necesito proteger muy bien lo que no puedo perder y aceptar que algunas piezas se pueden reconstruir con tiempo.
El error común es copiar “la carpeta de Immich” y pensar que ya está. Depende de cómo lo tengas montado, puede que hayas copiado parte de los datos, puede que no hayas hecho un backup consistente de PostgreSQL y puede que estés confiando en volúmenes Docker que no recuerdas ni dónde viven. Mala receta para el día que algo se tuerce.
Mi regla: no actualizar sin backup reciente#
No actualizo Immich si no tengo un backup reciente de la base de datos y una copia razonable de los originales. Punto.
Para PostgreSQL prefiero un dump consistente, no una copia en caliente de archivos internos. Copiar el directorio de datos de una base viva puede funcionar en algunos escenarios si se hace bien, pero no es el camino que elegiría para una instalación doméstica normal. Un dump es más fácil de entender, mover, verificar y restaurar en un entorno limpio.
Para los originales, la estrategia depende del tamaño. Si tienes cientos de gigas o varios teras, no vas a duplicarlo todo antes de cada actualización. Pero sí deberías tener una política clara: copia local, copia externa, snapshots si aplica y alguna verificación periódica. Si la única copia de tus fotos vive en el mismo disco donde corre Immich, el problema no es la actualización. El problema es anterior.
Antes de actualizar me gusta comprobar tres cosas:
- Cuándo fue el último backup de PostgreSQL.
- Si los originales están incluidos en mi estrategia de backup.
- Si puedo restaurar al menos una muestra sin depender del servicio vivo.
Esa última parte es importante. Un backup que nunca has restaurado es una promesa, no una garantía. No hace falta montar un simulacro completo cada semana, pero sí haber probado el camino alguna vez.
Leer las notas de versión sin convertirlo en tesis#
No hace falta estudiar cada cambio como si fueras a mantener Immich upstream, pero sí conviene leer las notas antes de actualizar. Sobre todo cuando saltas varias versiones.
Busco especialmente:
- Cambios de Docker Compose.
- Migraciones de base de datos.
- Cambios en variables de entorno.
- Requisitos nuevos de servicios auxiliares.
- Avisos sobre versiones mínimas.
- Cambios en el formato de almacenamiento o jobs internos.
Si hay migración de base de datos, no actualizo con prisa. Las migraciones suelen ir bien, pero son el punto donde menos me apetece descubrir que el backup era viejo, que el disco estaba justo de espacio o que el contenedor se reinició a mitad por una tontería.
También miro issues recientes si la versión acaba de salir. No para caer en paranoia, sino para evitar ser el primer voluntario en casa. En servicios familiares, esperar unos días puede ser una decisión muy sensata. La urgencia de tener el último release rara vez compensa el riesgo de romper fotos un sábado por la noche.
Esto no significa quedarse en versiones antiguas eternamente. Eso también es mala idea. Significa actualizar con ritmo, no con ansiedad.
No saltaría muchas versiones de golpe#
Si llevo meses sin actualizar, no me gusta saltar directamente a la última versión sin mirar. A veces no pasa nada. Otras veces te comes varios cambios acumulados, migraciones antiguas, variables nuevas y comportamientos que ya nadie explica con detalle porque para la comunidad pasaron hace tiempo.
Prefiero hacer saltos más controlados cuando el retraso es grande. Revisar versiones intermedias importantes, actualizar por tramos si las notas lo recomiendan y confirmar que el servicio queda sano antes de seguir.
En Docker Compose esto parece pesado, pero no lo es tanto. Cambias versión, levantas, miras logs, pruebas login, compruebas la app móvil, revisas trabajos pendientes y sigues. Lo importante es no convertir una actualización atrasada en una apuesta de todo o nada.
También evitaría actualizar Immich junto con otras piezas grandes el mismo día. Nada de “ya que estoy, actualizo Docker, el host, PostgreSQL, el NAS y el reverse proxy”. Esa frase ha roto más homelabs que muchas vulnerabilidades.
Si Immich guarda fotos importantes, la ventana de mantenimiento debe tener un objetivo: actualizar Immich. Lo demás puede esperar.
Una copia del compose vale oro#
Parece básico, pero mucha gente no tiene versionado su docker-compose.yml, su .env o sus notas de despliegue. Luego llega el día de reconstruir y todo depende de memoria, historial de terminal y suerte.
Yo guardaría como mínimo:
docker-compose.yml..envsin exponer secretos en sitios raros.- Versión actual de las imágenes.
- Ruta real de originales.
- Ruta de backups.
- Comando de backup de PostgreSQL.
- Comando de restauración probado.
- Notas de reverse proxy y volúmenes.
No hace falta montar una plataforma GitOps doméstica si no te apetece. Pero un repositorio privado con configuración saneada y notas operativas ya cambia mucho. Si mañana el host muere, quieres reconstruir, no investigar tu propio pasado.
También me gusta anotar la versión antes de tocar nada. Parece absurdo hasta que una actualización falla y quieres volver a la imagen anterior. Saber exactamente desde dónde venías evita búsquedas tontas.
La actualización que haría en casa#
Mi proceso ideal para actualizar Immich en casa sería bastante aburrido. Eso es buena señal.
Primero aviso mentalmente de que es una ventana de mantenimiento. No lo hago justo antes de dormir ni cuando alguien está importando fotos. Si hay móviles subiendo contenido, espero o paro sincronización.
Después reviso espacio libre. Las migraciones, thumbnails y trabajos internos pueden necesitar margen. Actualizar con el disco al 95 por ciento es pedirle al sistema que improvise donde no debe.
Luego hago backup de PostgreSQL y verifico que el archivo existe, pesa algo razonable y está fuera del contenedor. Si el backup queda dentro del mismo volumen que vas a tocar, ayuda poco.
Compruebo que los originales siguen cubiertos por backup. No necesariamente ejecuto una copia completa en ese momento, pero sí confirmo que no estoy ante una instalación huérfana.
Guardo el compose actual y la versión de imágenes. Si uso Git, commit. Si no, copia fechada. Lo importante es poder volver a ver qué había.
Leo notas de versión. Si hay cambios de compose, los aplico con calma. Si hay migraciones grandes, asumo que la primera arrancada puede tardar.
Actualizo imágenes, levanto servicios y miro logs. No solo “está running”. Running significa poco. Quiero ver que la app arranca, que conecta a PostgreSQL, que no hay migraciones fallidas y que los workers no están en bucle.
Después pruebo lo básico: login web, timeline, búsqueda, vista de álbum, reproducción de vídeo, subida desde móvil si aplica y acceso desde fuera si uso reverse proxy o VPN.
Por último, dejo pasar un rato y vuelvo a mirar logs. Algunos problemas no salen en los primeros diez segundos. Immich puede empezar trabajos de fondo, regeneraciones o tareas que tardan.
Nada de esto es sofisticado. Es mantenimiento normal. Precisamente por eso funciona.
Qué miraría en los logs#
No necesito leer cada línea, pero sí busco patrones claros.
Me preocupan errores de conexión a PostgreSQL, migraciones fallidas, permisos sobre la biblioteca, rutas que no existen, servicios auxiliares que no responden, problemas con Redis si está en el stack, workers reiniciando y errores repetidos al procesar assets.
Un error aislado durante el arranque puede no ser grave. Un bucle repetido sí. Un contenedor que reinicia solo también. Un worker que no procesa nada y llena logs merece atención.
También miraría si hay trabajos atascados desde la interfaz. Después de una actualización puede haber tareas pendientes. Eso no es malo por sí mismo. Lo malo es que no avancen nunca o que saturen el host hasta dejarlo torpe.
En máquinas pequeñas, Immich puede consumir bastante cuando genera miniaturas, procesa vídeos o ejecuta machine learning. Si actualizas y de pronto el servidor parece sufrir, no siempre es que algo esté roto. Puede estar haciendo trabajo acumulado. Aun así, conviene distinguir carga normal de incendio.
Rollback: pensarlo antes, no durante#
El rollback se prepara antes de actualizar. Durante el problema todo cuesta más.
Volver a la imagen anterior puede ser fácil si la base de datos no ha migrado. Si ha migrado, quizá ya no puedes arrancar la versión antigua sin restaurar también PostgreSQL. Este detalle importa mucho.
Por eso guardo el backup justo antes de actualizar. Si algo falla después de una migración, el camino limpio suele ser parar servicios, restaurar base de datos previa, volver a la versión anterior del compose y levantar de nuevo. Si los originales no se tocaron, perfecto. Si la actualización modificó estructura o ejecutó trabajos sobre archivos, hay que leer bien qué pasó antes de asumir.
No improvisaría rollback borrando volúmenes a ciegas. Tampoco mezclaría varios intentos sin tomar notas. Si algo va mal, lo mejor es parar, leer logs, identificar en qué punto falló y decidir. El pánico escribe comandos bastante malos.
Una opción útil es tener un entorno de prueba mínimo. No hace falta clonar toda la biblioteca. Puedes restaurar una muestra pequeña con una copia de la base o levantar una instalación aparte con unas cuantas fotos. Para saltos grandes, eso da tranquilidad.
La app móvil también cuenta#
Cuando hablamos de Immich pensamos mucho en el servidor, pero la app móvil es parte del sistema. Si cambias servidor y la app deja de subir, tienes un problema silencioso.
Después de actualizar, compruebo que el móvil sigue autenticado, que la subida automática funciona y que no hay cola atascada. También reviso permisos de fotos en iOS o Android si algo se comporta raro.
La peor avería no es siempre perder fotos. A veces es creer que se están sincronizando cuando llevan semanas sin hacerlo. Eso es especialmente fácil si vienes de Google Photos, donde mucha gente da por hecho que todo sube solo.
Con Immich prefiero tener una pequeña rutina: abrir la app de vez en cuando, mirar estado de backup, confirmar que las fotos recientes aparecen en web y revisar si hay errores. No es elegante, pero las fotos familiares merecen más que fe.
Cuándo no actualizaría#
Hay momentos donde no tocaría Immich aunque haya versión nueva.
No actualizaría si el backup falló. No actualizaría si el disco está casi lleno. No actualizaría si el host ya tiene errores raros. No actualizaría justo antes de un viaje. No actualizaría de noche, cansado y con prisa. No actualizaría si acabo de hacer cambios grandes en red, almacenamiento o reverse proxy.
Tampoco actualizaría el primer día de una versión importante si no necesito nada de esa versión. Prefiero dejar que otros encuentren los problemas obvios. Suena egoísta, pero en casa no hay premio por ser valiente con los recuerdos familiares.
Sí actualizaría con cierta regularidad. Quedarse demasiado atrás acumula deuda. El punto sensato está entre perseguir cada release y abandonar el servicio durante un año.
Señales de que Immich ya es producción doméstica#
Hay un momento curioso en self-hosting: una app deja de ser hobby cuando alguien más empieza a depender de ella.
Con Immich pasa rápido. Primero subes tus fotos. Luego añades otro móvil. Luego creas álbumes. Luego alguien te pide una foto y tú ya no abres Google Photos, abres Immich. En ese momento la aplicación ya no es una prueba. Es producción doméstica, aunque esté en una VM pequeña y tenga un nombre simpático en el dashboard.
Cuando llega ese punto, cambia el trato:
- Backups de verdad.
- Actualizaciones con ventana.
- Notas de operación.
- Restauración probada.
- Monitorización básica.
- Espacio libre vigilado.
- Paciencia con versiones nuevas.
No hace falta montar una empresa dentro de casa. Pero sí dejar de jugar a la ruleta con datos que importan.
Lo que haría si empezara hoy#
Si montara Immich desde cero para fotos familiares, lo haría con una arquitectura bastante sencilla.
Aplicación en Docker Compose en un host que pueda mantener sin drama. PostgreSQL con backups automatizados y restauración documentada. Originales en almacenamiento fiable, accesible sin depender de magia, con copias externas. Reverse proxy o VPN según necesidad real, no por enseñar el servicio a internet porque sí. Actualizaciones periódicas, pero nunca automáticas a ciegas.
También separaría claramente lo que puedo regenerar de lo que no. Miniaturas y cachés no me quitan el sueño. Originales y base de datos, sí.
Y antes de invitar a más gente de casa, probaría una restauración. Aunque sea pequeña. Levantar Immich en otro entorno con una muestra y confirmar que entiendo el proceso. Esa tarde aburrida puede ahorrarte un disgusto enorme.
Immich merece respeto, no miedo#
Immich me parece un proyecto fantástico. Tiene una mezcla difícil: utilidad real, interfaz buena, ritmo de desarrollo alto y una comunidad enorme alrededor. Para un homelab doméstico, pocas aplicaciones tienen tanto sentido como una galería de fotos propia.
Pero las fotos familiares cambian las reglas. No son contenedores, no son logs, no son ISOs que puedes bajar otra vez. Son datos con valor emocional. Y cuando una aplicación guarda algo así, actualizar deja de ser un gesto mecánico.
Mi postura es esta: usar Immich, sí. Disfrutarlo, también. Pero actualizarlo como quien toca una pieza importante de casa, no como quien reinicia un laboratorio.
Backup reciente, notas leídas, compose guardado, logs revisados y rollback pensado antes de tocar nada. No es una receta espectacular. Es casi aburrida.
Justo lo que quieres cuando lo que hay dentro son recuerdos.