手机照片越来越多以后，很多人会开始纠结同一个问题：继续买 iCloud、Google Photos、OneDrive 的空间，还是把照片放回自己的服务器？如果你已经有一台 VPS，Immich 是目前最接近“自建 Google Photos”的开源方案之一：手机自动备份、时间线浏览、人脸识别、相册分享、视频预览、Web 管理界面都比较完整。
但 Immich 不是一个“随便跑个容器就完事”的小工具。照片和视频会持续吃磁盘，数据库和上传目录都需要备份，机器学习组件会占用内存，升级也要比普通静态站点更谨慎。本文不只讲安装命令，也会把 VPS 上部署 Immich 最容易踩的坑讲清楚：存储放哪里、端口怎么暴露、手机怎么同步、备份该备份什么、什么时候不适合把 Immich 放在小 VPS 上。
先说结论：可以，但要看你的照片规模和预算。
适合 VPS 部署的情况：
- 你想给自己或家庭成员做一个私有照片备份入口。
- 照片规模在几十 GB 到几百 GB，能接受按需扩容磁盘。
- 你希望手机 App 自动上传，不想手动 rsync 或 SFTP。
- 你愿意定期做数据库和上传目录备份。
- 你有域名，可以用 HTTPS 访问。
不太适合的情况：
- 已经有几 TB 照片和视频，却只买了很小的 VPS 磁盘。
- 希望把它当唯一备份，没有第二份副本。
- 机器只有 512MB 内存，还想同时跑很多服务。
- 不想维护 Docker、PostgreSQL、反向代理和升级流程。
Immich 的体验很好，但照片备份属于长期数据业务。你真正要考虑的不是“今天能不能启动”，而是半年后磁盘满了、升级失败了、数据库坏了时能不能恢复。
如果只是个人测试：
| 用途 | 建议配置 |
|---|---|
| 体验和少量照片 | 2 vCPU / 2GB RAM / 40GB SSD |
| 个人长期使用 | 2-4 vCPU / 4GB RAM / 100GB+ SSD |
| 家庭多人使用 | 4 vCPU / 8GB RAM / 300GB+ SSD 或挂载额外存储 |
Immich 包含 server、machine learning、Redis/Valkey、PostgreSQL 等组件。内存太小也能勉强启动，但后台缩略图、视频转码、人脸识别和机器学习任务会让体验变差。
如果 VPS 磁盘不大，不建议一开始就把所有手机原图全部导入。可以先用一个测试相册跑通上传、浏览、备份和恢复流程，再决定是否迁移主照片库。
开始前建议准备：
- 一台 Ubuntu 22.04 / 24.04 或 Debian 12 VPS。
- 已安装 Docker Engine 和 Docker Compose 插件。
- 一个域名，例如
photos.example.com。 - 防火墙只开放必要端口。
- 足够大的磁盘目录，例如
/opt/immich/library。
确认 Docker 可用：
docker version
docker compose version
如果你用的是系统源里的旧 Docker，可能会遇到 Compose 语法不兼容。Immich 官方也提醒：正确命令是 docker compose，不是旧的 docker-compose。如果遇到奇怪的 Compose 报错，优先安装 Docker 官方仓库版本。
建议把 Immich 放在 /opt/immich：
sudo mkdir -p /opt/immich
sudo chown -R "$USER":"$USER" /opt/immich
cd /opt/immich
后面所有配置文件都放在这个目录，方便备份和迁移。
Immich 官方推荐使用 Docker Compose 部署，并要求使用当前 release 对应的 compose 文件。
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
下载后目录里应该有：
ls -la
至少看到：
docker-compose.yml
.env
不要直接复制 GitHub main 分支里的 compose 文件到生产环境，因为 main 分支可能和最新 release 不兼容。用 release 下载链接更稳。
打开 .env：
nano .env
重点改这几个变量：
UPLOAD_LOCATION=/opt/immich/library
DB_DATA_LOCATION=/opt/immich/postgres
TZ=Asia/Shanghai
IMMICH_VERSION=v2
DB_PASSWORD=换成一串随机密码
这些变量的含义：
UPLOAD_LOCATION：照片和视频上传目录，必须有足够空间。DB_DATA_LOCATION：PostgreSQL 数据目录。官方示例提醒，数据库目录不支持放在网络共享上。TZ：时区，国内用户通常用Asia/Shanghai。IMMICH_VERSION：使用的 Immich 版本。可以用v2，更谨慎的做法是固定到具体版本。DB_PASSWORD：PostgreSQL 密码。建议使用只包含字母数字的随机字符串，避免 Docker 解析特殊字符时出问题。
生成一个简单随机密码：
openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 24
创建存储目录：
mkdir -p /opt/immich/library /opt/immich/postgres
在 /opt/immich 目录执行：
docker compose up -d
查看容器状态：
docker compose ps
查看日志：
docker compose logs -f --tail=100
官方 compose 默认暴露 2283:2283，所以你可以先临时访问：
http://服务器IP:2283
如果页面能打开，说明服务已经起来。首次进入后创建管理员账号，再进入系统设置。
测试阶段直接访问 IP:2283 没问题，但长期使用不建议把 Immich 裸露在公网端口上。
更推荐：
公网用户 -> Caddy/Nginx :443 -> 127.0.0.1:2283 -> Immich
你可以把 compose 中的端口改成只监听本机：
ports:
- '127.0.0.1:2283:2283'
然后重启：
docker compose up -d
这样外部无法直接访问 IP:2283，只能通过反向代理域名访问。
假设域名是 photos.example.com，Caddyfile 可以这样写：
photos.example.com {
encode zstd gzip
reverse_proxy 127.0.0.1:2283
}
修改后验证并重载：
sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
然后访问：
https://photos.example.com
如果你用 Nginx，也可以反向代理到 127.0.0.1:2283。重点不是 Caddy 还是 Nginx，而是不要把管理入口和上传入口直接裸露在不受控端口上。
Immich 有 Android 和 iOS 客户端。大致流程是：
- 在手机安装 Immich App。
- Server URL 填写你的 HTTPS 地址，例如
https://photos.example.com。 - 用刚创建的账号登录。
- 选择要备份的相册。
- 开启后台备份和仅 Wi-Fi 备份等选项。
第一次备份可能会很慢，尤其是手机里已有大量照片和视频时。建议：
- 先只选择一个测试相册。
- 确认 Web 端能看到照片。
- 确认 VPS 磁盘增长符合预期。
- 再逐步开启全部相册备份。
不要一上来就把几万张照片全部推上去。第一次导入是最容易暴露磁盘、带宽、发热、后台权限问题的阶段。
Immich 的照片和视频会放在 UPLOAD_LOCATION 指定目录。规划容量时不要只看当前手机相册大小，还要考虑：
- 未来一年新增照片和视频。
- 视频文件通常比照片大得多。
- 缩略图、转码文件、机器学习缓存也会占空间。
- 备份归档也需要额外空间。
查看目录占用：
du -sh /opt/immich/library
查看磁盘：
df -h
如果你预计照片库会很快超过 VPS 系统盘，建议一开始就把 UPLOAD_LOCATION 放到单独挂载的数据盘，例如：
UPLOAD_LOCATION=/mnt/photos/immich-library
但数据库目录 DB_DATA_LOCATION 不建议放网络共享。数据库对延迟和一致性更敏感，应该放本机 SSD 或可靠块存储。
Immich 不是备份工具本身，它只是照片管理和同步服务。真正的备份至少要包括两部分：
- 上传目录：
UPLOAD_LOCATION - 数据库目录或 PostgreSQL 导出
如果只备份照片文件，不备份数据库，恢复后相册、用户、元数据、识别结果可能不完整。如果只备份数据库，不备份上传目录，也没有意义。
一个简单的归档思路：
mkdir -p /opt/backups/immich
tar czf /opt/backups/immich/immich-library-$(date +%F).tar.gz -C /opt/immich library
数据库更推荐使用 PostgreSQL 工具导出，而不是在运行中直接复制数据目录。你可以进入数据库容器执行：
docker compose exec database pg_dump -U postgres immich > /opt/backups/immich/immich-db-$(date +%F).sql
备份完成后，再用 rclone、对象存储或另一台服务器保存第二份副本。照片备份最怕“只有一份，还在同一台机器上”。
Immich 更新比较活跃，不建议无脑自动升级。升级前建议：
- 阅读 release notes。
- 备份
.env、docker-compose.yml。 - 备份数据库和上传目录。
- 拉取新 compose 或更新版本变量。
- 执行
docker compose pull。 - 再
docker compose up -d。
基本命令：
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
升级后看日志：
docker compose logs -f --tail=100
如果你用具体版本标签，升级节奏会更可控；如果直接跟随 v2 或 release，省事但变动更快。
检查容器：
docker compose ps
docker compose logs --tail=100 immich-server
检查端口：
ss -lntp | grep 2283
如果你把端口绑定到了 127.0.0.1，公网访问 IP:2283 本来就不会通，需要通过反向代理域名访问。
常见原因：
- VPS 带宽太小。
- 手机后台权限受限。
- 首次上传文件太多。
- VPS 磁盘 I/O 弱。
- 反向代理上传大小限制太小。
先用少量照片测试，再逐步放开。
检查目录：
du -h --max-depth=1 /opt/immich | sort -h
重点看 library、postgres、Docker overlay 和日志。不要随便删除 Immich 内部目录，先确认哪些是缓存、哪些是原始上传文件。
Immich 的 machine learning 组件用于搜索、人脸识别等功能。如果 VPS 配置很低，首次扫描会让 CPU 和内存占用升高。可以先让它在低峰期跑完，或者暂时减少导入量。
如果你的照片已经超过 1TB，而且每天还在增长，小 VPS 可能不是最合适的位置。你需要考虑：
- 块存储扩容成本。
- 出站流量成本。
- 备份到第二地点的成本。
- VPS 提供商对长期大流量的限制。
- 数据恢复时间。
这种情况下，家用 NAS、对象存储、专门的大盘服务器或混合方案可能更合适。Immich 可以部署在 VPS 上，但照片库这种数据长期增长的业务，最终瓶颈通常是存储和备份，而不是安装命令。
在 VPS 上部署 Immich 并不复杂：下载官方 docker-compose.yml 和 .env，设置上传目录、数据库目录、版本和密码，然后执行 docker compose up -d 就能跑起来。
真正要认真对待的是后半部分：不要裸露端口，使用 HTTPS 域名；不要把数据库放网络共享；不要只备份照片不备份数据库；不要无脑自动升级；不要在小磁盘 VPS 上一次性导入所有照片。
如果你只是想体验自托管照片备份，Immich 很适合从一台 2-4GB 内存 VPS 开始；如果你要把它变成长期家庭照片中心，就要把存储、备份、恢复演练和升级流程一起规划好。