
ستون حاوية على خادم واحد
صندوق معادن عارية واحد يشغل عشرات إلى مئات حاويات Hoody. يجعل KSM و BTRFS dedup التكلفة الإضافية قريبة من الصفر.
التقط لقطة لحاوية الـ staging مرّة. كل PR جديد ينسخ اللقطة إلى حاويته الخاصة برابطه الخاص. الحاوية تستيقظ حين يفتح المراجع الرابط، تغفو حين لا أحد ينظر، وتُدمَّر بسطر cron واحد حين يُغلق الـ PR. ستّون فرعاً، ستّون رابطاً، وفاتورة ثابتة.
الرابط على اليمين هو بيئة المعاينة — نقرة واحدة، حاوية حقيقية، قاعدة بيانات حقيقية
ثلاثة استدعاءات. سطر cron واحد. خط أنابيب CI الذي تملكه أصلاً يُشغّلها بالترتيب الذي ستكتبه بنفسك لو اضطُررت.
اختر الحاوية التي تُشغّل حزمة staging — التطبيق، قاعدة البيانات، الطوابير، البيانات الأوّلية. أرسل POST لقطة، سمّها staging-base. الملفات والعمليات والذاكرة تُلتقط. اللقطة نقطة بداية قابلة للتفريع، ليست tarball — النسخ تتقاسم صفحاتها بدلاً من نسخها.
خط CI يستقبل webhook دفع GitHub ويُرسل POST إلى API الحاويات مع source_snapshot=staging-base. حاوية جديدة تُقلع في ثوانٍ بقاعدة بيانات مزروعة وفرع الـ PR مفحوصاً. الرابط يعود كفحص حالة.
إدخال cron مدّته 5 دقائق يمشي على الـ PRs المدمجة ويحذف حاوياتها — أو webhook الدمج يفعل ذلك مباشرة. دلتا قرص الحاوية تُستعاد، الرابط يتحرّر، وفتحة الحاوية تعود إلى المجمّع للـ PR التالي.
الخطوة 02 تستغرق وقتاً يقارب yarn install. الخطوة 03 استدعاء HTTP واحد. لا شيء آخر يحتاج أن يعرف أن حاوية الـ PR كانت موجودة.
ثلاث نقاط نهاية حقيقية من Hoody Containers و Snapshots APIs. أسقطها في خطوة GitHub Actions التي تملكها أصلاً.
/api/v1/containers/[staging_id]/snapshotsBody: [ "alias": "staging-base", "expiry": 30 ]. يُعيد اسم لقطة مثل snap-20260501-093000. شغّل هذا مرّة لكل نشر فرع رئيسي — كل نسخة PR تنحدر من أحدث التقاط.
/api/v1/projects/[project_id]/containersالـ body يختار server_id و container_image؛ مرّر environment_vars لحقن رقم الـ PR وفرعه واسم قاعدة البيانات. الحاوية تُقلع من نظام ملفات لقطتك، لا من الصفر — التخزين المؤقّت والبيانات الأوّلية موجودة بالفعل.
/api/v1/containers/[pr_container_id]استدعاء واحد. الحاوية تتوقّف ودلتا قرصها تُستعاد؛ لا شيء آخر يحتاج إلى تفكيك. إدخال cron بإيقاع 5 دقائق يتعامل مع الـ PRs التي أُغلقت بينما لا ينظر أحد.
نقاط نهاية من Hoody Container Snapshots API و Containers API. انتهاء صلاحية اللقطة بالأيام؛ إنشاء الحاوية يقبل environment_vars و ssh_public_key و autostart و ramdisk و realm_ids — راجع التوثيق لمخطّط الطلب الكامل.
الحساب يتوقّف عن تقييد سلوك المراجع. ثلاث عادات كانت باهظة جداً عند 40 دولاراً للمعاينة تظهر من تلقاء نفسها بمجرد أن تصبح التكلفة لكل PR خطأ تقريب.
لا أحد يفحص الفرع محلّياً ليُعيد إنتاج الخطأ. يفتحون الرابط، يضغطون الشيء المعطوب، يتركون لقطة شاشة في الـ PR. حلقة المراجعة تعمل على ما يفعله الكود فعلاً، لا ما يُلمّح إليه الـ diff.
خمسون PR لا يُراجعها أحد حالياً تكلّف صفر CPU وصفر RAM. تتقاسم صفحات لقطة staging-base على القرص، حتى بصمتها معظمها دلتا. الفاتورة محدودة بالصندوق، لا بعدد الـ PRs المفتوحة.
مصمّمك، مهندس الدعم، قائد المبيعات — أيّ شخص لديه الرابط يستطيع التلاعب بالـ PR. لم يكونوا أبداً سيُجرون git checkout للفرع. مع رابط، ينظرون فعلاً إلى التغيير قبل أن يصل.
فريق يفتح 30 PR شهرياً. الرقم قبل هو فاتورة بيئة المعاينة المعيارية. الرقم بعد هو صندوق Hoody معدن عارٍ واحد يتّسع للثلاثين كلّها بالإضافة إلى staging.
$480/mo
تسعير Pro لكل مقعد بالإضافة إلى دقائق البناء بالإضافة إلى عرض النطاق على فريق من 6 مهندسين يُشغّل 30 نشر PR شهرياً. معظم الفرق يُقيّدون المعاينات بالعشرة النشطة لأن العشرين التالية تكلّف مالاً حقيقياً.
$30/mo
خادم متوسّط واحد من سوق Hoody يُشغّل staging بالإضافة إلى 30 نسخة PR بالإضافة إلى تخزين CI المؤقّت. أضف الستّين التالية بـ 0 دولاراً — copy-on-write يعني أن كل نسخة هي صفحات اللقطة بالإضافة إلى دلتا.
تسعير قائمة Vercel Pro هو 20 دولاراً/مقعد/شهرياً بالإضافة إلى الاستخدام؛ تسعير Hoody معدن عارٍ مدفوع بالسوق ويبدأ تحت 20 دولاراً شهرياً للفئات الأساسية. كثافة الحاويات تعتمد على عبء العمل — تطبيقات الويب النموذجية تتراكم بعشرات إلى مئات؛ الخدمات الكبيرة ذات الحالة تحتاج هامشاً أكبر.
بيئات المعاينة تتوقّف عن أن تكون بنداً في الميزانية. تصبح الافتراض.
منتجات بيئات المعاينة تُسعّر لكل مقعد، لكل دقيقة، أو لكل حاوية تعمل. Hoody يُسعّر لكل خادم — المعاينة الثلاثون تكلّف مثل الأولى.
التقط لقطة مرّة. انسخ لكل PR. دمّر عند الدمج. المراجع لا يشعر بالخياطة أبداً.