rivet-dev/rivet

Rivet 调度的是 "Actor"：按 key 寻址的长时存活进程，每个都有自己的 SQLite 数据库、键值存储、队列、实时连接和定时调度。它面向需要运行大量小型有状态负载的团队——每个 agent、会话、租户、文档或房间一个——而不必为每个负载单独准备容器或虚拟机。控制面是一个 Rust 二进制；托管云、BYOC 和完全自托管运行同一套代码。

工作方式的变化

不必把每个 agent 或文档建模成 pod，而是在 Node.js 或 Bun 上用 TypeScript/Rust 定义 actor 的 action。一个 action 可以写入该 actor 的 SQLite 数据库，并通过 WebSocket 向已连接的客户端广播；客户端通过生成的类型化客户端按 key 调用。空闲 actor 会持久化状态并卸载，下次请求时再唤醒；节点故障时，其 actor 会被重新调度到别处且状态完好。这是主要取舍：放弃按单元划分的容器，换来轻量、按 key 寻址的单元，并内置持久化、路由和调度。

文档列出的典型用途包括：每个编码 agent 一个 actor、为生成的用户应用提供独立后端、留在 VPC 内的公司内部 agent，以及每个实时房间一个 actor。Workflow 和 sandbox 也是可用的 actor 类型。另有一个 skills 包，可把搭建说明交给 Claude Code、Cursor 等 AI 编程工具。

部署与依赖

README 称单个控制面可承载大量 actor，并给出了具体基准数字，这是该架构的核心卖点。自托管需要：多个相同的控制面实例（试运行一个，生产三个以上）、每个实例一块持久磁盘、每个集群一个对象存储桶（S3、GCS、Azure Blob，或 MinIO、R2 等 S3 兼容存储），以及运行 actor 的节点。对象存储桶是唯一的外部依赖；项目表示不需要 Postgres、FoundationDB 或 NATS。单机试用可用本地文件系统后端。部署指南覆盖 Docker Compose、Kubernetes、VM、AWS ECS、Railway 和 Render；节点只需一个通过 WebSocket 连接的标准进程。

性能声明的适用范围

6.92 ms 冷启动和 4.37 ms 唤醒数字来自明确条件：2026 年 10 月 25 日，Azure eastus2，三个可用区各一个控制面实例，写入由 3 个实例中的 2 个确认，一个运行 Node.js 24 的节点虚拟机。测量的是从客户端发送到收到完整首个响应，而非应用层吞吐。内存数字是使用 Rust SDK 时每个 actor 的 RSS 增量。与 Kubernetes 的对比被描述为典型公开值，并非同一条件下的基准测试。

限制与未决问题

每个 actor 独立一个 SQLite 数据库，使跨 actor 查询变得不那么直接。在 HN 讨论中，维护者承认这一点，并表示计划构建跨库查询引擎，DuckDB 是考虑方案之一；讨论也提到重新实现数据库事务的负担。一位评论者表示已将某个 Durable Objects 功能替换为 Rivet Actors 且使用满意，但尚未使用 SQLite 存储。这些是 2026 年 2 月的用户观点，不是项目保证。Python 和 Swift SDK 标注为实验性；TypeScript 和 Rust SDK 是主要路径。

项目采用 Apache-2.0 许可，自托管在该条款下被允许。选择自托管还是托管云，取决于合规与运维需求。

项目源码与说明