CapSoftware/Cap

如果你的团队在用 Loom，又不希望录屏长期存放在别人的服务器上，Cap 值得认真评估。它不只是录制工具，还包含分享平台，所以除了录制体验，还要考虑谁来部署和维护分享服务。

解决什么问题

要录一段 bug 复现或产品演示发给同事，通常得先录屏、上传、设置权限，再把链接贴到聊天里；用托管分享服务时，视频还会进入你无法控制的存储。Cap 把这几步合成一个流程：可以录屏幕、摄像头和麦克风，然后立即拿到分享链接（Instant Mode 边录边上传），也可以先在本地编辑器里裁剪、加背景、缩放和字幕，再分享出去（Studio Mode）。最终得到的是一个带评论、转录和观看统计的观看页面，而不只是一个附件。

有什么不同

真正的差异在存储。录像可以放在 Cap Cloud，也可以接入 AWS S3、Cloudflare R2、MinIO 或 Wasabi 等 S3 兼容存储，或只保存在本地；整个 Web 平台还能用 Docker Compose 自托管。桌面端支持 macOS 和 Windows，采集与导出由 Rust crate 承担，桌面界面基于 Tauri。对想替换付费异步视频工具的团队来说，这比单纯一个录屏器更有吸引力。

代价是范围大。仓库是一个 Turborepo monorepo，包含 Next.js Web 应用、SolidStart 桌面界面、媒体服务、Discord bot、CLI 和数据库包；自托管意味着要同时运营 Web、API、数据库和媒体服务。README 还特别提醒，分析配置命令可能删除 checked-in 配置之外的 Tinybird 资源，说明部分内置工具并非只读操作。如果只是偶尔录一段个人视频，这套设施是负担；如果团队本来就在运维基础设施，这正是选择 Cap 的理由。

谁值得试

适合：目前用托管服务分享视频、手上已有 S3 存储桶或小服务器、希望链接跑在自己域名上并控制保留策略的团队。也适合主要录制本地演示并导出文件的个人，因为 Studio Mode 不依赖分享平台。

不适合：只想装完就录、不在意上传去哪里的用户，或者团队里没人愿意负责自托管部署。README 把生产使用当成一项配置任务，要求暴露到公网前设置公共 URL 并替换默认密钥，这是持续维护责任，不是一次性安装。还要注意许可证是分开的：摄像头和 scap-* 系列 crate 是 MIT，其余大部分代码是 AGPLv3。

使用条件与边界

从源码运行需要 Node.js 24+、Bun 1.4.4、Rust 1.88+，以及用于 MySQL 和 MinIO 的 Docker，等于要在三个生态里维持较新的工具链。用 Docker Compose 自托管更轻，但指南把邮件、AI 服务商、SSL、存储和生产加固都列为需要另行处理的事项。认证是反复出现的主题：未配置邮件时登录链接会输出到服务日志；位于认证反向代理之后的单用户实例，还需要单独配置带共享密钥的 trusted-proxy。

有一条较早的反馈值得留意，但不应当成现状：2024 年 10 月 Show HN 讨论中有评论者称，浏览器登录后桌面应用没有完成认证。按 HotRepo 最后观测时间算，这个帖子已接近两年，实际登录表现要以你打算采用的托管方式为准。

HotRepo 点评

HotRepo 记录到 Cap 两次登上每日 Trending 榜：2026-10-24（+81 星）和 2026-10-25（+94 星），该样本内达到 23,705 星。两天窗口太短，无法判断关注度是持续还是消退。真要采用，先核对自托管指南是否覆盖你的存储、邮件和域名配置，再决定是否把团队的录像库迁过去。