我一次又一次从离开 Nextcloud 的人那里读到的，总是同一个故事。同步客户端显示“已完全同步”，文件却少了。一次升级撞上数据库问题。一次照片上传的表现和用户预期的不一样。
这三件事背后的抱怨是同一个：他们想从一个为覆盖众多工作流而生的套件里，拿到一条可靠的工作流。
我在法兰克福的一台 VPS 上有一个 Nextcloud 实例，两年前花一个周末搭起来，此后大概用过四次。安装是成功的，实例现在也还在跑。我只是不再打开它了，因为事实证明，Nextcloud 能做的十件事里有九件我从来不需要。
官方的 All-in-One 发行版在启用任意可选容器后就要求至少 2 GB 内存，其性能指南还建议在基础需求之上按每个活跃用户再加约 1 GB 内存。因此随着并发使用增长，团队部署需要更多余量。社区在 help.nextcloud.com 上也有一个尚未关闭的帖子，请求项目考虑推出更轻的版本。
下面是三条出路，各自对应一种工作流。凡有官方资源要求的地方，我就采用；没有的地方，我不给出硬性数字。迁移图会讲清楚你保留什么、失去什么，以及每次搬迁在哪里变得麻烦。
简短版本
- 如果你用 Nextcloud 只是为了在自己的几台设备之间同步文件，那么 Syncthing 是个不错的选择：点对点，不需要中心服务器，但在移动端有几点重要的保留意见。
- 如果你把 Nextcloud 当作多用户的团队文件共享来用，那么 Seafile CE 是个不错的选择。它记录在案的最低配置是 2 GB 内存和 2 个 CPU 核心，而更窄的定位让它在以文件共享为主时更容易估算规模。
- 如果你主要把 Nextcloud 当作网页端的文件浏览器，那么 Cloudreve 或 AList 能给你一套窄得多的架构，不必背上 Nextcloud 完整的协作套件。
- 任何一次搬迁的两个摩擦点，都是 CalDAV/CardDAV 的缺口（日历和联系人）以及 iOS 上的照片备份。两者在下面的迁移图里都有覆盖。
为什么 Nextcloud 显得笨重（以及为什么这不是缺陷）
在一套全新安装的 Nextcloud All-in-One 上， htop 会显示出一整套真正的多容器架构：AIO 主容器、Apache、Nextcloud 应用服务器、PostgreSQL、Redis 和 Notify Push。Office、Talk、Talk Recording、ClamAV、全文检索、Imaginary、Whiteboard 以及基于 Borg 的备份都是可选的。核心确实比单一用途的同步守护进程重，但那些可选服务只有在你启用时才会吃内存。
GitHub 上官方的 All-in-One 讨论把记录在案的最低值定在 2 GB 内存，但它涨得很快：一旦启用 ClamAV、Talk Recording 或全文检索就是 3 GB，全部打开是 5 GB，再加上基础之上每个活跃用户约 1 GB。
这些是估算规模的建议，而不是实测的稳态内存占用：AIO 会随着可选服务的启用而需要更多内存，并建议为每个活跃用户留出额外余量。这就是把三十多项功能捆进一个自托管套件的架构代价。来源： github.com/nextcloud/all-in-one/discussions/1335.
Nextcloud 社区自己也注意到了。help.nextcloud.com 上一个名为“Nextcloud Lite, discuss”的帖子于 2024 年 12 月开启，讨论项目是否应该为只想要文件和共享的用户发布一个精简版。一些用户，包括那些本来挺喜欢 Nextcloud 的人，提出了更轻构建的需求。但多数回帖持反对意见，理由是不需要的功能本来就能关掉，而削减安全类应用是笔划不来的买卖。帖子仍然开着，维护者也没有在任何一边表态。参考： help.nextcloud.com/t/nextcloud-lite-discuss/213611.
反方的论点同样重要。AIO 本身已经自带 PostgreSQL、Redis 和 APCu，它自己的性能指南也建议关掉你用不上的可选容器和 Nextcloud 应用。如果你的实例之所以重，是因为你启用了 Office、Talk、ClamAV、全文检索或其他早已不用的服务，那就先从那里修剪。如果你确实在同时使用这些服务，那更大的占用就是在做有用的事。
但如果你装好 Nextcloud 之后，只是为了把文件丢进一个同步文件夹才打开它，那么关于调优的讨论跟你无关。
关于 Nextcloud 与它最接近的分支如何对比，可以看我们的 Nextcloud 与 ownCloud 对比.
本节要点：对大多数自托管者实际使用的那一种工作流来说，Nextcloud 配置过剩了。
三种典型用户的自我诊断：哪条出路是你的？
在挑工具之前，先挑工作流。我聊过的几乎每一位 Nextcloud 用户，都能干净地归入三种模式之一。
典型 A。只做设备间同步。 “我装 Nextcloud 是为了让笔记本、台式机和手机保持同步。网页界面我从没拿来做过正经事。我也不跟别人共享文件。”
典型 B。团队文件共享。 “我装 Nextcloud，是因为需要多个人往一个共享文件空间里上传、从中下载。有时用浏览器，有时用桌面客户端。我在意大文件的性能。”
典型 C。只用网页门户。 “我把 Nextcloud 当网页文件浏览器装的。一种随时随地登录并取走自己文件的方式。桌面客户端我可能装过，但很少用。实时同步不是重点。”
如果其中两种都像你，就选那个会让你说出“这东西明天要是停了，我一小时内就会发现”的。那才是你真正依赖的工作流。其余的是锦上添花，以后可以替换，或者干脆不要。
每条路径的资源下限：
| 工具 | 内存建议 | 底层架构 | 同步模型 |
|---|---|---|---|
| Nextcloud AIO | 启用可选容器后从 2 GB 起，另按每个活跃用户约 1 GB | PHP + PostgreSQL + 多容器 | 客户端-服务器，整文件同步 |
| Seafile CE | 记录在案的最低值为 2 GB | C/Python + MariaDB | 客户端-服务器，块级去重 |
| Syncthing | 没有官方固定的最低值；随库的规模和扫描而变 | 单个 Go 二进制文件 | 点对点 |
| Cloudreve | 未公布官方的硬性最低值 | Go + 数据库 | 客户端-服务器，多后端存储 |
| AList | 未公布官方的硬性最低值 | Go + 默认 SQLite | 挂载存储之上的 Web 门户 |
上面 Nextcloud AIO 和 Seafile CE 的数字，是有据可查的要求或建议。Syncthing、Cloudreve 和 AList 并未公布可供干净并排比较的硬性内存最低值，所以请按你实际的库规模、存储后端和负载来估算这些工具的配置，而不要把社区给出的空闲内存数字当成硬性要求。
本节要点：挑那个契合你当初用 Nextcloud 做的事的工具，而不是功能清单最长的那个。
典型 A。设备间同步用 Syncthing
一台笔记本、一台台式机、一部手机。你把文件放进笔记本上的某个文件夹，二十秒后它就出现在另外两台设备上。没有网页门户，没有共享资料库，没有团队。Syncthing 就是为这件事造的，而它也只做这件事。
Syncthing 是点对点的。在架构意义上并不存在服务器。每台设备运行同一个二进制文件，设备之间通过全球中继网络或局域网互相发现。你可以把一台 VPS 加进这张网，但它只是众多节点中的一个，而非中心权威。没有网页文件浏览器，没有 CalDAV，也没有团队权限。如果你对 Nextcloud 的使用仅限于“让我自己的文件夹保持同步”，那么这些损失都无关紧要。
最受关注的是资源开销。在小规模的库上，比如 50 GB 以内的几千个文件，Syncthing 空闲时通常占用 50 到 100 MB 内存。一旦库涨到几十万个文件，内存占用可能超过 700 MB。大多数自托管者永远到不了那一步。但如果你在一个文件夹里放了二十五万个文件，你会到。
记录这一扩展行为的一手资料有两份：
- Syncthing 论坛上关于内存占用的长期帖子： forum.syncthing.net/t/ram-utilization/9769
- 项目自己在 GitHub 上关于扩展性断崖的议题： github.com/syncthing/syncthing/issues/468
即便在点对点模型里，VPS 依然有意义。你的笔记本和手机不会同时在线。如果你希望某台设备休眠时改动仍能传开，就需要第三台长期在线的设备。跑着 Syncthing 的 VPS 正好担任这个角色，并把最新副本交给下一台醒来的设备。小规模的库在 512 MB 内存以下就能轻松跑起来；如果你的库超过几十万个文件，就给它 1 GB。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 Linux 套餐关于 iOS 的那条保留意见，是 Syncthing 教程一笔带过的地方。没有官方的 iOS 版 Syncthing 客户端能可靠地在后台上传照片。第三方客户端有几个，但没有一个能比得上 Nextcloud 的 iOS 应用在相册备份上的表现。如果 iPhone 照片同步正是你运行 Nextcloud 的理由，那 Syncthing 本身替代不了它。变通办法是用 PhotoSync 之类的付费应用把照片推进 Syncthing 文件夹，或者在迁走其他一切的同时，单为这一条工作流把 Nextcloud 继续留着。
这个方向上的迁移摩擦很低。Syncthing 工作在普通文件系统之上。你把它指向文件本来就在的那个文件夹，加上其他机器的设备 ID，同步就开始了。没有东西需要转换，也没有东西需要导入。数据就是磁盘上原本那些。
本节要点：在设备到设备的同步上，Syncthing 在资源下限和可靠性上胜出，但在 iOS 照片备份上落败，并且彻底放弃了网页门户。
典型 B。团队文件同步用 Seafile
一个四人小队。一个叫“Operations”的共享资料库，里面是 60 GB 的合同、设计文件和导出件。四个人里有三个用桌面同步客户端，一个更喜欢浏览器。偶尔有人上传一段 4 GB 的视频。
只做文件共享的 Nextcloud 部署，也会随着活跃用户和可选服务的增加而需要更多余量。Seafile 在设计上就更窄，因此当只需要文件同步与共享时更容易估算规模。
Seafile 用 C 和 Python 编写，后端是 MariaDB，没有 PHP 层。它的同步模型是块级去重：当你改动一个文件时，只有变化的块会传输，而跨用户相同的块只存一份。Nextcloud 的默认同步在多数场景下传的是整个文件。
社区里关于 Seafile 在大规模库上更快的说法流传很广，原因确实在架构。我不会引用比较类文章里反复出现的倍数，因为那些线索追不到一手来源。我能说的是：Seafile 手册中记载的块级去重，正是速度差异存在的结构性原因。
Seafile Community Edition 当前的文档把最低配置列为 2 GB 内存和 2 个 CPU 核心。这与启用任意可选容器时 Nextcloud AIO 的 2 GB 最低值相当。Seafile 更窄的定位仍然可能让面向文件共享的规模估算更省心，但具体的内存差距取决于负载、活跃用户、库的规模，以及你启用了 Nextcloud 的哪些服务。
对于只需要文件同步与共享的团队，Seafile 让你可以避开那些用不上的 Nextcloud 附加服务。这确实可能减小服务器占用，但具体差距取决于负载，而不是“2 GB 对 5 GB”这样的固定规则。
迁移需要一些规划，因为并没有从 Nextcloud 到 Seafile 的原生导入工具。先把 Seafile 服务端搭起来，在一台能访问你现有文件的机器上安装 Seafile 桌面客户端，创建目标资料库，然后让客户端把文件传上去。搬迁耗时取决于库的规模和可用的上传带宽。
Seafile 把资料库数据存成块和内部对象，而不是可以直接浏览的普通文件。用 ls 列出数据目录，看到的是 Seafile 的内部对象结构，而不是你原来的文件夹树。加密是另一项独立功能，并不是这些对象难以辨读的原因。这意味着你没法靠从后端存储里复制几个看起来正常的文件来恢复一个 Seafile 资料库。
Seafile CE 还需要手动做垃圾回收。删除资料库或文件之后，你要运行一个脚本来清理没有引用的块。Pro 版把这部分自动化得更多，Community 版则没有。如果你的运维安全感来自随时能把数据原样复制出来，那 Seafile 会让你不太舒服，因为复制要用的是这条命令： cp -r.
另一项需要预先安排的损失是日历和联系人。Seafile 既没有实现 CalDAV，也没有实现 CardDAV。如果你的 Nextcloud 就是手机背后的通讯录，那你需要另找一个轻量服务来补上这个缺口。Radicale 和 Baikal 是常见的答案。
本节要点：如果你主要把 Nextcloud 当多用户文件共享用，Seafile 很合适。它以文件为中心的架构让你不必背上 Nextcloud 更宽的协作套件。代价是它基于块和对象的存储模型，以及失去 CalDAV/CardDAV。
典型 C。网页门户用 Cloudreve 或 AList
最被忽视的一条出路。这类用户想要的，是一个能从任何设备登录、取走自己文件的网页。桌面客户端他几乎从不用，实时同步他也不在乎。对这份差事来说，Nextcloud 的整套功能远超他的需要。
对这类用户而言，Nextcloud、Seafile、Syncthing 都不是对的答案。对的答案是一个网页门户。有两个项目干净地落在这里，而它们分野于一条轴线：这个工具是管理你的存储，还是只从中读取。
Cloudreve 是网页门户加一层受管存储。文件放在 Cloudreve 掌管的存储里（本地磁盘、兼容 S3 的对象存储，或其他后端）。它有用户账号和配额，而且 Cloudreve Pro 现在已经带有官方的 Windows 桌面客户端，支持实时双向同步。其架构是一个 Go 二进制文件加一个数据库，项目仓库活跃地址为 github.com/cloudreve/cloudreve.
AList 是在既有存储之上盖一层网页界面。它可以浏览并操作已挂载的后端，比如本地磁盘、S3、Google Drive、OneDrive、SMB 和 WebDAV，在后端支持的地方还能执行文件操作。它以 Go 二进制文件运行，默认使用 SQLite，因此基础部署不需要单独的数据库服务器。如果你的文件本来就以普通文件的形式躺在受支持的存储上，AList 可以直接把它们呈现出来，而不必导入成新的文件格式。
该怎么选：
- AList 如果你的文件已经在磁盘或云存储上整理好，你要的只是在其之上加一层统一的网页界面。迁移量基本为零，把 AList 指向文件所在的位置即可。
- Cloudreve 如果你想要一层受管的服务，带用户账号、配额，以及一个由门户从头到尾掌管的存储后端。迁移很轻：配置一个后端，把文件复制过去，完事。
在选定其中任何一个之前，有一点要说清楚：AList 不是同步的替代品，而 Cloudreve 的同步能力也比 Nextcloud 窄。Cloudreve Pro 有官方的 Windows 桌面同步客户端，但这两个工具都给不了你 Nextcloud 的 CalDAV/CardDAV 生态，也给不了跨全部平台的同等照片备份流程。如果这些是必需的，那你其实更接近典型 A 或 B，而不是 C。AList 和 Cloudreve 不是更轻的 Nextcloud，而是为更窄的活儿准备的更窄的工具。
本节要点：如果你主要用的是 Nextcloud 的网页文件浏览器，那 Cloudreve 和 AList 都是不错的选择。当你只需要在既有存储之上加一层网页时，AList 能把部署保持得更简单；当你想要受管存储、用户账号和 Windows 上的桌面同步时，Cloudreve 更说得通。
迁移摩擦图：你保留什么，失去什么
这就是拔掉电源之前该读的那张表。大多数搬迁正是在这里出岔子。
| 从 Nextcloud 迁往 | 文件能迁移吗 | 日历 / 联系人 | iOS 照片备份 | 笔记 / 任务 / Talk | 迁移工作量 |
|---|---|---|---|---|---|
| Syncthing | 可以，直接复制 | 需要单独的 CalDAV/CardDAV 服务 | 没有官方 iOS 客户端 | 不包括 | 取决于数据量和设备数量 |
| Seafile | 可以，通过桌面客户端上传 | 需要单独的 CalDAV/CardDAV 服务 | 通过 Seafile 的移动应用支持 | 不包括 | 取决于数据量和上传速度 |
| Cloudreve | 可以，复制到已配置的存储 | 不包括 | 没有与 Nextcloud 相机备份对等的流程 | 不包括 | 取决于后端和数据量 |
| AList | 既有的普通存储可以就地挂载 | 不包括 | 没有原生的移动端同步 | 不包括 | 如果文件已在受支持的后端上则很低 |
CalDAV/CardDAV 的缺口，是最容易被忽视的一项迁移成本。如果你手机的通讯录是同步到 Nextcloud 的，那么无论你用哪个文件工具来替代，这条链路都会在你停止运行 Nextcloud 的那一刻断掉。Radicale 和 Baikal 是常见的轻量替代，两者都比一套完整的 Nextcloud 安装小得多。在给 Nextcloud 实例拔电源之前，这些补缺的方案值得先放进视野。
如果你想要一个独立环境，在押上自己的数据之前先把迁移跑一遍，那么 Cloudzy 的 Linux VPS 能给你一块干净的地方来做这件事。一台独立的测试服务器让你可以在不碰生产实例的前提下演练搬迁，下面这些你都能一键部署：
什么时候你该留在 Nextcloud
这套诊断是双向的。下面是留下来的三个理由，按分量排列。
你确实在用日历、联系人、任务和笔记这一整套。 Nextcloud 把这四样收在同一个登录之后，配上能用的 CalDAV/CardDAV 实现、能用的网页界面和能用的移动客户端。用分立服务来替代它，意味着要跑 Radicale 或 Baikal 来管日历和联系人，再加一个单独的笔记应用和一个单独的任务管理。一个服务变成两三个，一种故障方式也变成两三种。如果这就是你的日常，那 Nextcloud 是在为自己的内存开销买单。
你依赖 Nextcloud 内置的协作体系。 Nextcloud 把文件、文档编辑、日历、联系人、任务、笔记和其他协作功能收在同一个账号和界面之后。Seafile 也能集成 Collabora 或 OnlyOffice 来做文档的同时编辑，所以单凭协作文档这一点并不足以把它排除。差别在于：要替换 Nextcloud 更宽的生态，仍然意味着要为 Seafile 不覆盖的那些功能拼装分立的服务。
你的 Nextcloud 之所以重，是因为那些你不用的服务。 AIO 已经自带 PostgreSQL、Redis 和 APCu，所以换数据库或启用 APCu 并不是这里该做的调优步骤。先从关掉用不上的可选容器和 Nextcloud 应用开始。如果 Office、Talk、ClamAV、全文检索或预览服务在没有实际用途的情况下跑着，那就在决定迁移之前先把这份负载卸掉。
那句“只用了 10% 的功能就该走”的逻辑，同样也在说“真的在用这些功能就该留”。诚实地判断你属于哪一种。
本节要点：如果你的工作流包含日历、联系人和协作文档，那 Nextcloud 仍然是对的工具。逃走之前，先把配置理顺。
常见问题
Nextcloud 最轻的替代品是什么？
这要看工作流。AList 是纯网页访问文件时最简单的选择之一，因为它可以直接架在既有存储之上，并默认使用 SQLite。Syncthing 是设备间同步这件事上更窄的选择。当你需要多用户文件共享时，Seafile Community Edition 是更完整的替代，其记录在案的最低配置是 2 GB 内存和 2 个 CPU 核心。
Seafile 比 Nextcloud 更省内存吗？
对于只做文件共享的负载，Seafile 可能需要更少的资源，但并不存在适用于所有部署的固定内存差值。视配置而定，Seafile CE 和 Nextcloud AIO 都可能从 2 GB 左右的基线起步。此后 Nextcloud 的推荐容量会随活跃用户和启用的服务增长，而 Seafile 是围绕文件同步与共享这一更窄的负载构建的。
怎样从 Nextcloud 迁到 Seafile？
没有自动导入工具。行之有效的路径是：安装 Seafile，在一台能读取你 Nextcloud 数据目录的机器上安装 Seafile 桌面客户端，在 Seafile 服务端创建一个资料库，然后让桌面客户端把文件以块的形式推进去。日历和联系人不会随文件一起搬走。你需要另外搭一台 Radicale 或 Baikal 这样的 CalDAV 服务器，并从手机重新同步。迁移耗时取决于数据量和你可用的上传带宽。
照片备份是 Syncthing 比 Nextcloud 更好吗？
在移动端并不能一概而论。Syncthing 的官方 Android 应用在 2024 年 12 月那次发布之后就停止维护了，不过社区维护的 Android 方案仍然存在。iOS 至今没有具备 Nextcloud 那种后台照片备份能力的官方 Syncthing 客户端。如果相册自动备份是你整套方案的核心，那就把移动端支持当成一个单独的决定，而不要默认 Syncthing 能取代 Nextcloud 的应用。
我能在低价 VPS 上运行 Nextcloud 的替代品吗？
可以，但请按具体的工具和负载来估算 VPS 规格，不要默认一个内存目标适用于这四者。Seafile CE 官方建议至少 2 GB 内存和 2 个 CPU 核心。Syncthing、AList 和 Cloudreve 并未就这里讨论的这些负载给出可直接比较的硬性内存最低值，所以请从它们各自的部署要求出发，并为库的规模、数据库和存储后端留出余量。
讨论
评论
登录后参与讨论。