
1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
すべてのテーブルに tenant_id を散在させるのをやめてください。顧客がサインアップすると、実行スクリプトが新規顧客コンテナをコピーし、顧客に独自の URL、独自のファイルシステム、独自の SQLite を提供します。分離はテーブルの WHERE 句ではなく、その間にあるオペレーティングシステムです。
When a user signs up, this is what happens.
Each POST to /api/v1/projects/{id}/containers spins up an isolated environment. One call, one tenant, one URL handed back to your app.
Your Stripe (or any billing) webhook hits a Hoody Exec script. No Express, no server config — just a file in scripts/.
The new container has its own filesystem, its own SQLite, its own ramdisk. Tenant A literally cannot see tenant B's data.
The response includes a container URL. Your app redirects the user into their own sandbox in the same deploy window.
Container network and firewall rules are copied from your template. Every new tenant starts from the same security baseline.
Stop the container and it costs nothing. BTRFS keeps only the delta from your template — disk stays cheap even at scale.
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.
従来の選択肢は、すべてのテーブルにカラムを置くか、買えない VM フリートでした。Hoody は 3 つ目の形: すべての顧客に 1 つずつ与えるのに十分安いコンテナです。
マルチテナンシーはアーキテクチャ問題でなくなります。`cp` コマンドになります。
POST /containers/$TEMPLATE/copyDELETE /containers/$CIDPATCH /containers/$CID [ env_vars ]テナントごとの隔離は歴史的に、巧妙な WHERE 句か高価なクラスターを意味しました。顧客ごとのコンテナは通常の回避策を置き換えます:
アイドル顧客はコストがかかりません。アクティブな顧客はオンデマンドでスケール。全体は数百の支払いユーザーになるまで $49 のベアメタルで動きます。