Vercel pricing: متى يخفّض Basic تكلفة البناء؟

في Vercel pricing، لا ينبغي أن تُحسم المفاضلة لمجرد أن دقيقة البناء أرخص. ففي 3 سبتمبر 2026، أتاحت Vercel لفرق Pro وEnterprise خيار Basic جديدًا بمواصفات 2 vCPUs وذاكرة 8 GB، وبسعر $0.007 لدقيقة البناء. ولا يخفض هذا الخيار الفاتورة إلا عندما تكون تكلفة كل عملية بناء مكتملة أقل من تكلفتها على Elastic بعد احتساب مدة التشغيل، والتقريب، وحالات الفشل، ووقت الانتظار في الطابور.

Vercel pricing: ما الذي تغيّر في أجهزة البناء؟

جهاز البناء هو حاسوب مؤقت تستخدمه Vercel لتثبيت التبعيات، وتجميع التطبيق، وتجهيز عملية النشر. وأصبح للمشاريع المدفوعة الآن خيار ثابت أصغر: أجهزة بناء Basic متاحة ضمن خطتي Pro وEnterprise، ولم تعد مقتصرة على Hobby.

يأتي Basic مع 2 vCPUs وذاكرة 8 GB وقرص بسعة 32 GB. أما Elastic، فيمكنه تخصيص ما بين 4 و30 vCPUs وذاكرة بين 8 و60 GB بحسب عبء عمل المشروع. وتظل المشاريع المدفوعة الجديدة مضبوطة افتراضيًا على Elastic.

هذا خيار متاح، وليس إعدادًا افتراضيًا مدفوعًا جديدًا. فالمشاريع المدفوعة الجديدة ما زالت تبدأ على Elastic، ويمكن للمالك اختيار Basic من إعدادات الفريق أو المشروع. أما مشاريع Hobby، فتحتفظ بالجهاز المضمّن نفسه ذي 2 vCPUs، والذي أصبح اسمه الآن Basic.

يركز هذا المقال على قرار جهاز البناء وحده. أما رسوم الخطة، ورصيد الاستخدام، والمقاعد، وحركة البيانات، والوظائف، والتخزين، والإضافات، فما زالت مشمولة في الشرح الكامل لأسعار Vercel.

الرقم الأهم هو تكلفة كل عملية بناء مكتملة

ينطلق Basic وElastic من سعر المعالج نفسه: $0.0035 لكل دقيقة CPU. غير أن الفاتورتين تختلفان لأن Basic يستخدم دائمًا 2 vCPUs، بينما يخصص Elastic ما بين 4 و30.

تقرّب Vercel مدة كل عملية بناء إلى الدقيقة التالية. ومن ثم يمكن العمل بالمعادلتين التاليتين:

• Basic: دقائق البناء بعد التقريب لأعلى × $0.007.
• Elastic: دقائق البناء بعد التقريب لأعلى × عدد vCPUs المخصصة × $0.0035.

عند أصغر تخصيص لـ Elastic، أي 4 vCPUs، تبدأ التكلفة من $0.014 لكل دقيقة بناء مفوترة. وتبلغ تكلفة Basic نصف ذلك لكل دقيقة مفوترة. لذلك يتعادل Basic عندما يستغرق بالضبط ضعف عدد الدقائق المفوترة، ويكون أوفر عندما يستغرق أقل من الضعف.

تتغير هذه القاعدة إذا خصص Elastic أكثر من 4 vCPUs. كما تتغير عند كل حد فاصل بين الدقائق، لأن Vercel تقرّب مدة كل عملية بناء على حدة، لا الإجمالي الشهري. ولهذا يجب أن تعتمد الفاتورة على المدة الفعلية والجهاز المخصص، لا على تخمين مستند إلى جدول الأسعار.

التوفير البالغ $7 حقيقي ضمن هذا المثال، لكنه قد لا يكون ذا قيمة. فإذا كانت كل معاينة تعطل مطورًا أو مراجعًا أو وكيل برمجة، فقد تكلّف حلقة الملاحظات الأبطأ أكثر مما توفره الفاتورة. أما إذا كانت عمليات البناء تعمل في الخلفية وظل الطابور خاليًا، فيحقق Basic تكلفة أفضل للوحدة.

أدخل حالات الفشل في البسط أيضًا. مقياس التشغيل الصحيح هو إجمالي رسوم البناء مقسومًا على عمليات النشر الناجحة. فقد يخسر جهاز رخيص في الدقيقة إذا تسبب في إعادة المحاولات، لأن النتيجة التي تدفع مقابلها هي ما يهم فعلًا.

وقت الانتظار في الطابور تكلفة على سير العمل

تعتمد معادلة الفوترة المنشورة من Vercel على مدة البناء وعدد وحدات المعالجة. وهي لا تضيف وقت الانتظار في الطابور كبند آخر، لكن فريقك سيشعر بهذا التأخير على أي حال.

عندما يكون التزامن عند الطلب متوقفًا، تتيح خطة Pro عددًا قدره 3 خانات متزامنة لعمليات النشر. وتنتظر عمليات البناء التي تتجاوز هذه الخانات النشطة. ومع التزامن عند الطلب، تذكر Vercel حدًا يصل إلى 500 عملية نشر متزامنة، وتفوتر دقائق البناء المستخدمة.

تشغل عملية البناء الأبطأ على Basic الخانة مدة أطول. وقد لا يهم ذلك مؤسسًا ينشر موقعًا صغيرًا بضع مرات يوميًا، لكنه قد يصبح مؤثرًا سريعًا عندما ينشئ وكيل برمجة عدة معاينات، أو تنشر وكالة مشاريع كثيرة لعملائها، أو يدفع فريق تحديثاته إلى عدة فروع في الوقت نفسه.

سجّل الزمنين معًا:

• مدة البناء تحدد رسوم الجهاز بعد التقريب.
• وقت الانتظار في الطابور مضافًا إليه مدة البناء يحدد زمن الوصول إلى الملاحظات.

هنا تكمن المفاضلة كلها: حسّن الرقم الأول من دون أن تسمح للثاني بالإضرار بسير العمل.

من المناسب أن يختبر Basic؟

مؤسس منفرد لديه تطبيق صغير

يمكن لمؤسس SaaS منفرد نقل موقع تسويقي خفيف أو لوحة معلومات إلى Basic على مستوى المشروع، ثم مقارنة عملية البناء التمثيلية نفسها على Elastic. والفائدة هي خفض بند البناء المتكرر من دون تغيير بقية خطة Vercel.

لا يستحق الإبقاء على التغيير إلا إذا ظلت عملية البناء موثوقة، ولم يؤخر التشغيل الأبطأ الإصدارات إن حدث. أما المشروع الذي لا يُنشر إلا من حين إلى آخر، فقد يكون فرق التكلفة ضئيلًا إلى درجة لا تبرر الضبط اليدوي.

وكالة تدير مشاريع متنوعة لعملائها

لا ينبغي لوكالة العملاء اتخاذ قرار واحد بشأن الجهاز لكل الحسابات. اضبط مواقع الهبوط الصغيرة ومشاريع المحتوى على Basic، مشروعًا بعد آخر. واترك المتاجر الأكبر، والمستودعات الأحادية، والتطبيقات كثيفة التبعيات على Elastic إلى أن تثبت قياساتها الخاصة خلاف ذلك.

الفائدة هنا هي هامش ربح أوضح لكل مشروع؛ فلم يعد على عميل قليل الاحتياجات أن يرث جهاز البناء نفسه المخصص لأثقل تطبيقات الوكالة.

قائد هندسي يشغّل وكلاء برمجة

يغيّر التطوير المعتمد على الوكلاء جانب الحجم في المعادلة. فزيادة عمليات commit المؤتمتة قد تعني مزيدًا من عمليات بناء المعاينات، ليتكرر فرق صغير في كل عملية مرات أكثر.

على القائد الهندسي قياس دفعة تمثيلية، لا عملية نشر هادئة واحدة. فإذا خفّض Basic تكلفة كل عملية بناء مكتملة، لكن التشغيل الأطول ملأ 3 خانات متاحة وأنشأ طابورًا، يكون الجهاز الأرخص قد نقل التكلفة من الفاتورة إلى زمن الإنجاز.

مالك منصة Enterprise

يتوفر Basic لعملاء Enterprise، لكن أحد بنود العقد قد يمنع تغيير الإعداد ذاتيًا. عملاء Enterprise الذين فُعّلت لهم أجهزة Enhanced بموجب العقد يستخدمون تلك الأجهزة افتراضيًا، وعليهم التواصل مع مدير الحساب لتحديث تفضيلات الأجهزة.

كيف تغيّر إعداد مشروع واحد وتختبره؟

ابدأ بتغيير على مستوى المشروع. فهذا يعزل التجربة عن التطبيقات الأخرى، ويوفر مسارًا واضحًا للتراجع من الإعداد نفسه.

1. 1

   سجّل خط الأساس على Elastic

   افتح Build Diagnostics ضمن Vercel Observability، واختر عملية نشر تمثيلية. سجّل مدة البناء، والجهاز المخصص، والاستخدام المفوتر، ووقت الانتظار في الطابور، وما إذا كان النشر قد اكتمل. وحافظ على تقارب حالة الذاكرة المؤقتة وإصدار الشفرة عند تشغيل Basic.

2. 2

   اختر Basic للمشروع

   افتح المشروع في Vercel، ثم انتقل إلى Settings، ثم Build and Deployment، ثم Build Machine. اختر Basic واحفظ التغيير. توثّق Vercel الخيار نفسه على مستوى الفريق، لكن إعداد المشروع هو الأكثر أمانًا للاختبار الأول. وتحتاج إلى صلاحية المالك للوصول إلى إعدادات جهاز البناء.

3. 3

   استخدم مسار CLI الموثّق

   يستطيع Vercel CLI بالإصدار 59.6.0 أو أحدث تنفيذ التغيير على المشروع بهذا الأمر:

   vc project update --build-machine basic

   من السهل تشغيل إصدار أقدم من CLI ثم افتراض أن خيار الجهاز غير متاح. تحقّق من الإصدار قبل اعتبار فشل الأمر قيدًا في الخطة.

4. 4

   شغّل عبء العمل نفسه

   ابنِ المراجعة التمثيلية نفسها في ظل حالة متقاربة للذاكرة المؤقتة. وسجّل الحقول نفسها: المدة، والجهاز، والاستخدام المفوتر، ووقت الانتظار في الطابور، والاكتمال. وفي العمل المعتمد على الوكلاء، أدرج دفعة طبيعية حتى تتاح للطابور فرصة الظهور.

5. 5

   اتخذ القرار بناءً على النتائج

   احسب إجمالي تكلفة البناء الشهرية، ثم اقسمه على عمليات النشر الناجحة. أبقِ Basic عندما تنخفض تكلفة الوحدة ويظل زمن الإنجاز الإجمالي ضمن هدف الفريق. وأعد المشروع إلى Elastic من إعدادات Build Machine إذا تراجعت السرعة أو الذاكرة أو الموثوقية بما يكفي لمحو التوفير.

الحدود الفعلية للخيار

Basic جهاز أصغر، وليس نسخة أعلى كفاءة من Elastic. فسقف ذاكرته ثابت عند 8 GB، بينما يمكن لـ Elastic التوسع حتى 60 GB و30 vCPUs عندما يحتاج عبء العمل إلى ذلك.

قد يلتهم التقريب وفرًا صغيرًا أيضًا؛ فبضع ثوانٍ بعد حد الدقيقة تخلق دقيقة مفوترة كاملة أخرى. قارن الاستخدام المفوتر الذي تعرضه Vercel، لا حساب ساعة إيقاف قُرّب لصالحك.

يواصل Elastic أيضًا التكيّف مع تغير المشروع، بينما تظل موارد Basic ثابتة. وقد يصبح اختيار الجهاز المناسب لتطبيق اليوم الصغير اختيارًا خاطئًا بعد نمو التبعيات أو المسارات أو الأصول المولّدة.

من يتحرك الآن، ومن ينتظر، ومن يتجاهل التغيير؟

• تحرّك هذا الأسبوع إذا كنت تشغّل مشروعًا ضمن Pro أو Enterprise بعمليات بناء مستقرة وقليلة الاحتياجات، وبحجم بناء يكفي ليصبح الفرق المتكرر لكل عملية مؤثرًا.
• انتظر إذا كان المشروع محدودًا بقدرة CPU، أو كثيف الذاكرة، أو قريبًا من حد 45 دقيقة، أو يتأثر أصلًا بطوابير المعاينات. ابدأ بتسجيل خط أساس واضح على Elastic.
• تجاهل تغيير السعر إذا كنت على Hobby. فقد أُعيدت تسمية جهازك المضمّن ذي 2 vCPUs إلى Basic، لكن الجهاز وطريقة احتسابه ضمن الخطة لم يتغيرا.
• راجع العقد أولًا إذا كانت أجهزة Enhanced مفعّلة ضمن Enterprise؛ فقد يكون تغيير الإعداد من مسؤولية مدير الحساب.

خطوة يوم الاثنين

اختر مشروعًا صغيرًا تمثيليًا يوم الاثنين. شغّل عملية البناء نفسها على Elastic وBasic، ثم سجّل المدة، والاستخدام المفوتر، ووحدات CPU المخصصة، ووقت الانتظار في الطابور، والاكتمال. احتفظ بالخيار الذي يخفض تكلفة كل عملية بناء مكتملة من دون تجاوز هدف الفريق لزمن الإنجاز.

اشترك في النشرة البريدية لتصلك شروح مبسطة عن تغييرات المنصات التي تؤثر في الميزانية أو سير العمل.