DocuSeal：用 Ruby 写的开源 DocuSign 替代品，部署简单但 AGPL 授权需留意

它解决什么问题，谁需要它

DocuSeal 解决的是数字文档签署流程的最后一公里：把 PDF 变成可在线填写和签名的表单。它面向的是需要替代 DocuSign 或 Adobe Sign 的团队，但不想把文档数据托管在第三方云服务上。典型使用者是中小型公司、律所、人事部门，或者那些需要把签署功能嵌入到自己产品里的开发者。README 里明确说它支持“Create PDF forms to have them filled and signed online on any device”，并且强调移动端优化。换句话说，它不是一个通用的文档管理系统，而是一个专门处理表单填写和电子签名的工具。如果你只需要简单的 PDF 编辑，它并不合适。

核心机制：从 PDF 表单到签署流程

DocuSeal 的工作流程可以拆成三步。第一步，用内置的 WYSIWYG 表单构建器在 PDF 上拖放字段，支持签名、日期、文件、复选框等 12 种字段类型。第二步，把表单发给多个签署人，系统通过 SMTP 自动发送邮件通知。第三步，签署人在浏览器里完成填写和签名，DocuSeal 自动生成电子签名并写入 PDF。这里的关键是“Automatic PDF eSignature”，意味着签名过程不需要用户手绘或上传图片，而是由系统在 PDF 上生成签名图像。同时它还提供“PDF signature verification”，用于验证文档是否被篡改。数据存储方面，默认使用 SQLite，但可以通过 DATABASE_URL 环境变量切换到 PostgreSQL 或 MySQL。文件存储支持本地磁盘、AWS S3、Google Storage 和 Azure Cloud。整个架构是典型的 Ruby on Rails 风格，但 README 没有给出内部组件细节，所以无法确认是否使用 Sidekiq 或 ActiveJob 之类的后台任务。

部署方式：Docker 是首选路径

部署 DocuSeal 最直接的方式是 Docker。README 给出的命令是：docker run --name docuseal -p 3000:3000 -v.:/data docuseal/docuseal。这条命令会启动一个容器，把当前目录挂载到 /data，用于持久化数据。默认使用 SQLite，所以不需要额外配置数据库。如果要换用 PostgreSQL 或 MySQL，只需设置 DATABASE_URL 环境变量。对于生产环境，官方推荐使用 Docker Compose，并提供了下载 docker-compose.yml 的命令：curl https://raw.githubusercontent.com/docusealco/docuseal/master/docker-compose.yml > docker-compose.yml。然后通过 sudo HOST=your-domain-name.com docker compose up 启动，这个命令会利用 Caddy 自动申请 SSL 证书。注意，这里要求 DNS 已经指向你的服务器，否则证书签发会失败。除了 Docker，README 还列出了 Heroku、Railway、DigitalOcean 和 Render 的一键部署入口，说明项目对平台兼容性做了不少工作。但如果你不想用 Docker，官方没有提供裸机安装指南，所以非容器环境下的部署需要自己摸索。

功能边界：开源版与 Pro 版的差距

DocuSeal 的开源版功能并不少，但有几项关键能力被划入 Pro 版本。开源版包含表单字段构建器、12 种字段类型、多签署人、SMTP 邮件、三种对象存储、用户管理、移动端适配、7 种 UI 语言和 14 种签署语言、API 和 Webhooks。这些功能已经能支撑基本的签署流程。但 Pro 版额外提供白标、用户角色、自动提醒、SMS 邀请和身份验证、条件字段和公式、CSV/XLSX 批量发送、SSO/SAML，以及 HTML API 和 PDF/DOCX 字段标签 API 来创建模板。其中“条件字段和公式”对复杂表单很重要，比如根据某个复选框动态显示其他字段，这在开源版中做不到。另外，嵌入式签署表单和嵌入式表单构建器也被列为 Pro 功能，这意味着如果你想在自己的 React、Vue 或 Angular 应用里嵌入签署界面，需要付费。这个功能分层策略很清晰：开源版适合内部使用，Pro 版适合产品集成。

许可证的坑：AGPL 不是 MIT

DocuSeal 使用 AGPL-3.0 许可证，并附加了第 7(b) 条附加条款。这意味着如果你修改了源码，并且通过网络向用户提供服务，你必须公开修改后的源码。对于内部使用，AGPL 的限制相对宽松，但如果你打算把 DocuSeal 嵌入到自己的商业产品中，或者作为 SaaS 服务对外提供，就必须考虑开源义务。README 中明确写了“Distributed under the AGPLv3 License with Section 7(b) Additional Terms”，并且提到所有文件版权归 DocuSeal LLC 所有。这里有一个实际风险：如果开发者修改了 DocuSeal 的代码并部署在公网服务器上，即使没有分发软件，也可能被要求公开源码。这一点与 MIT 或 Apache 许可证完全不同。如果你的公司对许可证合规有严格要求，建议在采用前咨询法务。另外，附加条款可能包含额外的限制或条件，但 README 没有详细说明，需要查看 LICENSE_ADDITIONAL_TERMS 文件。

替代方案：与 DocuSign 和 Paperless-ngx 的对比

DocuSeal 最直接的替代品是 DocuSign 本身，但那是商业 SaaS，数据不在你手里。另一个开源替代是 Paperless-ngx，但它更偏向文档归档和 OCR，而不是签署流程。与 DocuSign 相比，DocuSeal 的优势是自托管和数据控制，劣势是缺少成熟的合规认证和广泛的集成生态。与 Paperless-ngx 相比，DocuSeal 专注于签署，而 Paperless-ngx 专注于文档生命周期管理。如果你需要的是“创建表单、发送签署请求、跟踪状态”，DocuSeal 更合适。如果你需要的是“扫描、分类、检索文档”，Paperless-ngx 更合适。还有一个值得注意的差异是 DocuSeal 的签署流程是自动化的，签署人不需要安装任何软件，只需浏览器。而 Paperless-ngx 本身没有签署功能。所以选择哪个取决于你的核心需求是“签”还是“存”。

维护与升级成本

从发布频率看，DocuSeal 的维护相当活跃。最近三个版本分别是 3.2.2（2026-08-25）、3.2.1（2026-08-17）和 3.2.0（2026-08-11），间隔大约一周。这说明项目处于快速迭代期，bug 修复和功能更新都比较频繁。但这也意味着升级成本不低，因为你需要跟踪每个版本的变更，尤其是数据库迁移。由于默认使用 SQLite，小规模部署的升级相对简单，但如果你切换到 PostgreSQL，迁移就需要谨慎。另外，项目没有提供自动升级工具，你需要自己处理 docker compose pull 和容器重建。考虑到 AGPL 许可证，如果你修改了源码，每次升级都需要重新合并补丁，这会显著增加维护负担。如果你只是原样使用官方镜像，升级成本主要是停机时间和数据备份。总体而言，DocuSeal 的维护是可持续的，但你不能指望像商业软件那样有长期支持版本。

编辑结论

DocuSeal 适合那些需要快速自托管电子签名流程、且团队能接受 AGPL 许可证约束的中小型组织。它尤其适合已有 Docker 环境的团队，因为官方提供的 docker run 和 docker compose 命令可以在几分钟内启动一个带 SQLite 的实例。但不适合需要白标、SMS 身份验证、批量发送或 SSO 的企业，这些功能被锁定在 Pro 版本。在采用前，请先验证三件事：你的使用场景是否触发 AGPL 的 copyleft 条款，尤其是当你计划修改源码并对外提供服务时；你的存储需求是否匹配默认的本地磁盘，还是需要配置 AWS S3、Google Storage 或 Azure；你的签署流程是否依赖条件字段或公式，这些在开源版中不可用。如果这些限制可以接受，DocuSeal 的部署成本和功能覆盖在同类开源工具中具有明显优势。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes