
ستون حاوية على خادم واحد
صندوق معادن عارية واحد يشغل عشرات إلى مئات حاويات Hoody. يجعل KSM و BTRFS dedup التكلفة الإضافية قريبة من الصفر.
توقف عن نثر tenant_id عبر كل جدول. عندما يسجل عميل، ينسخ سيناريو exec حاوية عميل جديدة ويُسلّمهم عنوان 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.
الخيارات التقليديّة كانت إمّا عمود على كل جدول أو أسطول VMs لا تستطيع تحمّل تكلفته. Hoody شكل ثالث: حاويات رخيصة بما يكفي لإعطاء واحدة لكل عميل.
تعدّد المستأجرين يتوقّف عن كونه مشكلة معماريّة. يصبح أمر `cp`.
POST /containers/$TEMPLATE/copyDELETE /containers/$CIDPATCH /containers/$CID [ env_vars ]العزل لكل مستأجر يعني تاريخياً إمّا جملة WHERE ذكيّة أو عنقوداً مكلفاً. الحاوية لكل عميل تُزيح الحلول المعتادة:
العملاء الخاملون لا يُكلّفون شيئاً. النشطون يتوسّعون عند الطلب. كل ذلك يعمل على معدن عارٍ بـ 49 دولاراً حتى يصبح لديك مئات المستخدمين الدافعين.