انتقل إلى المحتوى
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

تعدّد مستأجرين مشترك مقابل حاوية لكل عميل

الخيارات التقليديّة كانت إمّا عمود على كل جدول أو أسطول VMs لا تستطيع تحمّل تكلفته. Hoody شكل ثالث: حاويات رخيصة بما يكفي لإعطاء واحدة لكل عميل.

البُعد
قاعدة بيانات مشتركة · TENANT_ID
HOODY · حاوية لكل عميل
  • العزلWHERE tenant_id = $1 — وتأمل أنّ كل استعلام يتذكّرأسماء فضائيّة في Linux. المستأجر A لا يستطيع حرفياً رؤية نظام ملفّات المستأجر B.
  • سطح تسرّب البياناتكل JOIN، كل ربط ORM، كل نصّ تقاريرحدّ الحاوية. قطعة واحدة لتدقيقها، لا 200 موقع استعلام.
  • إعداد لكل مستأجرجدول علامات ميزات، هشّ، نصف مُختبَر في devعدّل بيئة حاوية واحدة. الـ 399 الأخرى لا تتغيّر.
  • الجار المُزعجعميل ثقيل واحد يستطيع قفل قاعدة البيانات المشتركةحصص CPU وقرص للحاوية؛ حمل مستأجر واحد يبقى في صندوقه.
  • إنهاء الاشتراكDELETE … WHERE tenant_id … زائد 12 جدولاً نسيتهااحذف الحاوية. بياناتهم تذهب معها. GDPR استدعاء HTTP واحد.
  • التكلفة عند الخمولكل صفّ يُكلّف تخزيناً حتى حين العميل نائمأوقف الحاوية — صفر CPU، صفر RAM. BTRFS يُبقي الفرق فقط.
  • لا أعمدة tenant_id
  • لا تدقيقات أمن مستوى الصفّ
  • لا YAML أسماء فضائيّة
  • احذف = انسَ
use-cases / one-sandbox-per-customer / punchline

تعدّد المستأجرين يتوقّف عن كونه مشكلة معماريّة. يصبح أمر `cp`.

تسجيلPOST /containers/$TEMPLATE/copy
إنهاءDELETE /containers/$CID
تخصيص لكل مستأجرPATCH /containers/$CID [ env_vars ]
  • عزل بدرجة الأسماء الفضائيّة
  • حذف GDPR في استدعاء واحد
  • حاوية واحدة لكل حساب
use-cases / one-sandbox-per-customer / replaces

ما يستبدله هذا

العزل لكل مستأجر يعني تاريخياً إمّا جملة WHERE ذكيّة أو عنقوداً مكلفاً. الحاوية لكل عميل تُزيح الحلول المعتادة:

  • تعدّد مستأجرين مشترك (عمود tenant_id)استعلام سيّئ واحد يكشف الجميع
  • وسيط عزل مستأجرين مُخصّصحارس مكتوب يدوياً تصونه إلى الأبد
  • سياسات أمن مستوى الصفّ في Postgresالإجابة الصحيحة، مكلفة لتدقيقها لكل جدول
  • اسم فضاء Kubernetes لكل مستأجرعبء على مستوى العنقود، فريق ops مطلوب
  • مخطّطات / قواعد بيانات لكل عميلمضاعف هجرة، ألم مجمّع اتّصالات
  • صفوف قياس Stripe في جدول مشتركتتبّع استخدام مُلصَق بنفس الصندوق المشترك
use-cases / one-sandbox-per-customer / cta

العملاء الخاملون لا يُكلّفون شيئاً. النشطون يتوسّعون عند الطلب. كل ذلك يعمل على معدن عارٍ بـ 49 دولاراً حتى يصبح لديك مئات المستخدمين الدافعين.

اقرأ توثيق نسخ الحاوية
use-cases / one-sandbox-per-customer / related

اقرأ الآخرين