Los benchmarks de autoalojamiento de Immich revelan altos requisitos de RAM y necesidades críticas de respaldo
Un análisis técnico profundo de Immich muestra que la alternativa a Google Photos requiere más de 4 GB de RAM, respaldos estrictos de la base de datos y una configuración de red cuidadosa para un acceso móvil seguro.
Traducido automáticamente del original en inglés.
Según un análisis de despliegue publicado el 30 de octubre de 2026, los entusiastas del autoalojamiento que buscan reemplazar Google Photos con Immich se enfrentan a importantes compensaciones en hardware y operaciones. La revisión destaca que, aunque la plataforma de código abierto ofrece potentes funciones de aprendizaje automático, exige sustancialmente más recursos del sistema que las aplicaciones típicas de autoalojamiento ligeras. Los usuarios deben prepararse para una configuración compleja que involucra múltiples contenedores, políticas estrictas de contraseñas y procedimientos rigurosos de respaldo para evitar la pérdida de datos.
Qué sucedió
El autor desplegó Immich versión 3 en una estación de trabajo equipada con un procesador Intel Core Ultra 7 255H, 30 GB de RAM y almacenamiento NVMe ejecutando Ubuntu 24.04.5 LTS. El objetivo era medir el consumo real de recursos del stack, que incluye el servidor principal, un servicio de aprendizaje automático, VectorChord para Postgres y Valkey. A diferencia de herramientas más simples como Vaultwarden o Uptime Kuma, que operan dentro de unos pocos megabytes de memoria, Immich demostró ser una aplicación pesada. El conjunto de trabajo medido se estabilizó en aproximadamente 2,4 GB de RAM, con picos notables durante tareas de procesamiento de aprendizaje automático como la generación de miniaturas y la creación de incrustaciones (embeddings).
Más allá del uso bruto de recursos, el despliegue reveló varias trampas operativas que pueden romper la instalación o comprometer la seguridad. El autor señaló que el archivo Docker Compose cambia frecuentemente entre versiones debido al rápido ciclo de desarrollo del proyecto. Simplemente extraer nuevas imágenes sin actualizar la configuración de Compose puede llevar a fallos. Además, el componente de base de datos no es desechable; almacena todos los metadatos, álbumes, datos de reconocimiento facial e historial de ediciones. Esto hace esenciales los respaldos regulares tanto de la carpeta de biblioteca como de un volcado de Postgres antes de importar grandes colecciones de fotos.
Detalles clave
- Requisitos de memoria: El stack requiere al menos 4 GB de RAM libre para funcionar de manera fiable, con un uso base de alrededor de 2,4 GB y picos más altos durante tareas de ML.
- Complejidad de la base de datos: Postgres almacena metadatos críticos y no puede tratarse como efímero; los usuarios deben respaldar tanto el volcado de la base de datos como la carpeta de la biblioteca.
- Restricciones de contraseña: Los caracteres especiales en la variable de entorno
DB_PASSWORDrompen la cadena de conexión, lo que requiere contraseñas solo alfanuméricas a pesar de las advertencias estándar. - Volatilidad de la configuración: El archivo oficial de Docker Compose se actualiza con frecuencia, lo que obliga a descargar uno nuevo para cada actualización en lugar de simplemente extraer nuevas imágenes de contenedor.
- Seguridad de red: Las funciones de respaldo móvil requieren HTTPS mediante un proxy inverso o un túnel seguro como Tailscale, ya que exponer el servicio directamente a internet no es seguro.
- Servicios opcionales: El servicio de aprendizaje automático puede eliminarse para hardware más débil, aunque esto desactiva las funciones de búsqueda inteligente y reconocimiento facial.
Contexto
Immich ha ganado popularidad como una alternativa de autoalojamiento a Google Photos, acumulando más de 115.000 estrellas en GitHub. Proporciona aplicaciones móviles con capacidades de respaldo automático y utiliza aprendizaje automático para habilitar búsquedas en lenguaje natural, como encontrar fotos describiendo "atardecer sobre el agua". Esta funcionalidad depende de la generación de incrustaciones para imágenes, un proceso computacionalmente intensivo en comparación con el simple almacenamiento de archivos. Mientras que muchas herramientas de autoalojamiento están diseñadas para ejecutarse en servidores privados virtuales mínimos, la arquitectura de Immich refleja la naturaleza intensiva en recursos de los servicios en la nube comerciales, trasladando el costo de las tarifas de suscripción a la capacidad de hardware local.
La distinción entre un visor de galería y una solución completa de respaldo es crítica en este contexto. Google Photos proporcionaba durabilidad y redundancia fuera del sitio, mientras que una instancia de Immich autoalojada representa un único punto de fallo a menos que esté correctamente respaldada. La regla de respaldo "3-2-1"—mantener tres copias de los datos, en dos medios diferentes, con uno fuera del sitio—se aplica estrictamente aquí. Sin un respaldo fuera del sitio de la base de datos y la biblioteca, el servidor es meramente una segunda copia de los datos en hardware gestionado por el usuario, no una verdadera red de seguridad contra fallos de hardware o ransomware.
Por qué importa
Para líderes de TI y desarrolladores que gestionan infraestructuras a pequeña escala, comprender el verdadero costo de autoalojar aplicaciones complejas es vital. Immich demuestra que el software "gratuito" a menudo conlleva costos ocultos en términos de especificaciones de hardware y sobrecarga de mantenimiento. Un VPS estándar de 1 GB o una opción PaaS de nivel gratuito son insuficientes para esta carga de trabajo. Los equipos que consideran tales migraciones deben evaluar si su hardware existente, como una VM gratuita de Oracle con 12 GB de RAM, puede sostener la carga continua del procesamiento de ML en segundo plano y las operaciones de base de datos.
Además, la disciplina operativa requerida para Immich excede la de aplicaciones simples sin estado. La necesidad de gestionar esquemas de bases de datos, manejar cambios disruptivos en archivos de configuración y asegurar canales de acceso remoto añade carga administrativa. Para organizaciones o individuos con disponibilidad intermitente de laboratorios domésticos, aumenta el riesgo de fallos de sincronización de datos. Si el servidor está desconectado cuando los dispositivos móviles intentan sincronizarse, la utilidad de respaldo queda anulada. Esto hace que Immich sea adecuado solo para entornos siempre activos con conectividad eléctrica y de red robusta.
Qué puedes hacer
- Auditar recursos de hardware: Asegúrate de que tu servidor tenga al menos 4 GB de RAM libre y almacenamiento NVMe suficiente antes de comenzar el despliegue.
- Implementar respaldos estrictos: Configura scripts automatizados para realizar tanto operaciones
pg_dumpcomo respaldos a nivel de archivo de la carpeta de la biblioteca en una ubicación fuera del sitio. - Asegurar el acceso remoto: Usa un proxy inverso con certificados TLS válidos o una herramienta de red mesh como Tailscale para habilitar respaldos móviles sin exponer puertos a internet público.
- Seguir protocolos de actualización: Descarga siempre el último archivo oficial de Docker Compose desde la etiqueta de versión específica al actualizar, en lugar de depender de configuraciones en caché.
- Validar credenciales: Usa solo caracteres alfanuméricos para las contraseñas de base de datos para evitar errores de análisis de cadenas de conexión durante la configuración inicial.
- Considerar reducir la escala: Si se ejecuta en hardware limitado, desactiva el servicio de aprendizaje automático para reducir el uso de RAM, aceptando la pérdida de capacidades de búsqueda inteligente.



