ستون حاوية على خادم واحد
صندوق معدن عارٍ واحد يشغّل عشرات إلى مئات حاويات Hoody. تجعل KSM وإزالة التكرار في BTRFS التكلفة الهامشية قريبة من الصفر.
توقف عن نثر tenant_id عبر كل جدول. عندما يسجل عميل، ينسخ سيناريو exec حاوية عميل جديدة ويُسلّمهم عنوان URL خاص بهم، نظام ملفات خاص بهم، SQLite خاص بهم. العزلة هي نظام التشغيل بينهم، وليس شرط WHERE.
حين يسجّل مستخدم، هذا ما يحدث.
كل طلب POST إلى /api/v1/projects/{id}/containers يُشغّل بيئة معزولة. نداء واحد، مستأجر واحد، URL واحد يُعاد إلى تطبيقك.
webhook الخاص بـ Stripe (أو أي نظام فوترة) يستدعي script في Hoody Exec. لا Express، لا إعداد خادم — مجرد ملف في scripts/.
الـ container الجديد له filesystem خاص به، وSQLite خاص، وramdisk خاص. المستأجر A لا يمكنه حرفياً رؤية بيانات المستأجر B.
تتضمن الاستجابة URL للـ container. يعيد تطبيقك توجيه المستخدم إلى sandbox الخاص به ضمن نفس نافذة الـ deploy.
تُنسخ قواعد شبكة الـ container والـ firewall من القالب الخاص بك. كل مستأجر جديد يبدأ من نفس الأساس الأمني.
أوقف الـ container ولن يكلّفك شيئاً. يحتفظ BTRFS بالـ delta فقط من قالبك — تبقى تكلفة القرص منخفضة حتى مع التوسّع.
استدعاء DELETE واحد يزيل الـ container وكل بياناته. حذف بيانات المستخدم وفق GDPR ليس script، بل استدعاء HTTP واحد.
التدفق كله معالج webhook واحد. لا مشغل Kubernetes، لا namespace YAML، لا مسؤول cluster. ثلاثة استدعاءات HTTP: webhook داخل، حاوية خارج، URL إلى المستخدم.
الخيارات التقليديّة كانت إمّا عمود على كل جدول أو أسطول VMs لا تستطيع تحمّل تكلفته. Hoody شكل ثالث: حاويات رخيصة بما يكفي لإعطاء واحدة لكل عميل.
تعدّد المستأجرين يتوقّف عن كونه مشكلة معماريّة. يصبح أمر `cp`.
POST /containers/$TEMPLATE/copyDELETE /containers/$CIDPATCH /containers/$CID [ env_vars ]العزل لكل مستأجر يعني تاريخياً إمّا جملة WHERE ذكيّة أو عنقوداً مكلفاً. الحاوية لكل عميل تُزيح الحلول المعتادة:
العملاء الخاملون لا يُكلّفون شيئاً. النشطون يتوسّعون عند الطلب. كل ذلك يعمل على معدن عارٍ بـ 49 دولاراً حتى يصبح لديك مئات المستخدمين الدافعين.