跳转到内容
类型解锁阶段船队难度中等工作多租户 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 子句。

阅读副本文档
use-cases / one-sandbox-per-customer / trigger

What that single API call provisions

Each POST to /api/v1/projects/{id}/containers spins up an isolated environment. One call, one tenant, one URL handed back to your app.

01 · WEBHOOK

Signup triggers the container POST

Your Stripe (or any billing) webhook hits a Hoody Exec script. No Express, no server config — just a file in scripts/.

02 · ISOLATION

Linux namespaces, not a WHERE clause

The new container has its own filesystem, its own SQLite, its own ramdisk. Tenant A literally cannot see tenant B's data.

03 · URL

A unique URL back to your app

The response includes a container URL. Your app redirects the user into their own sandbox in the same deploy window.

04 · FIREWALL

Per-tenant network rules cloned

Container network and firewall rules are copied from your template. Every new tenant starts from the same security baseline.

05 · IDLE

Zero cost when idle

Stop the container and it costs nothing. BTRFS keeps only the delta from your template — disk stays cheap even at scale.

06 · OFFBOARD

DELETE container = forget tenant

One DELETE call removes the container and all their data. GDPR offboarding is not a script, it is a single HTTP call.

The whole flow is one webhook handler. No Kubernetes operator, no namespace YAML, no cluster admin. Three HTTP calls: webhook in, container out, URL to user.

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

阅读其他内容