1 つのサーバーで 60 のコンテナ
1 台のベアメタルで、数十から数百の 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
顧客ごとに 1 つのサンドボックス。自動的に。
すべてのテーブルに tenant_id を散在させるのをやめてください。顧客がサインアップすると、実行スクリプトが新規顧客コンテナをコピーし、顧客に独自の 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 1 本がプロビジョニングするもの
/api/v1/projects/{id}/containers への POST ごとに、分離された環境が起動します。1 回の呼び出しで、1 つのテナント、1 つの URL がアプリに返されます。
01 · WEBHOOK
サインアップがコンテナの POST をトリガー
Stripe(あるいは任意の課金サービス)の webhook が Hoody Exec のスクリプトを叩きます。Express も、サーバー設定も不要 ── scripts/ にファイルを置くだけです。
02 · ISOLATION
WHERE 句ではなく、Linux ネームスペース
新しいコンテナは独自のファイルシステム、独自の SQLite、独自の ramdisk を持ちます。テナント A はテナント B のデータを文字どおり見ることができません。
03 · URL
アプリへ戻る固有の URL
レスポンスにはコンテナの URL が含まれます。アプリは同じデプロイのタイミングで、ユーザーを専用のサンドボックスへリダイレクトします。
04 · FIREWALL
テナントごとのネットワークルールを複製
コンテナのネットワークとファイアウォールのルールはテンプレートからコピーされます。新しいテナントはすべて、同じセキュリティ基準から始まります。
05 · IDLE
アイドル時はコストゼロ
コンテナを停止すれば、コストはかかりません。BTRFS はテンプレートとの差分だけを保持します ── スケールしてもディスクは安いままです。
06 · OFFBOARD
DELETE container = テナントを消去
1 回の DELETE 呼び出しで、コンテナとそのすべてのデータが削除されます。GDPR のオフボーディングはスクリプトではなく、1 回の HTTP 呼び出しです。
フロー全体が Webhook ハンドラ 1 つ。Kubernetes オペレータも、namespace の YAML も、クラスタ管理者も不要。HTTP 3 本——Webhook を受け、コンテナを返し、URL をユーザーに渡すだけです。
use-cases / one-sandbox-per-customer / compare
共有マルチテナンシー vs 顧客ごとのコンテナ
従来の選択肢は、すべてのテーブルにカラムを置くか、買えない VM フリートでした。Hoody は 3 つ目の形: すべての顧客に 1 つずつ与えるのに十分安いコンテナです。
項目
共有 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` コマンドになります。
オンボード
POST /containers/$TEMPLATE/copyオフボード
DELETE /containers/$CIDテナント別の調整
PATCH /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 のベアメタルで動きます。
use-cases / one-sandbox-per-customer / related