主题

关于 AsterDrive ​

这一页没有教你怎么做事

这一篇讲 AsterDrive 是什么、为什么存在、想做成什么样、不想做成什么样。
如果你只想跑起来用，去 快速开始；这一页留着以后看。

AsterDrive 是什么 ​

一个自托管的云存储——用 Rust 写的，单个二进制，一条命令跑起来。

这话本身不稀奇。市面上自托管云盘已经有不少成熟方案，AsterDrive 不是要替代它们。我们做这个，是因为对"轻、快、改得动"这几件事有自己的偏好，所以重新写了一个。

它现在也不只是一台机器上的单机网盘了。除了把文件落在本机目录、S3 / MinIO 这类对象存储上，也能把另一台 AsterDrive 节点当成远程存储后端：主控节点负责用户、前端、后台和策略，从节点负责接收内部签名后的对象读写请求。

我们想做成什么样 ​

能用，好用，适合我用 ​

这是三层递进。

能用——跑得起来，不出错，数据不丢。
好用——日常操作顺手，不别扭。
适合我用——不是"通用方案"，是"刚好是我要的这个"。

最后一层是 hackable 的另一面：你可以让它变成适合你的样子，因为代码在你手里。

一条命令跑起来 ​

部署门槛低到极致。一条 docker run 就能看到自己的第一个文件躺在自己服务器上的感觉——我们试过让这件事尽量不需要你先成为运维专家。

不需要装 PHP、不需要配 nginx + php-fpm、不需要先建数据库、不需要装 Redis。一个静态二进制，启动几秒，请求毫秒级。

先是一个安心放文件的地方 ​

如果只能保留三个功能，我们留：文件管理、上传下载、回收站。

注意没有分享、没有团队、没有 WebDAV、没有 WOPI——这些是好东西，但不是骨架。骨架是：你敢把重要文件放进去。

回收站排进前三是有意识的。没有回收站，你不会真的信任这个系统。

单机优先，但不把自己锁死在单机 ​

我们还是先把单机体验放在第一位，因为大多数人第一天要的不是"分布式架构"，是"先把服务跑起来"。

但这不代表 AsterDrive 只能永远停在单机。现在它已经支持两种比较现实的扩展路线：

  • 继续把文件落在当前机器，适合最简单的部署
  • 把文件改走 S3 / MinIO，适合把对象存储单独拆出去
  • 把另一台 AsterDrive 接成从节点，由主控节点通过内部协议把对象写过去

第三条很重要，因为它代表 AsterDrive 终于有了"控制面和存储面分开"这条路。

但也别脑补过头。现在的远程节点能力是“远程存储后端”，不是“多主集群”：

  • 主控节点还是唯一的登录入口、管理后台和策略控制面
  • 从节点不提供给普通用户登录，也不是第二个前端站点
  • 我们解决的是"对象怎么写到另一台机器"；不是"跨地域一致性、自动故障切换、双主同步"这种更贵的问题

改得动（hackable） ​

这是 AsterDrive 最重要的设计原则。

代码用 Rust 写，分层清晰，错误处理双层码、repo / service 分层、依赖少而稳。我们希望你 fork 之后能看懂、能改、能扩展、能 PR 回来。

就连刚长出来的远程节点能力，也尽量按这个思路做：

  • primary / follower 两种运行模式拆开，不把所有逻辑拧成一坨
  • 远程节点、主控绑定、接入会话分成独立模型，而不是一张神奇大表
  • 接入流程走明确的 node enroll CLI，不靠手工复制一堆密钥和隐藏配置

我们最喜欢的 issue 长这样：

"你这个项目有问题啊，这里有点小问题，我 fork 了一下你看能不能合"

不是因为你帮我们干活——而是这意味着你真的把这个项目当成自己的。这就是 hackable 的意思。

我们不想做成什么样 ​

不会有付费版 / Pro 版 / 功能墙 ​

所有功能在 MIT 协议下开源，每个人能用到的东西完全一样。

现在没有，将来也不会有。

那作者怎么活？

我们接二次开发、定制功能、商业部署咨询——如果你需要这些，可以 联系作者。

也欢迎 Sponsor；Sponsor 的反馈会被优先看。这不是把功能锁起来，是对支持者的诚实回报。

我们想要的是开源项目的可持续性，不是商业模式。

不商业化，但希望社区驱动 ​

虽然现在 AsterDrive 还只是一个人的项目，但我们一开始就是按"社区驱动"来设计的：

  • 代码可读，新人能看懂
  • 架构分层清晰，PR 容易找到落点
  • 文档分角色（部署者 / 管理员 / 普通用户 / 开发者），而不是堆在一起
  • 错误码千位分域，对接前端或第三方时不用猜
  • 跨数据库支持（SQLite / PostgreSQL / MySQL），别人能在自己的环境部署

我们希望这个项目以后不只是 AptS:1547 的项目，是所有把它跑起来的人的项目。

不假装比物理定律更可靠 ​

我们不会写"绝对安全"、"100% 可靠"这种话。

硬盘会坏，网络会断，磁盘会满，软件会有 bug。备份是你自己的责任——除非你给数据上 RAID 10，我们也不敢保证你不丢数据。

我们能做的是：

  • 把上传 / 下载 / 元数据每一层都做扎实
  • 提供 doctor 工具帮你校验一致性
  • 提供 完整备份恢复方案
  • 在出错时给你清晰的错误码 + 能定位问题的日志

剩下的，你自己安排。

适合谁用 ​

三类典型场景

  • 想替代商业网盘但又不想自己拼一堆开源组件的人
  • 想给家人共享照片视频、希望爸妈也能用得明白的人
  • 小团队需要一个轻量、可控的方案
  • 想把主控站点和真实存储落点拆开，但又不想自己先发明一套内部对象协议的人

如果你属于其中一类，快速开始 走一遍就知道这个项目对不对你味。

不适合谁用 ​

诚实地说，AsterDrive 不适合这些场景：

  • 千万级文件 / 上百 TB 数据 —— 设计目标是个人和小团队，不是企业云
  • 需要复杂权限矩阵（部门 / 角色 / ACL 嵌套） —— 我们故意做得简单
  • 现在就要本地客户端实时同步 —— 网页端已经能通过 SSE 实时刷新当前视图，但这不是本地文件夹双向同步客户端。未来会出 macOS / Windows / Linux / iOS / Android 五端客户端，但还要等。如果你现在就要 Dropbox 那种体验，可以先用 WebDAV 配 rclone / Mountain Duck 顶一阵。
  • 需要极强的合规审计（HIPAA / SOC2 / 等保） —— 我们提供基础审计日志，但不会替你做合规认证
  • 现在就要多主热备 / 自动故障切换 / 跨地域强一致复制 —— 当前远程节点能力是"远程存储后端"，不是集群编排系统

如果你的场景在上面这几条里，AsterDrive 可能不是你要找的——这没什么不好意思承认的。

为什么用 Rust ​

简短回答：作者本来就写 Rust。

完整回答：Rust 给我们的是性能 + 内存安全 + 单二进制分发。不需要 runtime、不需要垃圾回收停顿、不需要担心一个空指针让整个服务挂掉。

这不意味着 Rust 一定比 Go / Java / TypeScript 强——只是这个项目的目标（轻、快、改得动）跟 Rust 比较合拍。

后续路线 ​

短期重点（v0.1 之前）：

  • 把当前功能打磨稳定
  • 把远程节点第一版的文档、运维路径和错误反馈补齐
  • 准备 v0.0.1 正式发布

中期想做的（issue 列表里）：

  • SFTP / WebDAV / Azure Blob 作为存储后端
  • OneDrive / Google Drive 同步连接件
  • 五端本地客户端（macOS / Windows / Linux / iOS / Android）实现真正的实时同步

但这些都要等代码合了再写文档——我们不写承诺空头支票的文档。

项目归属

AsterDrive 后续可能会并入 AsterCommunity 一起维护——这是我们搞的一个专门写代码的组织，跟 The-ESAP-Project 是同级。
仓库迁移时会有完整的重定向，现有 fork、issue、star 不受影响。

三年后最坏的结局会是什么 ​

最坏的结局是没人用我的项目。

但即便如此，它仍然是我最喜欢、用起来最没负担的项目——所以我会继续把它写下去。

如果你决定加入这个项目（不管是用、还是改、还是 sponsor），谢谢你。如果没有，我们也理解。

想参与 ​

愿你用得顺手。
—— AptS:1547

基于 MIT 许可证发布

Copyright © 2026 AptS:1547