Trilli：MIT协议开源的全栈云存储平台，Dropbox替代方案

一个反常规的开源决定

在SaaS创业者们纷纷将核心代码锁在"企业版"付费墙背后的今天，一位独立开发者做出了截然相反的选择：在将自己的云存储平台商业化运营之后，他把整个代码库以MIT协议完全开源——包括平台本身和运营控制台，没有任何保留的"企业版"。

这个名为 Trilli 的项目，定位是 Dropbox + Google Docs + DocuSign 的自托管替代方案。换句话说，它试图用一套开源系统覆盖"文件存储、在线文档协作、电子签名"这三大企业刚需场景。作者表示，他此前已经将其作为商业化SaaS在实际运营，这意味着这套代码并非玩具级Demo，而是经过生产环境验证的成熟系统。

Trilli 开源云存储平台

Trilli功能全景：一站式企业文档基础设施

Trilli 的功能覆盖面相当完整，几乎把企业日常文档工作流的关键环节都纳入了进来。

存储与安全：按租户静态加密

最值得关注的是它的**按租户静态加密（per-tenant encryption at rest）**设计。作者特别强调，存储提供商只能看到密文（ciphertext），无法接触明文数据。这种设计在多租户场景下尤为重要——它意味着即使底层存储服务被攻破，或者存储服务商本身不可信，租户数据依然受到保护。对于处理敏感合同、财务文件的企业用户而言，这是一个硬性合规诉求。

文档协作：基于Collabora的在线编辑

在浏览器内的Office协同编辑通过 Collabora / WOPI 协议实现。这套方案是LibreOffice Online的商业化分支，能够提供接近Google Docs的多人实时协作体验，同时保持文档存储在自己的服务器上。这对不愿把商业机密交给Google的团队来说是个务实选择。

WOPI（Web Application Open Platform Interface）是微软提出的开放协议标准，定义了Web应用与文档存储服务之间的交互方式。通过WOPI，Collabora Online可以直接读写存储在Trilli服务器上的文件，而无需将文档上传到第三方服务器。Collabora Online本身基于LibreOffice内核，支持.docx、.xlsx、.pptx等主流Office格式的渲染与编辑，兼容性远优于单纯的Markdown或纯文本方案。这套组合的部署成本相对较高——Collabora需要单独运行一个容器服务——但换来的是接近商业产品的文档编辑体验和完全的数据主权。

电子签名：PKCS#7标准密封

电子签名功能采用 PKCS#7 密封文档。PKCS#7是行业标准的加密消息语法，用它对签署后的PDF进行数字密封，可以保证文档的完整性和签名的的确如此性。这让Trilli的电签能力具备了法律效力层面的技术基础，而不是简单地在PDF上贴张图片。

此外，平台还包含文件共享、文件请求门户（file-request portals）以及一系列PDF工具，构成了完整的文档处理链条。

PKCS#7（Public Key Cryptography Standards #7）现已被IETF标准化为RFC 5652，即CMS（Cryptographic Message Syntax，加密消息语法）。它定义了对数据进行数字签名、加密、摘要等操作的标准封装格式。在电子签名场景中，用PKCS#7对PDF进行密封，实际上是将签名者的数字证书、签名时间戳、文档哈希值等信息一并嵌入文件，使得任何后续对文档内容的篡改都会导致签名验证失败。这与欧盟eIDAS法规认可的PAdES（PDF高级电子签名）标准高度兼容。需要注意的是，技术合规性只是法律效力的必要条件之一，各国对电子签名法律效力的认定还涉及签名人身份认证方式等其他要素。

完整的商业运营层也一并开源

Trilli 真正与众不同的地方，在于它连商业运营层都一并开源了。

作者把 Stripe 计费、席位管理（seats）、用量计量（metering）、工单支持系统（support desk）全都放进了代码库。这意味着任何人拿到这套代码，不仅能自托管自用，理论上还能直接开一家类似的SaaS生意对外服务。

这在开源商业化的语境下是个大胆的举动。绝大多数"开源SaaS"采用的是Open-Core模式——开源一个功能受限的社区版，把计费、多租户、SSO等"变现功能"留在闭源的企业版里。Trilli 反其道而行，把最能构成护城河的商业层也放了出来。从纯商业角度看这颇具风险，但对开源生态和自托管社区而言，无疑是一份诚意十足的贡献。

Open-Core模式是当前开源商业化的主流路径，由Elastic、GitLab、HashiCorp等众多知名项目采用。其核心逻辑是：将基础功能开源以积累用户和社区影响力，将高价值的企业级功能（如SSO单点登录、审计日志、高级权限管理、多租户隔离、SLA支持等）封锁在付费的企业版中，形成从开源用户到付费客户的转化漏斗。这一模式的本质张力在于：开源的部分越强，社区越活跃，但企业版的差异化越难维持；反之则口碑受损。Trilli选择放弃这一护城河，意味着它的竞争优势将完全依赖品牌、支持服务质量，以及托管版本的便利性，而非代码上的功能壁垒。

工程架构：Go + React + Postgres 极简技术栈

作者反复强调，这套系统"built to be readable"（为易读而构建），其架构选型也体现了这一克制而务实的理念：

每个服务一个 Go 二进制文件：Go 语言编译产物单一、部署简单、性能可靠，微服务拆分保持了模块边界清晰。
React 应用嵌入可执行文件：前端直接打包进后端二进制，省去了独立部署前端的复杂度，单文件即可运行。
Postgres 承载一切：不引入复杂的多数据库栈，用一个成熟稳定的关系型数据库解决所有存储需求。

这套技术栈的共同特征是简单、可维护、易于自托管。对于中小团队或个人运维者来说，越少的组件意味着越低的运维负担。仓库中还提供了文档、环境变量示例和 systemd 服务单元文件，进一步降低了部署门槛。

后续发展方向与社区期待

作者在发布时明确表示欢迎反馈、Issue 和 PR，并点出了当前愿望清单上的头号需求：S3 / MinIO 存储后端。

这个需求切中要害。目前平台的存储方案若要在云原生环境中大规模部署，对接S3兼容的对象存储几乎是刚需。MinIO作为开源的S3兼容存储，也是自托管场景的黄金搭档。一旦这个后端落地，Trilli 的可扩展性和生产可用性将显著提升。

结语：完全开源的商业SaaS能走多远

Trilli 的故事很难简单归类。它既不是纯粹为爱发电的兴趣项目，也不是精心设计的Open-Core变现漏斗，而是一位开发者在完整验证了商业模式之后，选择把全部成果——技术层和商业层——毫无保留地交给社区。

对于寻求 Dropbox / Google Docs / DocuSign 自托管替代方案的团队来说，Trilli 提供了一个功能完整、架构清晰、且经过生产检验的起点。对于关注开源商业化模式的观察者而言，它则是一个值得持续跟踪的案例：完全开源的商业SaaS，究竟能走多远。

项目地址：https://github.com/elevityadmin/trilli