Immich vs Nextcloud vs PhotoPrism vs Ente: comparativa 2026 para autoalojados

Google Photos pule mejor la experiencia, pero cuesta soberanía: tus archivos viven en servidores de otra empresa, escaneados para entrenar modelos, y un cambio unilateral en los términos puede dejarte sin acceso a años de recuerdos. Si quieres salir, la buena noticia es que en 2026 ya no es una decisión binaria entre Google y PhotoPrism. Cuatro proyectos open source bien mantenidos resuelven el mismo problema desde ángulos distintos: Immich replica la app de Google casi feature por feature, Nextcloud Photos agrega fotos a un ecosistema de archivos y calendarios, PhotoPrism es el archivador inteligente para bibliotecas que ya tienes en disco, y Ente te da cifrado extremo a extremo con apps móviles nativas. La decisión depende del tamaño de tu biblioteca, de si las fotos viven en tus teléfonos o en un NAS, y de cuánta RAM puedes darle al servidor.

Esta guía es un comparativa técnica honesta de los cuatro, basada en documentación oficial, releases de GitHub y reportes de uso reales en VPS modestos. Cubre requisitos de hardware, capacidades de IA, experiencia móvil, modelo de almacenamiento y cifrado, y termina con un árbol de decisión y un plan de endurecimiento común. Si buscas solo la receta de instalación de Immich, tenemos una guía dedicada de setup con Docker, reverse proxy y backup 3-2-1 que publicamos hace una semana.

---

Qué resuelve cada uno y por qué existen cuatro

El espacio de fotos self-hosted está polarizado entre dos filosofías que rara vez coinciden. La primera es gestión de ingestion: tomaste las fotos con el teléfono, quieres backup automático desde la app móvil, y necesitas timeline, mapa y búsqueda semántica. Aquí manda Immich porque controla el flujo: la app sube originales directo a su upload location, indexa con CLIP, y muestra recuerdos en el formato familiar. La segunda filosofía es gestión de archivo: las fotos ya viven en un disco con estructura propia, organizadas por año/mes/evento desde hace una década, y la app debe indexar lo que ya existe sin moverlo. Aquí Photoprism y Lychee reinan porque leen el árbol de carpetas sin adueñarse de él.

Nextcloud Photos entra por una puerta distinta: no es un servidor de fotos sino una nube privada completa a la que las fotos se agregan como una más de sus capacidades. La fuerza es que ya tienes calendario, contactos, oficina colaborativa y compartición de archivos, así que añadir fotos es razonable si montaste Nextcloud por otras razones. La debilidad es que las funciones fotográficas son apps comunitarias sobre la base: Memories para timeline y mapa, y Recognize para reconocimiento facial. El resultado es funcional, pero no compite con Immich en pulido de UI ni con PhotoPrism en IA de catálogo.

Ente llega desde un ángulo criptográfico. Su modelo es zero-knowledge: el servidor nunca ve las fotos en claro porque el cifrado ocurre en el cliente y la clave nunca sale del dispositivo. Es la única de las cuatro con esta garantía auditable (Cure53 publicó la revisión criptográfica en 2024), pero asume confianza en su app móvil cerrada para mantener ese invariante. Útil si la privacidad es más fuerte que la personalización: pagas en comodidad y opciones de configuración a cambio de un modelo de amenaza mucho más estricto.

Cuatro opciones en una mirada

Aspecto	Immich	PhotoPrism	Nextcloud Photos	Ente
GitHub stars (oct 2026)	~110k	~40k	~30k (ecosistema general)	~28k
Licencia	AGPL-3.0	AGPL-3.0 Community + Plus de pago	AGPL-3.0	AGPL-3.0
Apps móviles nativas	iOS + Android, backup automático	Solo PWA + WebDAV con cliente de terceros	iOS + Android con auto-upload	iOS + Android, backup automático
Búsqueda semántica (CLIP)	Sí, modelo cargado en el contenedor ML	Sí, TensorFlow más liviano	Limitada vía app Recognize	Sí, MobileCLIP on-device
Reconocimiento facial	Incluido, sin costo extra	Incluido en Community	Vía app Recognize (comunitaria)	Incluido, debe activarse manual
Cifrado de extremo a extremo	No (TLS en tránsito, cifrado en disco opcional)	No	No (E2EE disponible para otras funciones)	Sí, audited por Cure53
RAM mínima realista	6 GB recomendado, 8 GB cómodo	2-3 GB	4-6 GB para Nextcloud con apps de fotos	1 GB
Contenedores Docker	4 (server, ML, postgres:vectorchord, valkey)	2 (app + MariaDB)	4-6 (PHP-FPM, nginx, postgres, redis, opcional Collabora)	3 + backend S3-compatible
Versión estable	v3.3.3 (oct 14, 2026)	Builds con sello de fecha, sin semver	Nextcloud Hub 35 + Memories 10.1.0	v1.7.x (builds mensuales)
Patrocinio	FUTO (full-time devs)	Comunidad + Plus subscriptions	Nextcloud GmbH	Ente Holdings (comercial + open)

Cómo evaluamos los cuatro

El criterio que más impacto tiene en la decisión diaria es si tus fotos viven en los teléfonos o ya en disco. Si todo entra desde cámara de celular, Immich o Ente con app nativa es la única respuesta razonable: configurar WebDAV en PhotoPrism para que teléfonos Android suban por su cuenta requiere instalar PhotoSync (pago) y mantener el daemon activo, lo cual no es práctico si la familia entera va a usarlo. Si las fotos viven en un NAS o disco USB desde hace años, PhotoPrism las indexa sin tocarlas, y eso es exactamente lo que quieres.

El segundo criterio es la RAM disponible en el servidor. Immich carga los modelos CLIP en su contenedor ML, y esa carga se queda en memoria: entre 1.5 GB y 2.5 GB dependiendo del modelo activo. Una VPS de 4 GB funciona con la opción -no-ml desactivando búsqueda semántica, pero entonces estás usando Immich sin la mitad de su valor. PhotoPrism aguanta 3 GB con TensorFlow y baja a 1.5 GB si aceptas desactivar RAW. Ente corre en 1 GB porque la IA pesada se hace en el celular. Nextcloud depende de cuántas apps activas tengas, pero solo con Hub básico más Memories ya pide 4 GB.

El tercer criterio es el modelo de amenaza. Si te importa más que las fotos nunca salgan de tus manos aunque roben el servidor, Ente es el único que cumple la promesa criptográfica. Immich y PhotoPrism almacenan los originales en claro dentro del contenedor, así que un atacante con acceso al host ve los archivos (aunque estén cifrados en disco con LUKS). Nextcloud tiene E2EE opcional pero no es el default y hay que activarlo por biblioteca.

El cuarto criterio, a menudo subestimado, es el ritmo de releases. Immich publica cada dos semanas con changelog claro, Paragon migrations entre mayor y menor automáticas. PhotoPrism usa builds fechados con cadencia mensual y la migración es manual. Nextcloud tiene LTS cada 12 meses y apps comunitarias que rompen compatibildad. Ente empuja builds móviles con cambios de UI frecuentes y self-hosting estable.

Immich: el reemplazo más cercano a Google Photos

Immich está escrito en TypeScript para el backend y Flutter para la app móvil, mantenido por dos ingenieros a tiempo completo bajo el paraguas de FUTO, y a octubre de 2026 va por la versión v3.3.3 (publicada el 14 de octubre) con más de 110.000 estrellas en GitHub. El lanzamiento v3.0.0 del 1 de julio de 2026 trajo tres primicias: Workflows (automatizaciones disparadas por eventos en la biblioteca), transcodificación HLS en tiempo real para video, y paridad completa entre la edición móvil y la edición web.

El stack oficial son cuatro contenedores Docker: immich-server (UI + API + transcodificación de video), immich-machine-learning (CLIP + detección de rostros, expuesto solo internamente), postgres:14-vectorchord (metadatos + embeddings vectoriales), y valkey (cola de trabajos en Redis-compatible). El puerto de la UI es 2283, que por defecto NO debe exponerse a internet: Caddy, Traefik o Nginx Proxy Manager en frente.

# Levantar Immich con la versión fija (no uses la etiqueta flotante en producción)
cd ~/services/immich
sed -i 's|^IMMICH_VERSION=v3$|IMMICH_VERSION=v3.3.3|' .env
sed -i 's|^UPLOAD_LOCATION=./library|UPLOAD_LOCATION=/mnt/fotos/immich-library|' .env
sed -i 's|^DB_PASSWORD=postgres|DB_PASSWORD='"$(pwgen -s 32 1)"'|' .env
docker compose up -d
sleep 15
docker compose logs immich-server | tail -20  # Esperar a ver "Listening on 0.0.0.0:2283"

La fortaleza diferencial de Immich es la búsqueda en lenguaje natural. Escribes “fotos del cumpleaños de María en el patio” y la consulta se vectoriza con el mismo modelo CLIP que indexó las fotos. Funciona porque el modelo entiende semántica, no solo palabras clave, y devuelve los embeddings más cercanos en milisegundos gracias a pgvector en Postgres. La detección facial corre en el mismo contenedor y agrupa las caras por similitud hasta construir una biblioteca de personas asignable manualmente. Lo que Immich todavía NO hace y Google Photos sí: integración con eventos del calendario, búsqueda por eventos de Gmail, collage automática al final del día.

El requisito de RAM es el techo real de Immich. Cada biblioteca indexada pasa antes por un job nocturno, y si la RAM es insuficiente el job se atasca y los embeddings no se computan. La métrica que importa es docker stats immich-machine-learning: si RSS supera 4 GB constantemente y ves el contenedor reiniciarse con exit code 137 (SIGKILL del OOM killer), la VPS se queda corta. Los modelos CLIP cargados entre 1.5 GB y 2.5 GB, y dejar headroom para el upsert vectorial pide 6 GB mínimo.

PhotoPrism: el archivador inteligente para bibliotecas existentes

PhotoPrism lleva seis años en desarrollo y su propuesta filosófica es opuesta a Immich: en lugar de adueñarse de los archivos, los lee donde ya están. Montas una carpeta originals con tu estructura existente (por año, por evento, por como te organizases), y PhotoPrism construye un índice vectorial sobre ella con TensorFlow. Si mañana desinstalas PhotoPrism, tus fotos siguen en el mismo sitio con los mismos nombres, y los sidecar YAML que escribió con lo aprendido viven aparte. Esa promesa de "no soy dueño de tus datos" es lo que hace a Photoprism la elección obvia para bibliotecas heredadas.

El stack de contenedores es el más liviano: dos imágenes (photoprism/photoprism:latest + MariaDB) y la huella en RAM documentada es de 2-3 GB. PhotoPrism recomienda swap adicional en servidores pequeños, idealmente 4 GB configurados antes del primer indexado. La indexación inicial es la operación más cara: para 200 GB de fotos, planeá varias horas con el servicio corriendo en background.

# PhotoPrism con la imagen community (gratis, AGPL-3.0 CE)
mkdir -p ~/services/photoprism/{originals,storage,import}
cd ~/services/photoprism
cat > docker-compose.yml <<'EOF'
services:
  photoprism:
    image: photoprism/photoprism:latest
    restart: unless-stopped
    environment:
      PHOTOPRISM_ADMIN_PASSWORD: "$(openssl rand -hex 16)"
      PHOTOPRISM_SITE_URL: "http://localhost:2342"
      PHOTOPRISM_DATABASE_DRIVER: "sqlite"
      PHOTOPRISM_STORAGE_PATH: "/photoprism/storage"
    ports:
      - "2342:2342"
    volumes:
      - ./originals:/photoprism/originals
      - ./storage:/photoprism/storage
EOF
docker compose up -d
docker compose logs photoprism | grep -E "ready|listening"  # "http://0.0.0.0:2342"

La edición Community es AGPL-3.0 y trae reconocimiento facial, búsqueda por TensorFlow, mapa por geolocalización y soporte RAW completo sin pagar un céntimo. Las funciones de pago de PhotoPrism incluyen un tier Essentials (~2 EUR/mes anuales, pensado para entusiastas que quieren extras personales) y un tier Plus (desde ~6 EUR/mes anuales, orientado a pequeños estudios fotográficos): geocodificación mejorada, vector graphics, soporte ampliado de video y gestión multi-usuario. El reconocimiento facial y todo el indexado por IA siguen siendo gratis en Community.

La pieza que PhotoPrism no resuelve es backup automático desde el celular. La app web progresiva funciona para visualizar, pero para subir automáticamente desde iOS o Android hay que instalar un cliente WebDAV de terceros (PhotoSync es el más pulido, de pago único). Eso es fricción seria para familias no técnicas y la razón principal por la que mucha gente termina instalando Immich después de probar PhotoPrism.

Nextcloud Photos: el todo-en-uno si ya tienes Nextcloud

Nextcloud no es un servidor de fotos sino una nube privada: archivos, calendario, contactos, oficina colaborativa, notas, bookmarks, y desde hace años, fotos. Si ya tienes Nextcloud montado por cualquier otra razón, agregar fotos es razonable porque reutiliza la infraestructura existente (PHP-FPM, Postgres, Redis) y los clientes móviles que ya sincronizan archivos pueden extender el auto-upload a Camera Roll.

Las dos apps que importan para fotos son Memories (escrita por pulsejet, ahora parte del repositorio oficial de Nextcloud) y Recognize (transferida al repositorio nextcloud-org en 2026, mantenida como app oficial) para reconocimiento facial. Memories trae timeline por fecha, mapa por geolocalización, álbumes compartidos y slideshow. Para Nextcloud 35 (Hub actual), Memories va por la versión 10.1.0, alineada con el ciclo de releases del servidor. Aunque ahora vive en el repositorio oficial de Nextcloud, Memories todavía conserva releases independientes y conviene revisar las release notes antes de cada upgrade mayor de Nextcloud.

# Instalar Memories en Nextcloud (asume que occ ya está en PATH del usuario www-data)
sudo -u www-data php /var/www/nextcloud/occ app:install memories
sudo -u www-data php /var/www/nextcloud/occ app:enable memories
# Reconocimiento facial vía Recognize
sudo -u www-data php /var/www/nextcloud/occ app:install recognize
sudo -u www-data php /var/www/nextcloud/occ app:enable recognize
# Re-indexar las fotos después de habilitar Memories
sudo -u www-data php /var/www/nextcloud/occ memories:index

La debilidad clásica de Nextcloud Photos es el rendimiento. La combinación PHP + Postgres + múltiples apps comunitarias no escala bien a bibliotecas grandes, y los reportes de "Nextcloud está lento" dominan los foros para instalaciones con más de 50 GB de fotos. La búsqueda y el slideshow se sienten menos pulidos que Immich o PhotoPrism. Si tu uso primario es fotos, Nextcloud es overkill. Si ya tienes Nextcloud y solo quieres subir las fotos familiares al mismo servidor, Memories es suficiente.

La memoria RAM de Nextcloud con fotos activas es 4-6 GB solo para Hub básico. Con Collabora Online (oficina), Talk (videollamadas), y otras apps activas, sube a 8-12 GB. No es la elección correcta para una Raspberry Pi o un VPS barato si tu objetivo central son las fotos.

Ente: cuando el cifrado manda sobre todo

Ente es la única opción con cifrado verdadero de extremo a extremo, auditada por Cure53 en 2024. El servidor nunca ve las fotos en claro porque la clave criptográfica vive solo en los dispositivos del usuario. La promesa es fuerte: si el operador del servidor es comprometido (ataque, brecha, citación judicial con orden sobre los metadatos), Ente solo puede entregar blobs cifrados que no puede abrir. La contraparte es que las funciones que requieren ver la imagen en el servidor (miniaturas generadas server-side, búsqueda semántica con embeddings server-side) son imposibles bajo este modelo. Ente lo resuelve haciendo la indexación y las miniaturas en el dispositivo móvil.

El stack de self-hosting requiere un backend S3-compatible (MinIO, Garage, SeaweedFS o pgsty/silo) más el binario único museum de Ente, que combina API, workers y proxy en un solo proceso. La imagen oficial pesa poco y la RAM documentada es de 1 GB mínimo, pero la realidad es que museum + MinIO suman entre 2 GB y 3 GB en uso normal. La instalación oficial usa el quickstart de Ente y se documenta en ente.com/help/self-hosting.

# Descargar y ejecutar el quickstart oficial (crea museum.yaml + docker-compose)
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ente/ente/main/server/quickstart.sh)"
# Editar las claves secretas (en el museum.yaml generado, no antes)
sed -i "s|jwt-secret: ".*"|jwt-secret: "$(openssl rand -hex 32)"|" museum.yaml
sed -i "s|encryption-secret: ".*"|encryption-secret: "$(openssl rand -hex 32)"|" museum.yaml
sed -i "s|hash-secret: ".*"|hash-secret: "$(openssl rand -hex 16)"|" museum.yaml
# Apuntar al bucket S3 (MinIO local o cualquier backend compatible)
sed -i 's|^    bucket: ".*"|    bucket: "ente-photos"|' museum.yaml
# Levantar el stack
docker compose up -d
# Verificar que el endpoint responde
curl -fsS http://localhost:8080/ping

La app móvil de Ente maneja el backup automático desde iOS y Android, idéntico a Immich. La búsqueda semántica usa MobileCLIP corriendo on-device, así que la consulta "playa al atardecer" se vectoriza en tu celular antes de enviarse. La consecuencia es batería: indexar 50 GB de fotos localmente en el celular drena varios puntos porcentuales por hora. La cara del modelo de amenaza criptográfica es también su costo.

La elección de Ente se justifica si el contenido de tus fotos es sensible (documentos de salud, fotos de menores, investigación periodística) y el riesgo de subpoena o brecha supera el costo de la batería. Para el 95% de los casos de uso familiar, Immich entrega privacidad suficiente cifrando el disco en reposo con LUKS o ZFS native encryption.

Árbol de decisión rápida

La decisión se reduce a cuatro preguntas, en orden. ¿Tus fotos viven principalmente en los teléfonos o en un disco del servidor? ¿Cuánta RAM puedes darle al VPS? ¿Necesitas además archivos, calendario y oficina? ¿El cifrado de extremo a extremo es requisito fuerte?

• Solo reemplazar Google Photos, 6 GB+ RAM disponibles: Immich. La migración desde Google Takeout funciona limpia y la app móvil configura sin intervención.
• Tengo 500 GB de fotos organizadas en carpetas, 3-4 GB RAM: PhotoPrism. Indexa sin tocar tu estructura y corre cómodo en hardware modesto.
• Ya tengo Nextcloud por archivos/calendario, 8 GB+ RAM: Nextcloud Photos con Memories. Evita montar otro servidor en casa.
• El cifrado de extremo a extremo es requisito legal o personal: Ente. acepta la fricción de las funciones server-side limitadas a cambio del modelo criptográfico.
• Quiero reconocimiento facial + búsqueda semántica gratis, sin RAM para Immich: corre PhotoPrism con TensorFlow y desactiva RAW si hace falta; el reconocimiento facial sigue funcionando en 2 GB de RAM.
• Familia entera con celulares, quieres algo fácil para todos: Immich. Ningún competidor iguala la app móvil.

Endurecimiento común: los 4 lo necesitan

Sean cual sea el elegido, hay cuatro tareas de endurecimiento que aplican a los cuatro y que tu yo futuro te va a agradecer. Saltar cualquiera deja la instalación vulnerable a las tres amenazas más comunes: datos en tránsito a internet público, credenciales filtradas al log de Docker, y backups ausentes en el momento del fallo.

# 1. Reverse proxy con TLS automático (Caddy como ejemplo)
# /etc/caddy/Caddyfile
foto.ejemplo.com {
  reverse_proxy localhost:2283  # Immich, ajustar puerto
  encode gzip
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "SAMEORIGIN"
    Referrer-Policy "strict-origin-when-cross-origin"
  }
}
sudo systemctl reload caddy
# 2. Fail2ban para el login web
sudo apt install fail2ban
sudo tee /etc/fail2ban/filter.d/immich.conf <<'EOF'
[Definition]
failregex = ^.*Failed login attempt.*ip=<HOST>.*$
ignoreregex =
EOF
sudo tee /etc/fail2ban/jail.d/immich.local <<'EOF'
[immich]
enabled  = true
filter   = immich
port     = http,https
logpath  = /var/log/caddy/access.log
maxretry = 5
bantime  = 3600
EOF
sudo systemctl restart fail2ban

Para backups aplica la regla 3-2-1 estricta: tres copias, dos medios, una offsite. La base de datos (Postgres en Immich/Nextcloud, MariaDB en PhotoPrism, Postgres en Ente) debe respaldarse al menos diaria, y los originales deben espejarse a un proveedor de storage frío como Backblaze B2 a USD 6/TB-mes. Sin la base de datos, las fotos viven sin reconocimiento facial, sin metadatos y sin mapa. Sin los archivos, los metadatos apuntan a la nada. Ambos, siempre juntos, encriptados en reposo en el destino.

# Backup diario de la base de datos Immich (cron a las 2 AM)
DB_PASSWORD=$(grep '^DB_PASSWORD=' ~/services/immich/.env | cut -d= -f2-)
docker exec -e PGPASSWORD="$DB_PASSWORD" -t immich_postgres pg_dump 
  --clean --if-exists 
  --dbname=immich 
  --username=postgres | gzip > /mnt/backups/immich_db_$(date +%Y%m%d).sql.gz
# Mirror de la biblioteca a almacenamiento frío con rclone
rclone sync /mnt/fotos/immich-library/ 
  b2:mi-cuenta/immich-library/ 
  --transfers 4 --checkers 8 
  --log-file=/var/log/rclone-immich.log
# Conservar los últimos 30 dumps locales antes de purgar
find /mnt/backups -name "immich_db_*.sql.gz" -mtime +30 -delete

Una decisión que define el modelo de amenaza físico: ¿el servidor donde corre Immich/PhotoPrism está cifrado en reposo? Si el servidor es un VPS en datacenter, la respuesta depende del proveedor (Hetzner cifra discos en reposo por default; OVH y Contabo ofrecen opcional con cargo adicional). Si es un homelab con disco físico accesible, LUKS en Linux o ZFS native encryption asegura que un disco robado no filtra las fotos. La verificación es trivial: lsblk -o NAME,TYPE,FSTYPE debe mostrar crypto_LUKS como tipo de filesystem, no ext4 directamente sobre el disco crudo.

Preguntas frecuentes

Lee también

• Montaje de Immich como Alternativa a Google Photos: Guía Definitiva para Sysadmins — receta paso a paso para instalar Immich con Docker, configurar el reverse proxy con Caddy o Traefik, y armar el backup 3-2-1 fuera del servidor.
• Nextcloud 35 en Linux: guía completa 2026 para sysadmins — instalación del Hub completo con Memories y Recognize, integración con clientes de escritorio y consideraciones de rendimiento.
• Cómo configurar Caddy como reverse proxy en Linux 2026: auto-HTTPS incluido — el reverse proxy recomendado para los cuatro, con TLS automático vía Let's Encrypt y soporte de HTTP/3.
• Cómo armar un homelab en 2026: presupuesto real + roadmap 12 meses — el servidor de fotos rara vez vive solo; esta guía cubre el stack completo (DNS, proxy, monitoring, backups) que necesitas.