Immich es la respuesta autoalojada a Google Photos: tu servidor, tus discos, una aplicación móvil que respalda tu carrete. La instalación se lee como si llevara cinco minutos, y mecánicamente así es. Las decisiones que determinarán si dentro de tres años sigues teniendo tus fotos se toman todas en el archivo que editas antes de lanzarla.
Qué es realmente la instalación oficial
Dos descargas y un comando. La documentación los da tal cual:
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env
Fíjate en la asimetría de esa segunda línea: el archivo se publica con el nombre example.env y tú lo guardas como .env. Después, una vez rellenadas las variables, toda la instalación se reduce a docker compose up -d.
Si ese último comando falla, la documentación nombra la causa habitual antes de que tengas que buscarla. Advierte de que si obtienes un error del tipo unknown shorthand flag: 'd' in -d, probablemente no tienes la versión correcta de Docker, y de que la forma correcta es docker compose con un espacio en lugar del antiguo binario docker-compose. Señala aparte una segunda trampa de versión: un error que indica can't set healthcheck.start_interval as feature require Docker Engine v25 or later, que sugiere sortear comentando esa línea.
Son dos desajustes de versión, no errores en tu archivo. Ninguno de los dos merece que le dediques la tarde.
Las dos ubicaciones que deciden tu capacidad de recuperar
El archivo compose es corto, pero dos de sus variables no son ajustes intercambiables. Son las respuestas a « qué debo respaldar » y « qué se va a corromper solo ».
UPLOAD_LOCATION se describe en la documentación como la ubicación donde se almacenan tus archivos subidos, con la indicación de poner ahí la ubicación que prefieras para conservar esos datos. Es el directorio que contendrá cada foto que subas. Elegirlo a la ligera es la forma más común de acabar con una fototeca instalada fuera de todas las copias de seguridad que ya tienes en marcha.
DB_DATA_LOCATION es la base de datos, y la documentación le asocia una restricción firme: los recursos compartidos de red no están soportados para la base de datos. No es una recomendación de rendimiento. Los motores de base se apoyan en garantías de bloqueo y de orden de escritura que los sistemas de archivos en red ofrecen de forma desigual, y el modo de fallo suele ser una corrupción silenciosa descubierta semanas después, no una negativa a arrancar.
En la práctica: tu fototeca puede vivir en almacenamiento de red si aceptas que sea más lenta. El directorio de la base se queda en un disco local. Y elijas lo que elijas para el primero, anótalo, porque es la ruta que tus copias tienen que incluir.
La advertencia que el proyecto muestra en su propia portada
La mayoría de las guías de autoalojamiento la pasan por alto, así que conviene citar al proyecto en lugar de parafrasearlo. El repositorio de Immich lleva, arriba del todo, esta línea: « Always follow 3-2-1 backup plan for your precious photos and videos! »
Esa advertencia hace algo concreto. No dice que el software sea poco fiable. Dice que alojar tu propio servidor de fotos no es en sí una copia de seguridad, y quienes la escribieron saben que los autoalojadores creen habitualmente lo contrario. Una instancia única en una máquina única posee exactamente una copia de tu fototeca. Un disco que se estropea, una actualización chapucera, un borrado accidental o una ruta mal escrita la hace desaparecer, y no hay ningún proveedor a quien pedírsela.
El proyecto tiene licencia AGPL-3.0, lo que explica en parte que puedas auditarlo y ejecutarlo. Eso no cambia la aritmética de tener una sola copia.
Qué desplaza el autoalojamiento, y qué no
Se presenta a menudo el autoalojamiento como la opción privada, sin más. Es más exacto, y más útil, decir que desplaza la confianza en lugar de eliminarla.
Lo que cambia de verdad: ninguna empresa posee tu fototeca, ningún proveedor puede ser obligado legalmente a entregarla, ninguna condición de uso cambia a tus espaldas y no hay ninguna cuenta que perder. Para mucha gente ese es todo el sentido, y la ganancia es real.
Lo que no cambia por sí solo: el cifrado en reposo en tus propios discos, la seguridad física de la máquina, mantenerla actualizada y tener más de una copia. Todo eso pasa a ser tu trabajo en el momento en que se lo quitas a un proveedor. Ese es el trato, y es razonable aceptarlo a sabiendas. Lo es mucho menos aceptarlo por descuido, por haber supuesto que autoalojado significaba protegido.
¿Quieres la fototeca privada sin administrar el servidor? pCloud de por vida + Crypto
Jurisdicción suiza · Zero-knowledge con el complemento Crypto · Pago único, sin actualizaciones que seguir ni base de datos que respaldar
Elegir honestamente entre las dos
Autoaloja Immich si quieres tus fotos en hardware que controlas, aceptas asumir las copias de seguridad y las actualizaciones, y el mantenimiento te resulta interesante en lugar de algo que te pesará dentro de ocho meses.
Usa un servicio gestionado zero-knowledge si lo que realmente querías es que ninguna empresa pueda leer tus fotos, sin convertirte en la persona de guardia el día que falle el disco. Ese resultado se consigue sin servidor, y elegirlo no es una renuncia en materia de privacidad: es otro reparto del mismo trabajo.
La única respuesta que no sobrevive al contacto con la realidad es una instancia autoalojada única sin segunda copia. Es exactamente por eso que el proyecto lo dice él mismo antes de que instales nada.
Los comandos de instalación, la precisión de que el archivo de entorno se publica con el nombre example.env, las descripciones de UPLOAD_LOCATION y DB_DATA_LOCATION, el enunciado de que los recursos compartidos de red no están soportados para la base de datos, y los dos errores de versión de Docker proceden de la documentación oficial de instalación de Immich con Docker Compose. La línea de copias 3-2-1 y la licencia AGPL-3.0 proceden de la portada del repositorio del proyecto. Las citas se dejan en su idioma original. Ambas fuentes se consultaron en el momento de la redacción; verifica con la versión que estés instalando, ya que el archivo compose se entrega con cada release. Los enlaces comerciales llevan el atributo rel="sponsored nofollow"; puede aplicarse una comisión de afiliación, sin coste adicional para ti.
Guías relacionadas
- Mejor almacenamiento en la nube para fotos - la vertiente gestionada de la misma pregunta, con los servicios que cifran las fotos del lado del cliente.
- Almacenamiento en la nube autoalojado - el mismo dilema aplicado a los archivos en vez de a las fotos, con Nextcloud, Seafile y ownCloud.
Preguntas frecuentes
- ¿Qué hay que descargar realmente para instalar Immich?
- Dos archivos, publicados con cada versión. La documentación da los comandos tal cual: wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml y wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env. Fíjate en que el segundo se publica con el nombre example.env y tú lo guardas como .env. Una vez rellenadas las variables, toda la instalación cabe en un comando: docker compose up -d.
- ¿Por qué mi comando docker compose falla con un error de opción desconocida?
- Casi con seguridad estás usando el antiguo binario independiente en lugar del plugin. La documentación trata este caso de forma explícita: si obtienes un error del tipo unknown shorthand flag 'd' in -d, probablemente no tienes la versión correcta de Docker, y el comando correcto es docker compose, con un espacio, no docker-compose con guion. Menciona aparte una segunda trampa de versión: un error que indica que healthcheck.start_interval requiere Docker Engine v25 o posterior, que sugiere sortear comentando esa línea.
- ¿Dónde acaban realmente mis fotos en el disco?
- Donde apunte UPLOAD_LOCATION, que la documentación describe como la ubicación donde se almacenan tus archivos subidos, pidiéndote que indiques ahí la ubicación que prefieras para conservar esos datos. Es la línea de mayor consecuencia del archivo, porque decide qué directorio tendrás que respaldar. Configúrala deliberadamente hacia una ruta que ya protejas, en lugar de aceptar un valor por defecto y descubrir más tarde que tu fototeca vive en un sitio que tus copias de seguridad nunca miran.
- ¿Puedo poner la base de datos en mi NAS?
- La base de datos no. La documentación lo dice sin rodeos para DB_DATA_LOCATION: los recursos compartidos de red no están soportados para la base de datos. Las bases necesitan un bloqueo de archivos de bajo nivel que los sistemas de archivos en red no garantizan de forma fiable, e ignorarlo suele producir corrupción en lugar de un error limpio. Tu fototeca puede vivir en almacenamiento de red si aceptas el coste en rendimiento; el directorio de la base se queda en un disco local.
- ¿Basta con autoalojar Immich para tener las fotos a salvo?
- El propio proyecto dice que no, y lo dice en su propia portada: aplica siempre un plan de copias 3-2-1 para tus fotos y vídeos valiosos. Ejecutar tú el servidor cambia quién posee tu fototeca, no crea una segunda copia de ella. Una instancia autoalojada en una sola máquina está a un fallo de disco, una actualización fallida o un borrado accidental de la pérdida total, que es justamente lo que la regla 3-2-1 existe para evitar.
Probar pCloud
10 días de garantía
