الاستضافة الذاتية على Cloudflare Workers: التكلفة والحدود

يمكن لـ Cloudflare Workers أن يحل محل Server صغير عندما يعتمد تطبيقك على طلبات قصيرة، وتخزين مُدار، ومهام تعمل بالأحداث. بذلك تستغني عن VPS ومضيف Docker وتحديثات نظام التشغيل. لكنك لن تحصل على استضافة ذاتية (Self-hosting) فوق أجهزة تتحكم بها. الوصف الأدق هو أنك تنشر تطبيقك بنفسك على شبكة الحافة المُدارة من Cloudflare.

ابدأ باختبار مدى الملاءمة

يعمل Cloudflare Worker عند وصول طلب HTTP أو حدث مجدول أو رسالة من Queue أو حدث بريد إلكتروني. وهو لا يتصرف كعملية Linux تعمل باستمرار. يناسب هذا النموذج لوحات المعلومات وواجهات API وعمليات إعادة التوجيه وأدوات التعاون الخفيفة والتطبيقات التي تخزن حالتها في خدمات Cloudflare. لكن المشاكل تبدأ عندما يتوقع البرنامج وجود خدمات خلفية دائمة، أو وصول غير مقيد إلى الملفات، أو خوادم TCP مخصصة، أو قاعدة بيانات محلية قابلة للنقل.

يمكن شحن ملفات الواجهة الأمامية الثابتة مع Worker في صورة أصول ثابتة (Static Assets). تعمل المسارات الديناميكية داخل بيئة تشغيل Workers، بينما تربط الموارد (Bindings) التطبيق بقواعد البيانات وتخزين الكائنات وQueues ومنتجات Cloudflare الأخرى.

تدير Cloudflare الأجهزة والشبكة وبيئة التشغيل وخدمات التخزين. أما مالك الحساب، فيتحكم في كود التطبيق وإعدادات البيانات والنطاقات وسياسات الوصول وعمليات النشر من خلال Cloudflare Workers.

لماذا يهم ذلك؟ اختيار المنصة بناءً على طبيعة بيئة التشغيل يمنع عملية نشر رخيصة من التحول إلى إعادة تصميم مكلفة.

انشر عبر المستودعات والربط وWrangler

يبدأ النشر المعتاد من مستودع بهذه الأوامر:

bashCopy
npm install
npx wrangler login
npx wrangler secret put JWT_SECRET
npm run deploy

Wrangler هو أداة سطر الأوامر من Cloudflare للتطوير المحلي وإعداد الموارد وإدارة الأسرار والنشر والسجلات. قد يستخدم مستودع تطبيقك أمر نشر مختلفًا، لذلك يجب اعتبار وثائق المشروع المرجع الأساسي دائمًا.

يفتح الأمر wrangler login مسار تفويض لحساب Cloudflare المستهدف. أما wrangler secret put JWT_SECRET فيحفظ السر من دون وضع قيمته في نظام التحكم بالمصدر أو في ملف إعدادات بنص واضح.

عادةً ما تتبع عملية النشر الكاملة هذا الترتيب:

1. أنشئ Fork من مستودع التطبيق أو استنسخه.
2. راجع إعدادات wrangler وعمليات الربط المطلوبة.
3. أنشئ قواعد بيانات D1 أو مساحات أسماء KV أو حاويات R2 أو Durable Objects أو Queues.
4. أضف الأسرار عبر Wrangler أو لوحة تحكم Cloudflare.
5. انشر التطبيق على عنوان workers.dev.
6. اختبر المصادقة والكتابة والتصدير والاستعادة.
7. اربط نطاقًا مخصصًا بعد التأكد من عمل العنوان المؤقت.

يمكن لخدمة Workers Builds الاتصال بمستودع Git والنشر بعد كل تغيير معتمد. أما النشر المحلي باستخدام Wrangler، فيمنح فريقك تحكمًا أكبر عندما يحتاج إنشاء الموارد أو ترحيل البيانات إلى ترتيب يدوي.

يتيح الربط (Binding) لكود التطبيق الوصول إلى مورد داخل الحساب. قد تكون قاعدة البيانات موجودة فعلًا في الحساب، ومع ذلك يفشل التطبيق لأن اسم الربط الذي يتوقعه لا يطابق الاسم في الإعدادات.

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

لماذا يهم ذلك؟ معظم حالات فشل نشر Workers تنتج عن ربط الموارد وترحيل البيانات، لا عن كود التطبيق.

اربط كل نوع من البيانات بخدمة التخزين المناسبة

تُعد D1 قاعدة بيانات SQL مُدارة من Cloudflare. تناسب السجلات المنظمة مثل المستخدمين والملاحظات والرسائل والروابط وبيانات صندوق البريد وقواعد الوصول. لا مكان للصور الكبيرة ونسخ ZIP الاحتياطية داخل سجلات D1. فهي تزيد حجم قاعدة البيانات، وتعقّد عمليات التصدير، وتحول استعلامًا بسيطًا عن البيانات الوصفية إلى نقل غير ضروري للبيانات.

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

تُعد R2 خدمة تخزين الكائنات من Cloudflare. تناسب المرفقات والصور المحفوظة وملفات التصدير والنسخ الاحتياطية المشفرة وغيرها من الملفات الثنائية. من المفيد تخزين البيانات الوصفية للملف في D1، والملف نفسه في R2. تسجل قاعدة البيانات الملكية والحالة، بينما يحدد مفتاح R2 الكائن المطلوب.

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

لماذا يهم ذلك؟ الفصل الواضح بين أنواع التخزين يحسن الاتساق والاستعادة والتحكم في التكلفة في الوقت نفسه.

استخدم Durable Objects والخدمات الخلفية للمهام التي لا يستطيع HTTP إكمالها

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

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

تفصل Cloudflare Queues بين طلب HTTP والعمل الذي يمكن تنفيذه لاحقًا. يستطيع التطبيق قبول الطلب بسرعة وكتابة رسالة في Queue، ثم يترك للمستهلك معالجة التسليم من دون إبقاء الاتصال الأصلي مفتوحًا.

لنفترض أن مزود إرسال البريد الإلكتروني انتهت مهلته بعد قبول الرسالة. قد تؤدي إعادة المحاولة بلا تحقق إلى إرسال الرسالة مرتين. يسمح مفتاح منع التكرار المرتبط بسجل الرسالة للمستهلك بمعرفة ما إذا كانت عملية التسليم قد اكتملت بالفعل.

تحتاج عمليات إعادة المحاولة إلى حد أقصى للمحاولات ومسار للرسائل المتعذرة التي يستمر فشلها. وإلا فقد يستهلك عنوان واحد غير صالح وقت المعالجة إلى أجل غير محدد.

تشغّل Cron Triggers مهام مجدولة، مثل حذف الروابط المنتهية أو إنشاء ملفات التصدير الليلية. أما Workflows، فتناسب المهام الأطول التي تتضمن عدة خطوات دائمة، مثل استيراد أرشيف واستخراج البيانات الوصفية وإنشاء المعاينات وتحديث فهارس البحث.

لماذا يهم ذلك؟ نقل المهام البطيئة أو القابلة لإعادة المحاولة خارج طلبات HTTP يجعل حالات الفشل واضحة وقابلة للمعالجة.

تعامل مع البريد الإلكتروني والوصول إلى AI كحدود أمنية

عادةً ما يتبع صندوق البريد المبني على Workers هذا المسار:

تتعامل Email Routing مع الرسائل الواردة. لكنها لا تغطي تلقائيًا كل جوانب إرسال البريد الصادر، أو إدارة السمعة، أو معالجة الرسائل المرتدة، أو الالتزام بقواعد التسويق. يحتاج النطاق إلى سجلات DNS والبريد المطلوبة. كما يحتاج مرسلو البريد الصادر إلى إعداد SPF وDKIM بشكل صحيح، وبيانات اعتماد المزود، والتعامل مع حدود المعدل، ومراقبة الرسائل المرتدة.

يمكن لـ Cloudflare Access إضافة خطوة للتحقق من الهوية قبل الوصول إلى التطبيق. وتصبح سياستها حدًا مهمًا للثقة عندما يستخدم عدة أشخاص عملية النشر نفسها.

يقدم Agentic Inbox نموذجًا لصندوق بريد مدعوم بالذكاء الاصطناعي، ومبني باستخدام Email Routing وDurable Objects مخصصة لكل صندوق بريد ومرفقات R2 وWorkers AI للبحث وكتابة المسودات. من المهم مراجعة سياسة Access المشتركة بعناية قبل أن يستخدم عدة أشخاص صناديق بريد منفصلة.

تشغّل Workers AI النماذج المدعومة عبر منصة Cloudflare. تخزن Vectorize المتجهات المستخدمة في البحث الدلالي، بينما يستطيع بروتوكول سياق النموذج (Model Context Protocol)، أو MCP، إتاحة أدوات التطبيق لوكيل AI. يجب أن تبقى صلاحيات MCP محدودة. فالوكيل الذي يمكنه قراءة البريد وإرساله وحذفه يملك عمليًا صلاحيات مستخدم صندوق البريد نفسها، بما في ذلك القدرة على ارتكاب أخطاء لا يمكن التراجع عنها.

لمزيد من السياق حول صلاحيات الوكلاء والمفاضلة بين النماذج المحلية، راجع اتجاهات مطوري AI: الوكلاء والنماذج المحلية وسلامة الكود.

لماذا يهم ذلك؟ إضافة البريد الإلكتروني أو AI تغيّر نموذج التهديدات، حتى لو ظلت بنية الاستضافة بسيطة.

اختر التطبيق بناءً على تكلفة الفشل

Sink هو الخيار الأكثر أمانًا لأول عملية نشر

يستخدم Sink قاعدة D1 كمصدر أساسي للبيانات، وKV كذاكرة مؤقتة لعمليات إعادة التوجيه، وAnalytics Engine لبيانات الزيارات. ويمكنه إضافة نسخ R2 الاحتياطية واقتراحات Workers AI ورموز QR وانتهاء الصلاحية وكلمات المرور وتحذيرات الروابط غير الآمنة والتوجيه حسب البلد أو الجهاز.

تعطل خدمة اختصار روابط يسبب إزعاجًا، لكنه لا يكشف خزنة كلمات مرور أو صندوق بريد خاصًا. توثق Sink حاليًا مسار Proxy لـ OpenAPI بدلًا من Server MCP أصلي، لذلك يجب تصحيح الادعاءات القديمة المتعلقة بدعم MCP.

يخدم EdgeEver وInkstone أسلوبين مختلفين للملاحظات

يناسب EdgeEver المستخدمين الذين يريدون مكتبة على نمط Evernote، مع حفظ المحتوى من الويب، وعملاء دون اتصال، وتصدير Markdown، وبيانات وصفية في D1، ومرفقات في R2، ووصول REST، ودعم MCP. يقلل ضغط الصور على جهاز المستخدم من مساحة R2 ووقت الرفع. وتوفر نسخ ZIP الاحتياطية مسارًا عمليًا لنقل المشروع، بينما يبقى العرض العام مؤقتًا ولا ينبغي أبدًا أن يحتوي على ملاحظات خاصة.

يناسب Inkstone المعرفة المترابطة التي تعتمد على Markdown أولًا. تشمل ميزاته الروابط الخلفية وروابط Wiki والمجلدات والمعاينة المباشرة والبحث بالنص الكامل والتحرير دون اتصال وسجل الإصدارات والبحث الدلالي الاختياري عبر Workers AI.

الاختيار هنا يتعلق بأسلوب العمل، لا بالشكل. يركز EdgeEver على حفظ المحتوى وتنظيمه داخل مكتبة، بينما يركز Inkstone على المعرفة المترابطة المخزنة كنص عادي.

يحل HQBase وsaasmail مشكلتين مختلفتين للبريد الإلكتروني

يستهدف HQBase الفرق الصغيرة التي تحتاج إلى عدة نطاقات وصناديق بريد مشتركة ووصول مضبوط على مستوى كل صندوق بريد وتطبيق ويب تقدمي يعمل على الهاتف والكمبيوتر وإشعارات فورية ووصول MCP محمي عبر OAuth. يتطلب إعداده الموثق خطة Workers Paid واشتراك R2 نشطًا ونطاقًا يستخدم Cloudflare DNS. وهذا يعني تكلفة بداية لا تقل عن $5 لكل حساب شهريًا، قبل أي استخدام يتجاوز الحدود المشمولة.

يركز saasmail على مسارات عمل الدعم والتسويق. ويشمل محادثات بأسلوب الدردشة وقوالب HTML قابلة لإعادة الاستخدام وتسلسلات مجدولة وقوائم حظر وترويسات إلغاء اشتراك بنقرة واحدة. تشغيل الواجهة على Workers لا يحل مشكلة سمعة الإرسال. لا تزال سجلات الموافقة وإعدادات SPF وDKIM ومعالجة إلغاء الاشتراك والرسائل المرتدة وحدود المزود بحاجة إلى إدارة مستمرة.

يتطلب NodeWarden مستوى تشغيليًا أعلى

يُعد NodeWarden Server متوافقًا مع Bitwarden للاستخدام الشخصي أو العائلي أو ضمن فريق صغير. وهو يدعم تطبيقات Bitwarden الرسمية وسجلات D1 ومرفقات R2 أو KV وإشعارات Durable Objects والنسخ الاحتياطية ومفاتيح المرور والمصادقة الثنائية.

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

لا يحل NodeWarden محل Bitwarden Enterprise أو نموذج الدعم الخاص به. يجب على الفرق التي لديها متطلبات رسمية للامتثال أو الدعم أو التدقيق أو الإدارة المركزية مقارنة هذه الفجوات مباشرة.

Counterscale هو الخيار المصمم للتحليلات

يُعد Counterscale تطبيق تحليلات مصممًا للعمل مباشرة على Cloudflare. أما Plausible، فيقدم خدمة مستضافة مستقرة ومسارًا منفصلًا للاستضافة الذاتية.

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

لماذا يهم ذلك؟ البدء ببيانات منخفضة المخاطر يمنح فريقك مساحة لتعلم Workers قبل ائتمانه على أسرار أو اتصالات مهمة.

اعرف التكلفة الحقيقية والنقطة التي يتوقف عندها Workers عن كونه مناسبًا

تتضمن خطة Workers Free حاليًا 100,000 طلب يوميًا و10 milliseconds من وقت CPU لكل عملية تشغيل، وفقًا لـ وثائق Workers. يقيس وقت CPU مدة الحساب الفعلي، لا الوقت الكامل الذي يُقضى في انتظار استجابات الشبكة أو التخزين.

تبدأ خطة Workers Paid من $5 لكل حساب شهريًا. وتشمل 10 million طلب و30 million CPU milliseconds شهريًا. يمكن لحساب مدفوع واحد تشغيل عدة تطبيقات صغيرة ما دام إجمالي استخدامها ضمن الحدود المشمولة.

لدى D1 وKV وR2 وDurable Objects وQueues وWorkers AI وغيرها من المنتجات حدود ورسوم مستقلة. لذلك قد يكون الاعتماد على عدد الطلبات وحده مضللًا. فقد تستهلك أداة بحث AI قليلة الزيارات وقت CPU واستخدامًا مدفوعًا للنماذج أكثر من خدمة إعادة توجيه مزدحمة.

يصبح Workers خيارًا غير مناسب عندما يحتاج التطبيق إلى:

• عملية تعمل باستمرار
• وصول واسع إلى نظام التشغيل أو نظام الملفات
• خوادم TCP أو UDP مخصصة
• تحويل كثيف للوسائط
• ذاكرة مؤقتة محلية كبيرة
• قاعدة بيانات يجب نقلها بين المزودين من دون تغيير
• استقلال موثوق عن حساب Cloud واحد
• حزم تشغيل تعتمد على وظائف أصلية غير مدعومة

يوفر VPS تحكمًا أوسع في بيئة التشغيل ونشرًا أسهل لتطبيقات Docker التقليدية. يقلل Workers من صيانة Server، لكنه يزيد الاعتماد على واجهات Cloudflare API وعمليات الربط والحدود ونماذج الفوترة.

قابلية التصدير هي خط الدفاع العملي. احتفظ بملفات تصدير D1 وقوائم كائنات R2 وإعدادات التطبيق ومواد التشفير وتعليمات الاستعادة خارج حساب Cloudflare.

خطوات عملية

ابدأ من هنا

انشر Sink على عنوان workers.dev مؤقت، وأنشئ 5 روابط، ثم تأكد من عمل إعادة التوجيه والتحليلات قبل إضافة نطاق مخصص.

مكاسب سريعة

• صدّر قاعدة بيانات D1 الخاصة بالتطبيق واستعدها داخل بيئة اختبار منفصلة هذا الأسبوع.
• أنشئ تنبيهًا للفوترة في Cloudflare وسجّل خط أساس لمدة 7 أيام للطلبات ووقت CPU وعمليات D1 ومساحة R2.

تعمق أكثر

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

موارد مفيدة

• وثائق Cloudflare Workers - بيئة التشغيل وWrangler والربط والحدود والأسعار والتخزين والسجلات وعمليات النشر.
• HQBase - متطلبات صناديق البريد المشتركة ودعم PWA ونموذج الوصول وإرشادات النشر.
• مستودع EdgeEver - بنية D1 وR2 والتطبيقات وعمليات التصدير وMCP وتفاصيل الإعداد.
• وثائق NodeWarden - التوافق مع Bitwarden وإعدادات الأمان والنسخ الاحتياطية والربط والحدود الحالية.
• وثائق Sink - إرشادات نشر Workers وD1 وKV وAnalytics Engine وR2 وWorkers AI.

لماذا يهم ذلك؟ يسهل التعامل مع مشاكل التكلفة وقابلية النقل قبل أن يصبح التطبيق مهمًا للعمليات اليومية.

الخلاصة

يمكن لـ Cloudflare Workers أن يحل محل Server صغير عندما تكون الطلبات قصيرة، وتعيش حالة التطبيق داخل خدمات مُدارة، وتستخدم المهام الخلفية Queues أو الجداول أو Workflows. فهو يلغي صيانة Server، لكنه لا يمنحك ملكية الأجهزة أو التحكم الكامل في بيئة التشغيل.

ابدأ بـ Sink أو تطبيق ملاحظات. أضف خيارات التصدير، واختبر الاستعادة، وراقب إجمالي استخدام الحساب، وراجع كل حدود المصادقة.

انتقل إلى VPS أو منصة حاويات أو قاعدة بيانات مُدارة قابلة للنقل عندما يحتاج عبء العمل إلى عمليات طويلة، أو وصول واسع إلى بيئة التشغيل، أو قواعد بيانات تقليدية، أو استقلال عن مزود واحد.

أفضل بيئة للنشر هي التي تتناسب مع تكلفة فشل التطبيق ونموذجه التشغيلي.