一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
类型解锁
阶段船队
难度中等
工作多租户 SaaS
用于个人创始人
用于开发团队
用于代理机构
服务容器
服务快照
服务Exec
服务文件
为何选 Hoody容器经济学
为何选 Hoody裸金属隔离
为何选 Hoody快照时间旅行
行业SaaS
类型解锁
阶段船队
难度中等
工作多租户 SaaS
用于个人创始人
用于开发团队
用于代理机构
服务容器
服务快照
服务Exec
服务文件
为何选 Hoody容器经济学
为何选 Hoody裸金属隔离
为何选 Hoody快照时间旅行
行业SaaS
类型解锁
阶段船队
难度中等
工作多租户 SaaS
用于个人创始人
用于开发团队
用于代理机构
服务容器
服务快照
服务Exec
服务文件
为何选 Hoody容器经济学
为何选 Hoody裸金属隔离
为何选 Hoody快照时间旅行
行业SaaS
类型解锁
阶段船队
难度中等
工作多租户 SaaS
用于个人创始人
用于开发团队
用于代理机构
服务容器
服务快照
服务Exec
服务文件
为何选 Hoody容器经济学
为何选 Hoody裸金属隔离
为何选 Hoody快照时间旅行
行业SaaS
use-cases / one-sandbox-per-customer / hero
容器 · 多租户 SAAS
每个客户一个沙箱，自动进行
停止在每个表中分散 tenant_id。当客户注册时，一个 exec 脚本复制一个新客户容器，并给他们自己的 URL、自己的文件系统、自己的 SQLite。隔离是他们之间的操作系统，而不是 WHERE 子句。
注册 WEBHOOK → 容器创建
你的 WEBHOOK 处理器
POST# 由 Stripe checkout.session.completed 触发
POST /api/v1/projects/{id}/containers
Authorization: Bearer hdy_***
{
"user_id": "usr_7xk9",
"container_image": "ubuntu/24.04",
"name": "sbx-usr-7xk9",
"hoody_kit": true
}
HOODY API 响应
201 Created{
"id": "ctr_a9f3e2b1c7d04500",
"status": "provisioning",
"name": "sbx-usr-7xk9",
"url": "https://proj-ctr_a9f3...containers.hoody.com"
}
用户注册时发生的就是这件事。
use-cases / one-sandbox-per-customer / trigger
那一次 API 调用开通了什么
每次 POST 到 /api/v1/projects/{id}/containers，都会启动一个隔离环境。一次调用、一个租户、一个 URL，直接交回你的应用。
01 · WEBHOOK
注册即触发 container POST
你的 Stripe（或任意计费）webhook 命中一个 Hoody Exec 脚本。没有 Express，没有服务器配置——只是 scripts/ 里的一个文件。
02 · ISOLATION
Linux 命名空间，不是 WHERE 子句
新容器有自己的文件系统、自己的 SQLite、自己的 ramdisk。租户 A 根本看不到租户 B 的数据。
03 · URL
一个回到你应用的专属 URL
响应里包含一个 container URL。你的应用在同一个部署窗口内就把用户重定向进他们自己的沙箱。
04 · FIREWALL
按租户克隆的网络规则
容器的网络和防火墙规则从你的模板复制而来。每个新租户都从同一条安全基线起步。
05 · IDLE
闲置时零成本
停掉容器就不花一分钱。BTRFS 只保留相对模板的增量——即便规模再大，磁盘依然便宜。
06 · OFFBOARD
DELETE container = 遗忘租户
一次 DELETE 调用就移除容器和他们的全部数据。GDPR 退出流程不是一段脚本，而是一次 HTTP 调用。
整套流程就是一个 webhook 处理器。不用 Kubernetes operator、不用 namespace YAML、不用集群管理员。三次 HTTP 调用：webhook 进、容器出、URL 给用户。
use-cases / one-sandbox-per-customer / compare
共享多租户 vs. 每客户一个容器
传统选择要么是每张表上一个列，要么是你养不起的 VM 机群。Hoody 是第三种形状：容器便宜到能给每个客户都发一个。
维度
共享数据库 · TENANT_ID
HOODY · 每客户一个容器
- 隔离WHERE tenant_id = $1 — 你只能祈祷每条查询都记得加Linux namespace。租户 A 在文件系统层面就看不见租户 B。
- 数据泄露面每次 JOIN、每个 ORM 钩子、每个报表脚本容器边界。一个工件要审计，而不是 200 个查询点。
- 按租户配置feature flags 表，脆弱，在 dev 里只测了一半改一个容器的环境。其他 399 个保持不变。
- 吵闹的邻居一个重客户能锁住共享数据库容器 CPU 和磁盘配额；一个租户的负载留在自己的盒子里。
- 下线DELETE … WHERE tenant_id … 加上你忘了的另外 12 张表DELETE 这个容器。他们的数据跟着走。GDPR 是一次 HTTP 调用。
- 空闲成本客户睡着时每一行也在烧存储停掉容器——零 CPU、零 RAM。BTRFS 只保留增量。
- 无 tenant_id 列
- 无行级安全审计
- 无 namespace YAML
- 删除 = 遗忘
use-cases / one-sandbox-per-customer / punchline
多租户不再是架构问题。它变成了一条 `cp` 命令。
上线
POST /containers/$TEMPLATE/copy下线
DELETE /containers/$CID按租户调整
PATCH /containers/$CID [ env_vars ]- namespace 级隔离
- GDPR 删除一次调用搞定
- 每账户一个容器
use-cases / one-sandbox-per-customer / replaces
这取代了什么
按租户隔离历来要么意味着一条聪明的 WHERE 子句，要么意味着一个昂贵的集群。每客户一个容器替换了那些常见变通：
- 共享多租户(tenant_id 列)一条坏查询暴露所有人
- 自定义租户隔离中间件你永远要维护的手写守卫
- Postgres 行级安全策略正确答案，但每张表审计昂贵
- 每租户一个 Kubernetes namespace集群级开销，需要运维团队
- 按客户的 schema / 数据库迁移倍增，连接池痛苦
- 共享表里的 Stripe 计量行用量追踪粘在同一个共享盒子上
use-cases / one-sandbox-per-customer / cta
空闲客户不花钱。活跃客户按需扩容。在你有数百付费用户之前，整个东西跑在 49 美元的裸金属上。
use-cases / one-sandbox-per-customer / related