Immich se ganó el puesto de el Google Photos autoalojado: subida automática desde el móvil que funciona de verdad, una línea de tiempo rápida sobre decenas de miles de elementos, álbumes compartidos y búsqueda con machine learning — caras, objetos, consultas en lenguaje natural vía CLIP — corriendo por completo en tu hardware. Dimensionarlo no se parece a la mayoría de apps autoalojadas porque la restricción no es el stack web, es la aritmética de almacenamiento más el apetito del ML, y acertar esas dos cosas decide si la familia de verdad migra fuera de Google.
Lo que consume el stack en realidad
| Componente | CPU | RAM | Notas |
|---|---|---|---|
| Servidor + Postgres + Redis | ligero | ~1–1.5 GB | estado estable |
| Machine learning (caras, CLIP) | a ráfagas, ama los núcleos | 1.5–3 GB | lo más pesado en el escaneo inicial |
| Transcodificación de vídeo | pesada sin aceleración HW | moderada | QuickSync/VAAPI convierte horas en minutos |
Suelos prácticos: 4 GB de RAM en total sirven para una biblioteca pequeña si aceptas una indexación ML inicial lenta; 6–8 GB es la recomendación honesta para una instancia familiar. La CPU importa sobre todo dos veces — el primer escaneo completo (días con 2 núcleos débiles, horas con 6 de verdad) y las transcodificaciones. Si la máquina tiene iGPU (Intel QuickSync), habilitar la transcodificación por hardware es el mayor desbloqueo de rendimiento.
La matemática de almacenamiento que nadie hace a priori
Las fotos son un dataset creciente sin techo natural. Tasas de generación realistas que vemos:
- Un usuario intensivo de móvil: 50–150 GB/año (fotos + vídeo casual).
- Una pareja con hijos: 200–300 GB/año — dominan los vídeos de los niños.
- Hogares con vídeo 4K o fotógrafos aficionados (RAW): 0.5–1 TB/año.
Reglas derivadas: aprovisiona al menos 2× tu biblioteca actual desde el primer día; mantén la base de datos y las miniaturas en NVMe vivan donde vivan los originales (la latencia de miniaturas es lo que hace que la línea de tiempo se sienta instantánea); y planifica la ruta de crecimiento antes de necesitarla. La función de storage-template de Immich guarda los originales en una estructura de carpetas plana y portable — tu salida de emergencia sigue abierta.
Tres perfiles de alojamiento que funcionan
- Biblioteca bajo ~500 GB: un VPS con NVMe generoso o un dedicado pequeño. El nivel de $25–35 con disco de 1 TB de nuestro catálogo cubre años para la mayoría de familias.
- Biblioteca de 1–10 TB: territorio HDD con ruta caliente en SSD — un servidor de almacenamiento con 2×4 TB HDD (desde ~$47) más NVMe para BD/miniaturas.
- Archivos masivos (10 TB+): máquinas de almacenamiento dedicadas (hasta 6×14 TB SAS en stock) — a ese tamaño diriges un datacenter fotográfico privado y el precio por TB es todo el juego.
Nota de ancho de banda: las subidas iniciales del móvil son el único momento a ráfagas (un primer sync de 200 GB satura el uplink de casa, no el servidor); después el tráfico es trivial salvo atracones de álbumes compartidos.
¿Buscas un servidor que simplemente funcione?
Valebyte VPS — NVMe, soporte 24/7, despliegue en 60 segundos.
Immich no es un backup — dilo dos veces
Borrar una foto en la app la borra en el servidor; un disco muerto sin redundancia lo borra todo. La capa que la gente se salta: los espejos RAID protegen contra la muerte del disco, los snapshots restic/borg de originales + un dump de Postgres hacia una segunda máquina protegen contra todo lo demás (error de usuario, ransomware, bugs). Las fotos son el único dataset donde «ya configuraré los backups» se convierte fiablemente en tragedia familiar. Regla de dos ubicaciones, restauraciones probadas, trimestrales.
Conclusión
Presupuesta 6–8 GB de RAM, núcleos reales para el primer escaneo, NVMe para la ruta caliente y matemática honesta de crecimiento para los originales — y entonces Immich jubila de verdad a Google Photos, suscripción y dudas de privacidad incluidas. Hechos verificados el 8 de julio de 2026; Immich publica rápido, pero el perfil de recursos de arriba ha sido estable en toda la línea 1.x.
