تكلفة بناء Vercel: فعّل Turbo لنشر واحد عند الحاجة

في 17 سبتمبر 2026، أضافت Vercel طريقة أدق للتحكم في تكلفة بناء Vercel: يمكن الآن تفعيل Turbo لعملية نشر واحدة، بدل الالتزام به على مستوى المشروع كله. ادفع تكلفة أعلى للبناء العاجل، ثم دع عملية النشر التالية تعود إلى خيار آلة البناء المعتاد للمشروع.

لم تعد مضطرًا إلى تغيير إعداد المشروع

آلة البناء هي الحاسوب المؤقت الذي توفره Vercel للكود أثناء تثبيت التبعيات وتجميع التطبيق وتجهيز عملية النشر. وTurbo هو أكبر الخيارات ثابتة الموارد: 30 vCPUs و60 GB من الذاكرة و64 GB من مساحة القرص.

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

أما التجاوز الجديد، فيربط Turbo بعملية نشر واحدة من دون تعديل إعداد المشروع. إذا كان المشروع يستخدم Basic أو Standard أو Elastic عادةً، فستعود عملية النشر التالية إلى ذلك الخيار ما لم تضف تجاوزًا جديدًا.

وهنا تكمن الفائدة: ترتبط الزيادة في إنفاق البناء بالحاجة العاجلة، لا بكل commit.

تتوفر خيارات Turbo وEnhanced وElastic ضمن خطتي Pro وEnterprise. أما مشاريع Hobby فتستخدم Basic دائمًا، لذا فهذه ليست وسيلة لتسريع خطة Hobby. ولن تحقق فائدة أيضًا لمشروع يشغّل جميع عمليات النشر على Turbo أصلًا.

ثلاث طرق لتفعيل Turbo في عملية نشر واحدة

تعتمد الطريقة على الجهة التي تبدأ عملية النشر. وكل مسار من المسارات الثلاثة يطبّق التجاوز نفسه على عملية نشر واحدة.

1. 1

   استخدم علامة GitHub داخل commit

   إذا كانت عملية النشر تبدأ عبر تكامل Vercel مع GitHub، فأضف العلامة التالية كما هي تمامًا، مع مراعاة حالة الأحرف إلى نص رسالة commit:

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   تسري العلامة على عملية النشر الناتجة من ذلك commit وحده. وهي لا تعمل حاليًا عبر تكامل Vercel مع GitLab أو Bitbucket.

2. 2

   استخدم Vercel CLI

   شغّل الأمر التالي من مشروع مرتبط:

   vc deploy --turbo

   يتطلب هذا المسار Vercel CLI 59.20.0 أو إصدارًا أحدث. وإذا لم يتعرف سطر الأوامر على العلامة، فتحقق أولًا من أنك لا تستخدم إصدارًا أقدم.

3. 3

   اضبط حقل واجهة API للنشر

   عندما تنشئ خدمة إصدار داخلية عملية النشر عبر POST /v13/deployments، اضبط buildMachine على turbo في الطلب. هذا الحقل اختياري، ونطاقه عملية النشر وحدها؛ فهو لا يعيد كتابة إعدادات المشروع.

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

تكلفة بناء Vercel: محدودة لمرة، وباهظة إذا أصبحت عادة

تحتسب Vercel حاليًا استخدام البناء بسعر $0.0035 لكل دقيقة CPU. وبذلك تبدأ تكلفة دقيقة البناء المفوترة من $0.007 لخيار Basic، و$0.014 لخيار Standard عندما تكون خاضعة للفوترة، و$0.028 لخيار Enhanced، و$0.105 لخيار Turbo.

يُقرَّب زمن كل عملية بناء إلى أعلى حتى أقرب دقيقة قبل ضربه في عدد وحدات CPU للآلة. لذلك تُفوتر عملية بناء على Turbo تستغرق 3 دقائق و40 ثانية باعتبارها 4 دقائق، أي $0.42.

وللمفاضلة بين Basic وElastic على مستوى المشروع، اقرأ كيف تخفض تكلفة بناء Vercel باستخدام أجهزة Basic. أما القرار الجديد هنا فأضيق نطاقًا: هل يستحق موعد نهائي واحد دفع علاوة Turbo؟

مثال لعبء عمل، لا اختبار أداء

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

يضيف التجاوز العاجل الواحد $0.364 مقارنة بتشغيل عملية النشر نفسها على Basic. وفي هذا المثال، تُدفع هذه العلاوة مقابل توفير فعلي مرصود قدره 3 دقائق و40 ثانية في الإصدار الذي يهم.

أما إبقاء عمليات البناء الاعتيادية الـ20 على Basic، فيجعل الإجمالي الأسبوعي أقل بمقدار $7.28 من تشغيل العمليات الـ21 كلها على Turbo. هذه خلاصة أداة التحكم الجديدة في الميزانية. لكن القرار الفعلي يجب أن يستند إلى مددك أنت، لأن حالة ذاكرة التخزين المؤقت واستخدام CPU وضغط الذاكرة والتقريب قد تغيّر النتيجة.

من سيستفيد فعليًا من هذا المسار؟

مؤسس يعمل بمفرده ويطلق إصلاحًا للإنتاج

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

مسؤول إصدار في وكالة أمام موعد واحد

تستطيع الوكالة استخدام vc deploy --turbo في إصدار العميل الذي ينتظر فريقه مراجعته. وتبقى المعاينات الاعتيادية على إعداد المشروع المعتاد، فلا ترتفع تكلفة البناء بصمت مع كل مراجعة للعميل.

مهندس منصة يعمل ضمن مسار موافقات

يمكن لفريق المنصة إضافة buildMachine: "turbo" إلى مسار معتمد للإصدارات العاجلة فقط داخل خدمة النشر. وهكذا تصبح الموارد الحاسوبية الإضافية قرار إصدار واضحًا يمكن تسجيله ومراجعته واحتساب تكلفته، بدل أن تكون الإعداد الافتراضي الدائم للمشروع.

الحدود التي ينبغي قولها بوضوح

وجود ثلاثين vCPUs لا يعني أن البناء سيعمل أسرع 15 مرة من Basic ذي 2 vCPUs. فبعض عمليات البناء لا تستطيع تشغيل كل هذه الأنوية بكفاءة. وتوضح Vercel أن مشاريع كثيرة لا تستفيد بالكامل من آلة Turbo، وهذا أيضًا ما يتيح لـElastic اختيار آلة أصغر للأعمال الاعتيادية.

كما أن Turbo يغيّر الآلة، لا سياسة قائمة الانتظار. فإذا كان معظم التأخير ناتجًا من انتظار شاغر للبناء، فقد تكون الآلة الأكبر حلًا للمشكلة الخطأ. قارن مدة الانتظار في القائمة بمدة البناء الفعلية قبل أن تدفع مقابل مزيد من CPU.

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

نفّذ تجربة واحدة منضبطة

1. 1

   سجّل بيانات عملية النشر المعتادة

   افتح Build Diagnostics وسجّل آلة البناء المعتادة للمشروع، ومدة البناء، ووقت الانتظار في القائمة، والدقائق المفوترة، والنتيجة. اختر عملية نشر تشبه عبء العمل العاجل الذي يهمك.

2. 2

   طبّق التجاوز على عملية نشر واحدة

   استخدم علامة GitHub أو خيار CLI أو حقل API في عملية نشر مماثلة واحدة. ولا تغيّر إعداد آلة البناء على مستوى الفريق أو المشروع.

3. 3

   احسب سعر الوقت الذي وفرته

   اضرب دقائق بناء Turbo بعد التقريب في $0.105. قارن هذه التكلفة بالاستخدام المفوتر لعملية النشر المعتادة، ثم اقسم الدولارات الإضافية على الدقائق التي وفرتها فعليًا.

4. 4

   تحقق من عملية النشر التالية

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

ما الخطوة المناسبة الآن؟

• طبّق ذلك هذا الأسبوع إذا كان مشروعك على Pro أو Enterprise، وكانت لديك إصدارات عرضية مرتبطة بموعد ضيق مع رغبتك في الإبقاء على إعداد الآلة المعتاد.
• قس الأداء أولًا إذا كان المشروع يستخدم Elastic. فقد يخصص بالفعل ما يكفي من CPU والذاكرة، وعندها قد يرفع فرض Turbo الفاتورة من دون توفير ملموس في الوقت.
• استخدم إعداد المشروع بدلًا من ذلك إذا كانت معظم عمليات النشر تحتاج إلى Turbo. فتكرار الاستثناء في كل commit ليس إلا سياسة دائمة متنكرة في هيئة علامة.
• تجاهل هذا الخيار إذا كنت على Hobby، أو تستخدم Turbo افتراضيًا بالفعل، أو كان التأخير ناتجًا أساسًا من قائمة الانتظار.

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

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

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