コンテンツにスキップ
use-cases / one-sandbox-per-customer / hero
コンテナ · マルチテナント SaaS

顧客ごとに 1 つのサンドボックス。自動的に。

すべてのテーブルに tenant_id を散在させるのをやめてください。顧客がサインアップすると、実行スクリプトが新規顧客コンテナをコピーし、顧客に独自の 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 は 3 つ目の形: すべての顧客に 1 つずつ与えるのに十分安いコンテナです。

DIMENSION
共有 DB · TENANT_ID
HOODY · 顧客ごとのコンテナ
  • ISOLATIONWHERE tenant_id = $1 — そしてすべてのクエリが覚えていることを願うLinux namespaces。テナント A はテナント B のファイルシステムを文字通り見ることができません。
  • DATA LEAK SURFACEすべての JOIN、すべての ORM フック、すべてのレポートスクリプトコンテナ境界。監査するのは 200 のクエリサイトではなく、1 つのアーティファクトです。
  • PER-TENANT CONFIG機能フラグテーブル、脆弱、開発で半分テスト1 つのコンテナの環境を編集。他の 399 は変わりません。
  • NOISY NEIGHBOR1 人の重い顧客が共有 DB をロックできるコンテナの CPU とディスククォータ。1 つのテナントの負荷は彼らのボックスに留まる。
  • OFFBOARDINGDELETE … WHERE tenant_id … プラスあなたが忘れた他の 12 テーブルコンテナを DELETE。彼らのデータも一緒に消える。GDPR は 1 回の HTTP コール。
  • COST AT IDLE顧客が眠っているときも各行がストレージをコストコンテナを停止 — CPU 0、RAM 0。BTRFS は差分だけを保持します。
  • tenant_id カラムなし
  • 行レベルセキュリティ監査なし
  • namespace YAML なし
  • 削除 = 忘れる
use-cases / one-sandbox-per-customer / punchline

マルチテナンシーはアーキテクチャ問題でなくなります。`cp` コマンドになります。

ONBOARDPOST /containers/$TEMPLATE/copy
OFFBOARDDELETE /containers/$CID
PER-TENANT TWEAKPATCH /containers/$CID [ env_vars ]
  • namespace 級の隔離
  • GDPR 削除を 1 回のコールで
  • アカウントごとに 1 コンテナ
use-cases / one-sandbox-per-customer / replaces

これが置き換えるもの

テナントごとの隔離は歴史的に、巧妙な WHERE 句か高価なクラスターを意味しました。顧客ごとのコンテナは通常の回避策を置き換えます:

  • 共有マルチテナンシー (tenant_id カラム)1 つの悪いクエリが全員を露出させる
  • カスタムテナント隔離ミドルウェア永遠にメンテする手作りのガード
  • Postgres 行レベルセキュリティポリシー正しい答えだが、テーブルごとの監査がコストがかかる
  • テナントごとの Kubernetes namespaceクラスターレベルのオーバーヘッド、ops チームが必要
  • 顧客ごとのスキーマ / データベースマイグレーションの倍数、コネクションプールの痛み
  • 共有テーブル内の Stripe メータリング行同じ共有ボックスに張り付けられた使用量追跡
use-cases / one-sandbox-per-customer / cta

アイドル顧客はコストがかかりません。アクティブな顧客はオンデマンドでスケール。全体は数百の支払いユーザーになるまで $49 のベアメタルで動きます。

コンテナコピー docs を読む
use-cases / one-sandbox-per-customer / related

他のユースケースを読む