كيف تصدّر تطبيقاً بُني بالذكاء الاصطناعي وتستضيفه بنفسك
لاستضافة تطبيق بُني بالذكاء الاصطناعي بنفسك، استخرج الكود (بتنزيله أو بمزامنته مع مستودع GitHub تملكه)، ثم أعد إنشاء أسراره كمتغيرات بيئة، وانقل قاعدة بياناته أو أعد إنشاءها، وانشره على مزود يناسب طبيعة التطبيق: استضافة ثابتة للواجهة الأمامية البسيطة، أو منصة تشغّل الخوادم أو الحاويات لأي تطبيق له خلفية. الكود عادةً هو الجزء السهل. البيانات والأسرار والخدمات التي كان المنشئ يشغّلها لك دون أن تلاحظ هي مكمن العمل الحقيقي.
لماذا تُصدّر أصلاً
هناك أسباب وجيهة لأخذ كودك معك، وأسباب أقل وجاهة.
أسباب وجيهة:
- الملكية والتأمين. نسخة من الكود في مستودعك الخاص تحميك إذا غيّر المنشئ أسعاره أو ميزاته أو شروطه.
- تسليم للمطورين. فريق هندسي سيريد الكود في Git وضمن أدواته ومسار المراجعة المعتاد لديه.
- متطلبات محددة. مكان تخزين البيانات، أو مزود سحابي بعينه، أو سياسات أمان الشركة، أو بنية تحتية لا يقدمها المنشئ.
- التوسع أو التكلفة عند حجم يجعل تشغيل بنيتك التحتية الخاصة مجدياً فعلاً.
أسباب أقل وجاهة: نقل تطبيق صغير له عدد قليل من المستخدمين لتوفير مبلغ شهري صغير. الاستضافة الذاتية تنقل العمل إليك: التحديثات، والنسخ الاحتياطي، والمراقبة، وترقيع الأمان. قد يكون ذلك القرار الصحيح، لكن اتخذه وأنت تعلم ما تفعل.
حل وسط مفيد: واصل البناء والاستضافة حيث أنت، لكن زامن الكود مع مستودع GitHub تملكه منذ البداية. تحصل على التأمين دون العبء التشغيلي. إذا كان Git جديداً عليك، فاقرأ ما هو GitHub.
ما الذي يحتويه التصدير وما الذي لا يحتويه
قبل أن تعتمد على تصدير، افتحه وتحقق منه. عادةً:
| يتضمنه | لا يتضمنه عادةً |
|---|---|
| الكود المصدري (الواجهة الأمامية والخلفية) | قيم الأسرار (مفاتيح الواجهات، وكلمات المرور) |
ملفات الإعداد (package.json، وDockerfile، وإعداد البناء) | الحزم المثبتة (node_modules وما شابهها)، فهي تُعاد تثبيتها |
| مخطط قاعدة البيانات وملفات الترحيل، إذا كان التطبيق يستخدمها | البيانات الفعلية في قاعدة البيانات |
| الملفات الثابتة في المشروع | الملفات التي رفعها المستخدمون إلى تخزين منفصل |
| الخدمات التي يديرها المنشئ: الاستضافة، والنطاقات، وخادم قاعدة البيانات، وتخزين الملفات |
تُستبعد الأسرار عن قصد، فالأرشيف الذي قد تُرسله بالبريد أو تُودعه في Git يجب ألا يحتوي أبداً على مفاتيح حية. وتُستبعد الحزم لأنها تُعاد بناؤها من ملف القفل (lock file).
الخطوة 1: أخرج الكود
هناك طريقتان شائعتان:
- تنزيل أرشيف للمشروع. سريع، ومناسب لنقل لمرة واحدة أو لنسخة احتياطية.
- المزامنة مع GitHub. أفضل لأي شيء مستمر: سجل كامل، وسهولة النسخ إلى أي مكان، ومعظم المنصات تنشر مباشرةً من مستودع GitHub مع كل دفعة.
في الحالتين، انسخ المشروع أو فك ضغطه على جهاز (أو بيئة تطوير سحابية)، وابحث عن ملف README. إذا لم يكن موجوداً، اطلب من الذكاء الاصطناعي في المنشئ أن يكتبه قبل أن تغادر:
اكتب README لتشغيل هذا المشروع خارج هذه المنصة: الحزمة التقنية، وإصدارات البيئة المطلوبة، وأوامر التثبيت والبناء، وأمر التشغيل والمنفذ، وكل متغير بيئة يقرؤه الكود (الأسماء والغرض، دون القيم)، وكيف تُشغَّل ترحيلات قاعدة البيانات.
هذا الطلب الواحد يوفر ساعات، لأنه يجبر الأجزاء الضمنية من الإعداد على أن تُكتب.
الخطوة 2: شغّله محلياً أولاً
قبل أن تنشر في أي مكان، أثبت أن التطبيق يعمل بمفرده:
- ثبّت البيئة التي يذكرها README، مثل Node.js أو Python أو Java أو .NET، بإصدار متوافق.
- ثبّت الحزم (
npm installأوpnpm installأوpip install -r requirements.txtأو المكافئ). - أنشئ ملف
.envمحلياً بمتغيرات البيئة، مع استخدام مفاتيح اختبار حيثما أمكن. واحفظه خارج Git. يشرح ما هي متغيرات البيئة والأسرار الفكرة. - صِله بقاعدة بيانات، إما Postgres محلي أو قاعدة بيانات تطوير مجانية من مزود مُدار.
- شغّل الترحيلات، ثم شغّل التطبيق وتصفح المسارات الرئيسية.
أي شيء يتعطل هنا سيتعطل على الخادم أيضاً، ويكون تصحيحه أسهل على جهازك. مفاجآت شائعة: رابط ثابت في الكود يشير إلى معاينة المنشئ، أو متغير بيئة مفقود كان المنشئ يحقنه تلقائياً، أو خدمة (تخزين ملفات، أو تغيير حجم الصور) لم تكن موجودة إلا على المنصة.
الخطوة 3: انقل البيانات
إذا كان للتطبيق مستخدمون حقيقيون، فالبيانات أهم من الكود.
- صدّر قاعدة البيانات. في Postgres، ينتج
pg_dumpملفاً يمكنك استعادته بـpg_restoreأوpsqlفي القاعدة الجديدة. اطلب من الذكاء الاصطناعي في منصة المنشئ تشغيله إذا لم يكن لديك وصول مباشر، واطلب منه شرح ما أنتجه. - انقل الملفات المرفوعة. إذا رفع المستخدمون صوراً أو مستندات، فهي موجودة في تخزين كائنات منفصل عن قاعدة البيانات. انسخها إلى التخزين الجديد (مثلاً حاوية متوافقة مع S3)، وحدّث الروابط المخزنة إذا كانت تتضمن النطاق القديم.
- خطط للحظة التحويل. بالنسبة للتطبيق الحي، الطريقة البسيطة هي نافذة صيانة قصيرة: أوقف الكتابة، وخذ تصديراً أخيراً، واستعده على المزود الجديد، وبدّل DNS، ثم أعد فتح التطبيق. اكتب كل خطوة قبل البدء.
- اختبر الاستعادة في قاعدة بيانات تجريبية قبل النقل الفعلي.
إذا كان Postgres غير مألوف لك، فإن ما هو Postgres يغطي الأساسيات.
الخطوة 4: اختر مكان الاستضافة
طابق المزود مع طبيعة التطبيق. الأسماء التالية أمثلة لمزودين معروفين في كل فئة، حتى سبتمبر 2026، وليست ترتيباً، فتحقق من الميزات والأسعار الحالية في مواقعهم.
| شكل التطبيق | ما يحتاجه | أمثلة على المزودين |
|---|---|---|
| موقع ثابت أو SPA (HTML وCSS وJS فقط) | استضافة ملفات مع شبكة توصيل محتوى (CDN) | Netlify، Vercel، Cloudflare Pages، GitHub Pages |
| إطار عمل متكامل (Next.js وما شابهه) | خوادم أو دوال بلا خادم (serverless) | Vercel، Netlify، Render، Railway |
| واجهة برمجية أو خلفية (Node وPython وJava وC#) | خادم يعمل دائماً أو يتوقف عند الخمول | Render، Railway، Fly.io، خدمات الحاويات السحابية |
| أي تطبيق لديه Dockerfile | بيئة تشغيل للحاويات | Fly.io، Render، Railway، AWS، Google Cloud، Azure |
| تحكم كامل | خادم افتراضي تديره بنفسك | DigitalOcean، Hetzner، Linode، أو أي خادم سحابي |
ستحتاج أيضاً إلى:
- قاعدة بيانات مُدارة. كثير من منصات التطبيقات توفر Postgres، وخدمات متخصصة مثل Neon أو Supabase توفره بمفرده. الإدارة تستحق العناء، فالنسخ الاحتياطي والتحديثات تصبح مسؤولية شخص آخر.
- تخزين كائنات للملفات المرفوعة، إذا كان للتطبيق رفع ملفات.
- إرسال البريد والمدفوعات ومزودي الذكاء الاصطناعي، وهذه تحتاج عادةً فقط إلى نفس مفاتيح الواجهات مضبوطة على المزود الجديد.
وبإنصاف في المقايضات: منصات الاستضافة (الصفوف الأربعة الأولى) أسرع في الإعداد والصيانة، لكن تحكمك أقل وقد ترتفع التكاليف مع الزيارات. الخادم الافتراضي غالباً أرخص عند الحمل الثابت، وتحت سيطرتك الكاملة، لكنك تتولى التحديثات والشهادات (TLS) والنسخ الاحتياطي والمراقبة والاستعادة. إذا لم يرغب أحد في فريقك في تحمّل هذه المهمة، فاختر منصة. لأساسيات الاستضافة، راجع ما هي استضافة الويب.
الخطوة 5: انشر وبدّل
- اربط المستودع بالمنصة، أو ادفع صورة حاوية.
- اضبط متغيرات البيئة في لوحة المنصة، كل متغير من README، بقيمه الحية.
- اضبط أوامر البناء والتشغيل والمنفذ. كثير من المنصات تمرر المنفذ عبر متغير
PORT؛ يجب أن يستمع التطبيق إليه وعلى كل الواجهات (0.0.0.0)، لا علىlocalhostفقط. - شغّل الترحيلات على قاعدة البيانات الجديدة.
- اختبر على الرابط المؤقت للمنصة قبل أن تلمس DNS.
- حدّث الخدمات الخارجية التي تشير إلى رابطك القديم: روابط webhooks للمدفوعات، وروابط إعادة التوجيه لتسجيل الدخول عبر OAuth، وروابط البريد، والأصول المسموح بها.
- انقل النطاق بتحديث سجلات DNS لتشير إلى المزود الجديد. يشرح كيف تربط نطاقاً مخصصاً السجلات.
- أبقِ النشر القديم قائماً لفترة قصيرة حتى تتأكد، ثم أوقفه.
الخطوة 6 هي الأكثر نسياناً: تسجيلات الدخول والمدفوعات التي تفشل بصمت بعد النقل تعود عادةً إلى عنوان رجوع (callback) ما زال يشير إلى الخادم القديم.
الخطوة 6: تولّ العمليات بنفسك
بعد أن تستضيف بنفسك، تصبح المهام التي كان المنشئ يتولاها من مسؤوليتك. على الأقل: نسخ احتياطية تلقائية لقاعدة البيانات مع استعادة مُجرَّبة، وتتبع للأخطاء، وتنبيهات تعطل الخدمة، وتحديث الاعتماديات، وقائمة بمن يملك صلاحية الوصول لكل حساب. يتناول كيف تنقل نموذجاً أولياً بالذكاء الاصطناعي إلى الإنتاج هذه القائمة بمزيد من التفصيل.
قائمة مراجعة التصدير
- الكود في مستودع تملكه، مع README يغطي التشغيل والبناء ومتغيرات البيئة
- التطبيق يعمل محلياً من نسخة نظيفة
- قاعدة البيانات مُصدَّرة ومُجرَّب استعادتها، والملفات المرفوعة منسوخة
- المزود مختار بحسب طبيعة التطبيق، مع قاعدة بيانات مُدارة وتخزين
- كل متغيرات البيئة مضبوطة بقيم حية على المزود الجديد
- روابط webhooks وOAuth ورسائل البريد محدّثة
- تم تبديل DNS، وأُبقي النشر القديم لفترة قصيرة ثم أُزيل
- النسخ الاحتياطية والمراقبة وقائمة الصلاحيات موجودة
التصدير من Mythex
في Mythex تملك الكود الذي تبنيه. في خطة Pro يمكنك تنزيل المشروع كأرشيف من إعدادات المشروع ← تصدير، أو ربط GitHub والدفع والسحب من مستودعك الخاص. أما الخطط المجانية فتتيح عرض الكود للقراءة فقط دون تصدير أو مزامنة. تُستبعد الأسرار وnode_modules من التصدير، لذا أعد إنشاء أسرارك على المزود الجديد. تغطي الوثائق الخطوات في التصدير والتشغيل في مكان آخر وGitHub والتصدير والاستيراد. ويمكنك أيضاً الاستمرار في الاستضافة على Mythex، واستخدام مزامنة GitHub كنسخة خاصة بك ومسار لتسليم الكود؛ وإذا انتقلت فعلاً، فأوقف تطبيق Mythex المنشور بعد أن يصبح المزود الجديد حياً.
الأسئلة
هل يمكنني تصدير الكود من منشئ تطبيقات بالذكاء الاصطناعي؟
يعتمد ذلك على الأداة والخطة. بعض المنشئين يتيحون تنزيل المشروع كاملاً أو مزامنته مع مستودع GitHub تملكه، وآخرون يُبقون التطبيق داخل منصتهم. تحقق قبل أن تستثمر شهوراً في أداة، واقرأ ما يتضمنه التصدير وما لا يتضمنه.
هل يتضمن التصدير قاعدة بياناتي ومفاتيح الواجهات البرمجية؟
عادةً يُصدَّر الكود وليس البيانات ولا الأسرار. المفاتيح السرية تُستبعد عادةً عن قصد، ومحتوى قاعدة البيانات يحتاج إلى تصدير منفصل، مثل pg_dump في Postgres. خطط للأمرين قبل أن تغيّر مزود الاستضافة.
أين يجب أن أستضيف تطبيقاً مُصدَّراً؟
الواجهة الأمامية الثابتة تناسب الاستضافة الثابتة مثل Netlify أو Vercel أو Cloudflare Pages. التطبيق الذي له خادم خاص به يحتاج إلى منصة تشغّل الكود أو الحاويات، مثل Render أو Railway أو Fly.io، أو خادماً افتراضياً تديره بنفسك. وستحتاج إلى قاعدة بيانات مُدارة إذا كان للتطبيق قاعدة بيانات.
هل الاستضافة الذاتية أرخص من البقاء على منصة المنشئ؟
أحياناً، عند الحجم الكبير. بالنسبة للتطبيقات الصغيرة يكون الفرق غالباً ضئيلاً بعد احتساب قاعدة البيانات والبريد والمراقبة ووقتك في الصيانة. انتقل من أجل التحكم أو متطلبات محددة، لا فقط لتوفير بضعة دولارات شهرياً.