La conclusión, primero: sí, pero depende del tamaño de tu fototeca y de tu presupuesto.

Casos en los que encaja el despliegue en VPS:

• Quieres un punto de entrada privado de copia de seguridad de fotos para ti o para los miembros de tu familia.
• Tus fotos ocupan entre decenas de GB y unos cientos de GB y puedes aceptar ampliar el disco según necesidad.
• Quieres que la app móvil suba automáticamente, sin rsync ni SFTP manuales.
• Estás dispuesto a hacer copias de seguridad periódicas de la base de datos y del directorio de subidas.
• Tienes un dominio y puedes acceder por HTTPS.

Casos en los que no encaja tan bien:

• Ya tienes varios TB de fotos y vídeos, pero solo compraste un disco de VPS pequeño.
• Quieres que sea tu única copia de seguridad, sin una segunda copia.
• La máquina solo tiene 512 MB de memoria y aun así quieres ejecutar muchos servicios en ella.
• No quieres mantener Docker, PostgreSQL, un proxy inverso y un proceso de actualización.

La experiencia de Immich es buena, pero la copia de seguridad de fotos es un negocio de datos a largo plazo. Lo que de verdad tienes que plantearte no es «si puede arrancar hoy», sino si podrás recuperarlo dentro de medio año cuando el disco se llene, falle una actualización o se rompa la base de datos.

Si es solo una prueba personal:

Immich incluye componentes como server, machine learning, Redis/Valkey y PostgreSQL. Con poca memoria también puede arrancar a duras penas, pero las tareas en segundo plano de miniaturas, transcodificación de vídeo, reconocimiento facial y machine learning empeorarán la experiencia.

Si el disco del VPS no es grande, no conviene importar todas las fotos originales del móvil desde el principio. Primero conviene probar con un álbum de prueba el flujo de subida, navegación, copia de seguridad y restauración, y después decidir si migras la fototeca principal.

Antes de empezar, prepara:

1. Un VPS con Ubuntu 22.04 / 24.04 o Debian 12.
2. Docker Engine y el plugin de Docker Compose instalados.
3. Un dominio, por ejemplo photos.example.com.
4. Un cortafuegos que solo abra los puertos necesarios.
5. Un directorio de disco suficientemente grande, por ejemplo /opt/immich/library.

Confirma que Docker está disponible:

docker version
docker compose version

Si usas el Docker antiguo de los repositorios del sistema, puedes encontrarte con incompatibilidades de sintaxis de Compose. La documentación oficial de Immich también recuerda: el comando correcto es docker compose, no el antiguo docker-compose. Si te aparece un error extraño de Compose, instala primero la versión del repositorio oficial de Docker.

Se recomienda poner Immich en /opt/immich:

sudo mkdir -p /opt/immich
sudo chown -R "$USER":"$USER" /opt/immich
cd /opt/immich

Todos los archivos de configuración se guardarán después en este directorio, lo que facilita las copias de seguridad y la migración.

Immich recomienda oficialmente el despliegue con Docker Compose y exige usar el archivo compose correspondiente a la release actual.

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

Tras la descarga, el directorio debería contener:

ls -la

Como mínimo deberías ver:

docker-compose.yml
.env

No copies directamente a producción el archivo compose de la rama main de GitHub, porque la rama main puede ser incompatible con la última release. Usar el enlace de descarga de la release es más estable.

Abre .env:

nano .env

Céntrate en estas variables:

UPLOAD_LOCATION=/opt/immich/library
DB_DATA_LOCATION=/opt/immich/postgres
TZ=Asia/Shanghai
IMMICH_VERSION=v2
DB_PASSWORD=换成一串随机密码

Qué significan estas variables:

• UPLOAD_LOCATION: directorio de subida de fotos y vídeos, debe tener espacio suficiente.
• DB_DATA_LOCATION: directorio de datos de PostgreSQL. El ejemplo oficial advierte que el directorio de la base de datos no es compatible con recursos compartidos de red.
• TZ: zona horaria; los usuarios de China continental suelen usar Asia/Shanghai.
• IMMICH_VERSION: versión de Immich que se usa. Puedes usar v2; lo más prudente es fijar una versión concreta.
• DB_PASSWORD: contraseña de PostgreSQL. Se recomienda una cadena aleatoria que solo contenga letras y números, para evitar problemas cuando Docker interpreta caracteres especiales.

Genera una contraseña aleatoria sencilla:

openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 24

Crea los directorios de almacenamiento:

mkdir -p /opt/immich/library /opt/immich/postgres

En el directorio /opt/immich, ejecuta:

docker compose up -d

Comprueba el estado de los contenedores:

docker compose ps

Consulta los registros:

docker compose logs -f --tail=100

El compose oficial expone 2283:2283 por defecto, así que puedes acceder temporalmente a:

http://服务器IP:2283

Si la página se abre, el servicio está en marcha. En la primera entrada, crea la cuenta de administrador y luego ve a los ajustes del sistema.

Acceder directamente a IP:2283 durante las pruebas no supone problema, pero para uso a largo plazo no se recomienda exponer Immich en un puerto público.

Más recomendable:

公网用户 -> Caddy/Nginx :443 -> 127.0.0.1:2283 -> Immich

Puedes cambiar el puerto en el compose para que escuche solo en localhost:

ports:
  - '127.0.0.1:2283:2283'

Y luego reiniciar:

docker compose up -d

Así el exterior no puede acceder directamente a IP:2283; solo se llega a través del dominio del proxy inverso.

Suponiendo que el dominio es photos.example.com, el Caddyfile puede escribirse así:

photos.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:2283
}

Tras modificarlo, valida y recarga:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Luego accede a:

https://photos.example.com

Si usas Nginx, también puedes hacer proxy inverso a 127.0.0.1:2283. Lo importante no es Caddy frente a Nginx, sino no exponer la entrada de administración y la de subida directamente en puertos sin control.

Immich tiene clientes para Android e iOS. El flujo general es:

1. Instala la app de Immich en el móvil.
2. En Server URL, introduce tu dirección HTTPS, por ejemplo https://photos.example.com.
3. Inicia sesión con la cuenta que acabas de crear.
4. Selecciona los álbumes que quieres respaldar.
5. Activa opciones como la copia en segundo plano y la copia solo por Wi-Fi.

La primera copia de seguridad puede ser muy lenta, sobre todo si el móvil ya tiene muchas fotos y vídeos. Sugerencias:

• Empieza con un solo álbum de prueba.
• Confirma que las fotos se ven en la web.
• Confirma que el crecimiento del disco del VPS coincide con lo esperado.
• Después activa poco a poco la copia de todos los álbumes.

No subas de golpe decenas de miles de fotos. La primera importación es la fase en la que más fácilmente se manifiestan problemas de disco, ancho de banda, calentamiento y permisos en segundo plano.

Immich guarda las fotos y los vídeos en el directorio indicado por UPLOAD_LOCATION. Al planificar la capacidad, no mires solo el tamaño actual del álbum del móvil; considera también:

• Las fotos y vídeos nuevos del próximo año.
• Los archivos de vídeo suelen ser mucho más grandes que las fotos.
• Las miniaturas, los archivos transcodificados y las cachés de machine learning también ocupan espacio.
• Los archivos de copia de seguridad también necesitan espacio adicional.

Consulta el uso del directorio:

du -sh /opt/immich/library

Consulta el disco:

df -h

Si prevés que la fototeca superará pronto el disco del sistema del VPS, conviene poner UPLOAD_LOCATION desde el principio en un disco de datos montado aparte, por ejemplo:

UPLOAD_LOCATION=/mnt/photos/immich-library

Pero el directorio de la base de datos DB_DATA_LOCATION no se recomienda en un recurso compartido de red. Las bases de datos son más sensibles a la latencia y la consistencia y deben estar en un SSD local o en almacenamiento en bloque fiable.

Immich no es en sí una herramienta de copia de seguridad; es un servicio de gestión y sincronización de fotos. Una copia de seguridad real debe incluir al menos dos partes:

1. El directorio de subidas: UPLOAD_LOCATION
2. El directorio de la base de datos o una exportación de PostgreSQL

Si solo respaldas los archivos de fotos y no la base de datos, tras la restauración los álbumes, usuarios, metadatos y resultados de reconocimiento pueden quedar incompletos. Si solo respaldas la base de datos y no el directorio de subidas, tampoco tiene sentido.

Una idea sencilla de archivado:

mkdir -p /opt/backups/immich

tar czf /opt/backups/immich/immich-library-$(date +%F).tar.gz -C /opt/immich library

Para la base de datos es mejor exportar con las herramientas de PostgreSQL que copiar el directorio de datos en caliente. Puedes entrar en el contenedor de la base de datos y ejecutar:

docker compose exec database pg_dump -U postgres immich > /opt/backups/immich/immich-db-$(date +%F).sql

Cuando termine la copia de seguridad, usa rclone, almacenamiento de objetos u otro servidor para guardar una segunda copia. Lo que más teme una copia de seguridad de fotos es «tener solo una copia, y además en la misma máquina».

Immich se actualiza con bastante frecuencia, así que no se recomiendan las actualizaciones automáticas sin criterio. Antes de actualizar:

1. Lee las notas de la release.
2. Haz copia de seguridad de .env y docker-compose.yml.
3. Haz copia de seguridad de la base de datos y del directorio de subidas.
4. Descarga el nuevo compose o actualiza la variable de versión.
5. Ejecuta docker compose pull.
6. Luego docker compose up -d.

Comandos básicos:

cd /opt/immich
cp .env .env.bak.$(date +%F)
cp docker-compose.yml docker-compose.yml.bak.$(date +%F)
docker compose pull
docker compose up -d

Consulta los registros tras la actualización:

docker compose logs -f --tail=100

Si usas una etiqueta de versión concreta, el ritmo de actualización es más controlable; si sigues directamente v2 o release, te ahorras trabajo pero los cambios llegan más rápido.

Si tus fotos ya superan 1 TB y siguen creciendo cada día, un VPS pequeño puede no ser el lugar más adecuado. Tienes que considerar:

• El coste de ampliar el almacenamiento en bloque.
• El coste del tráfico de salida.
• El coste de respaldar en una segunda ubicación.
• Las limitaciones del proveedor de VPS para tráfico intenso a largo plazo.
• El tiempo de recuperación de datos.

En estos casos, un NAS doméstico, el almacenamiento de objetos, un servidor dedicado de gran disco o una solución híbrida pueden ser más adecuados. Immich se puede desplegar en un VPS, pero en un negocio como una fototeca que crece a largo plazo, el cuello de botella final suele ser el almacenamiento y la copia de seguridad, no los comandos de instalación.

Desplegar Immich en un VPS no es complicado: descarga el docker-compose.yml y el .env oficiales, configura el directorio de subidas, el directorio de la base de datos, la versión y la contraseña, y ejecuta docker compose up -d para que funcione.

Lo que de verdad hay que tomarse en serio es la segunda parte: no expongas puertos, usa un dominio HTTPS; no pongas la base de datos en un recurso compartido de red; no respaldes solo las fotos sin la base de datos; no actualices automáticamente sin criterio; no importes todas las fotos de golpe en un VPS con poco disco.

Si solo quieres probar la copia de seguridad de fotos autoalojada, Immich es muy adecuado para empezar con un VPS de 2-4 GB de memoria; si quieres convertirlo en un centro familiar de fotos a largo plazo, planifica juntos el almacenamiento, las copias de seguridad, los simulacros de restauración y el proceso de actualización.