跳至正文
生活笔记 理无专在 学无止境
资源文章 约 10 分钟阅读

把相册搬回自己硬盘:Immich

写在前面本文为备忘笔记,记录 Immich 这个项目是什么、能做什么、有哪些坑,便于日后查阅,避免从头重复调研。如果你也在考虑「把手机照片从云相册搬回自己家」,这篇应该能省你半天调研时间。一句话介绍Immich 是一个自托带的照片、视频备份与管理方案,可以理解为「自己在家搭一个谷歌相册」。高性能、开源、移动端体验...

写在前面

本文为备忘笔记,记录 Immich 这个项目是什么、能做什么、有哪些坑,便于日后查阅,避免从头重复调研。

如果你也在考虑「把手机照片从云相册搬回自己家」,这篇应该能省你半天调研时间。


一句话介绍

Immich 是一个自托带的照片、视频备份与管理方案,可以理解为「自己在家搭一个谷歌相册」。

高性能、开源、移动端体验对标商业 App,而所有数据——原片、缩略图、数据库——都存在你自己的机器上。

项目采用 AGPL-3.0 许可,客户端和服务端全部开源。这一点在今天的自托管圈子里其实不太常见:很多同类项目是「客户端开源、服务端闭源收费」,Immich 是连服务器代码都放在 GitHub 上的。


为什么值得关注

先说三个现实动机:

  1. 云相册不是保险箱。免费无限存储的时代早就结束了,现在各家都是限容量、限画质、或者直接转付费。
  2. 隐私是真问题。照片是最私人的数据,上传到第三方意味着你把它们交给别人的服务器、别人的审核策略、别人的经营状况。
  3. 自托管门槛已经很低了。早些年自建相册意味着折腾 FTP、写脚本、手动同步。现在一个 Docker Compose 文件,四个容器,十几分钟就跑起来。

Immich 解决的就是第三点——它把「自建相册」这件事的产品体验做到了接近商业 App 的水平。


核心功能

手机端备份(核心卖点)

  • 后台自动备份:手机连上 WiFi 就自动上传新照片视频,无需手动操作
  • 选择性备份:可以只备份指定相册,或只备份选中的照片
  • 相册同步:把手机上的相册结构镜像到服务器,同名相册自动合并
  • 没网时排队:离线状态下拍的照片先存队列,恢复网络后自动续传

浏览与管理

  • 网页端画廊、时间线滚动、多设备上传实时渲染
  • 相册管理、共享相册、公开分享链接(可设有效期、可禁下载)
  • EXIF 信息提取展示,支持 HEIC/HEIF 与 RAW 格式
  • 按标签、拍摄器材、拍摄地点、文件名搜索
  • 支持从本地通过 CLI 批量导入历史照片

多用户

完善的用户与权限体系,每个人独立空间,可以互相共享相册。家庭场景下这是刚需——爸妈、伴侣、孩子各一个账号,各自自动备份,再建一个家庭共享相册。

AI 能力(可选)

  • 人脸识别与人物聚合
  • CLIP 语义搜索(可以直接搜"红色连衣裙"这种自然语言)
  • OCR 文字提取
  • 近似重复照片检测
⚠️ 这一整块是可选的,可以整个关掉。后面会说为什么有时候必须关。

最值得关注的两点

一、离线能力

Immich 的手机 App 从 v1.51.0 开始支持离线模式。官方的说明是:

以前服务器宕机或手机没网时,点任何东西都会被弹回登录页。我们加了新功能,即使服务器宕机或没有网络连接,你仍能查看缓存或存储在设备上的照片和视频。而且查看设备上的照片视频时不再从服务器加载,而是直接从本机读取——这减少了移动数据消耗,也加快了滚动时间线时缩略图的加载速度。

翻译成实际体验:

场景能用吗
服务器宕机✅ 照样看手机本地照片
手机没网✅ 照样看
没网时拍照⏸️ 排队,联网后自动传
省流量✅ 本地照片直读,不走服务器

但有个大坑:Immich 有个「释放手机空间」(Free Up Space)功能,会把已经备份成功的照片从手机里删掉,回收手机存储。

如果你开了这个功能,离线时就看不到那些照片了——因为本地文件已经没了,必须联网从服务器拉。

想保留离线可看性,就得保留手机本地副本。这两个需求是互斥的,提前想清楚。

二、多用户免费,无席位限制

这点必须单独说。

调研一圈同类自托管方案会发现一个现象:不少项目是「客户端开源、服务端闭源 + 按席位收费」。比如某知名 Notion 替代品,自托管免费档只给 1 个用户席位,全家共用就得买 Team 授权($10/人/月)。

Immich 不存在这个问题——AGPL-3.0 全栈开源,多用户免费,没有席位限制。

全家五口人各一个账号,零授权费。


架构与部署

Immich 是个多容器栈,标准部署一共四个:

容器职责
immich-server主服务,Web / API / 同步
immich-machine-learningAI 能力(人脸、语义搜索等)
redis(valkey)缓存与队列
database(Postgres + vectorchord)数据库

默认端口 2283,部署完手机 App 填 http://服务器IP:2283 就能连。

存储上有一个重要原则:数据库必须放 SSD。

Postgres 放机械盘会明显卡顿。照片原片库反而是"写一次、mostly 读"的负载,放大容量机械盘完全没问题。所以比较舒服的分工是:

  • NVMe SSD → 系统 + 数据库 + 缩略图缓存
  • 大容量 HDD → 照片原片库

硬件要求

官方给的基准:

内存能否运行说明
4 GB⚠️ 可以,但必须关 ML保留上传 / 相册 / 时间线 / 手机备份;失去人脸分组、语义搜索、自动标签
6 GB✅ 官方最低上传大批量照片时偏紧
8 GB✅ 官方推荐舒适

CPU 官方建议 2 核最低、4 核推荐。

一个反直觉的实测数据:在 Intel N100 这种低功耗小主机上,导入 4 万多张照片——

  • 开 ML:约 300 张/小时(ML 任务和缩略图生成抢 CPU)
  • 关 ML:约 5000 张/小时

差了接近 15 倍。

所以如果要做大批量历史照片导入,正确做法是先关 ML 快速导完,再开 ML 让它在后台慢慢跑。这个小技巧能省好几天时间。


与同类方案对比

Immich谷歌相册PhotoPrismNextcloud Memories
数据在哪自己机器谷歌服务器自己机器自己机器
手机自动备份✅✅❌ 无官方客户端✅
人脸 / 语义搜索✅ 可选✅✅部分
多用户免费✅ 无限制受限✅✅
服务端开源✅ AGPL❌✅ AGPL✅ AGPL
维护成本中(4 容器)零中高(整套 PHP 栈)

PhotoPrism 更适合当"只读的相册索引"管理 NAS 上海量历史照片,但它没有好用的手机客户端,做不了日常备份主力。Nextcloud 功能全但太重了,为了一个相册背上整套 PHP + Apache 栈不划算。


适合谁 / 不适合谁

适合:

  • 想把照片从云相册迁出来、数据自主的人
  • 家庭多成员共用一个相册库
  • 有 NAS 或一台常开机小主机的
  • 对隐私敏感、不希望照片经 third party 手的

不适合:

  • 完全不想运维任何东西的(再简单也要维护服务器)
  • 手机存储紧张、又必须依赖「释放空间」功能的(会和离线能力冲突)
  • 需要 EB 级存储的(那是另一套架构的问题)

必须提醒的三件事

1. 备份!备份!备份!

自托管最大的风险不是被黑,是硬盘挂了。

Immich 服务器只是你照片的一份拷贝。合理的做法是 3-2-1 原则:

  • 一份在 Immich 服务器(日常用)
  • 一份在定期同步的移动硬盘(放别处)
  • 可选:一份加密后放云端

数据库(Postgres)也要定期 pg_dump 导出,配置文件同样备份。单盘等于单点故障,别赌。

2. 关掉 ML 之前想清楚

ML 关掉后人脸分组、语义搜索、自动标签全没了。如果你就靠"搜海边日落"找照片,那 8GB 内存是值得投资的,别省。

3. 内网隔离的话,路由器和防火墙都要配

参考《家庭自托管部署手册》中的内网隔离方案,把照片机单独放一台机器、只接内网不暴露公网,需要注意:

  • 路由器不要给它做端口映射
  • 防火墙只放行内网网段访问 2283
  • 磁盘加密(LUKS)加上,机器被偷数据不泄

这样公网根本摸不到这台机器,而你在家连 WiFi 照常自动备份。隐私效果和物理气隙差不多,但保留了便利性。


小结

Immich 是目前自托管相册里完成度最高的方案之一:

  • 手机端体验真正对标商业 App,不是"能用的开源替代品"
  • 离线模式解决了"没网就看不了照片"的尴尬
  • 多用户免费、AGPL 全栈开源,没有授权陷阱
  • 硬件要求友好,一台低功耗小主机就能扛

如果你手里有 NAS 或者一台常开机的旧电脑,花半小时部署一个试试——把陪伴自己这么多年的照片,搬回自己硬盘上,这件事本身就很值。


备忘:关键信息速查

项值
项目地址github.com/immich-app/immich
许可AGPL-3.0(服务端也开源)
默认端口2283
容器数4(server / machine-learning / redis / postgres)
内存要求6GB 最低 / 8GB 推荐;4GB 需关 ML
关 ML 的环境变量IMMICH_MACHINE_LEARNING_ENABLED=false
数据库位置必须在 SSD
离线模式起始版本v1.51.0
手机 AppiOS App Store / Google Play / GitHub APK / F-Droid

本文为个人备忘笔记,功能与版本信息记录于 2026-10-18,实际以官方文档与最新版本为准。