بأسعار القائمة الحالية، يبدأ فريق من 3 أشخاص يستخدم GitHub Team وVercel Pro وSentry Team وLinear Basic وNotion Plus من نحو 158 دولارًا شهريًا قبل 1Password ورسوم الاستخدام والإضافات. يمكن لحزمة مستضافة ذاتيًا ومحددة النطاق بعناية أن تخفض هذه الفاتورة بدرجة كبيرة، لكن المقارنة المنصفة تشمل خادم VPS أكبر من الحد المخبري البالغ 4 غيغابايت، ووقت الصيانة الذي ينساه الجميع.
هذا الدليل موجّه إلى المطوّر أو الفريق الصغير الذي حسم أمره بأن «فاتورة SaaS مزعجة» وأن «إبقاء الشيفرة الخاصة وسير عمل التطوير على بنية تحتية تابعة لطرف ثالث أمر غير مريح»، ويريد الآن معرفة ما الذي يشغّله تحديدًا. تتألف الحزمة من أربع طبقات: الشيفرة، والبناء والنشر، والتشغيل، والتوثيق. تحصل كل طبقة على أداة موصى بها، وبديل واحد، وتكلفة الموارد، ونمط الفشل. النطاق هو الاستخدام الخاص والجماعي على خادم VPS واحد. أما استضافة البريد وDNS ومصادقة العملاء النهائيين وKubernetes فخارج النطاق، لأسباب سنذكرها في موضعها.
النسخة المختصرة
إن لم تقرأ سوى النقاط:
- الكود: Forgejo افتراضيًا. لا تستخدم GitLab CE إلا إذا أردت git وCI/CD والسجل والمهام في منتج واحد؛ فالأساس الحالي لـ GitLab على عقدة واحدة هو 16 غيغابايت من الذاكرة، مع تخصيص 8 غيغابايت للبيئات المحدودة الذاكرة.
- البناء والنشر: Coolify on the current stable release (v4.3.0 at QC time), with the dashboard kept off the public internet. Dokku suits solo developers; pure Docker Compose suits teams that prefer visible moving parts.
- نفّذ: Vaultwarden لبيانات الاعتماد المشتركة، وUptime Kuma للمراقبة، وGlitchTip لتتبّع الأخطاء، وPortainer أو Dockge لإدارة الحاويات. نشر GlitchTip أصغر بكثير من Sentry المستضاف ذاتيًا، الذي يبلغ حده الأدنى الرسمي 16 غيغابايت من الذاكرة إضافة إلى 16 غيغابايت من ذاكرة التبديل.
- التوثيق: Docmost للتوثيق وOpenProject (أو Plane) لتتبّع المهام. ويناسب AFFiNE الفرق التي تفضّل نموذج Notion القائم على لوحة الرسم.
- تحديد الحجم: اعتبر 4 غيغابايت حجمًا مخبريًا لبضع خدمات خفيفة، و8 غيغابايت تجربة مصغّرة بلا OpenProject أو Plane أو عمليات بناء محلية، و16 غيغابايت نقطة البداية العملية للحزمة الكاملة القائمة على Forgejo في هذا الدليل. أما أساس GitLab البالغ 8 وحدات معالجة افتراضية و16 غيغابايت فينطبق على GitLab نفسه، لذا تتطلب حزمة الصندوق الواحد القائمة على GitLab سعة إضافية أو اختبار أحمال منفصلًا.
- أين يخسر: المشاريع مفتوحة المصدر العامة التي تعتمد على مساهمين خارجيين. فأثر الشبكة لدى GitHub حقيقي، والاستضافة الذاتية تكلّفك قابلية الاكتشاف.
المتطلبات الأساسية
قبل أن تتابع القراءة، يفترض هذا الدليل:
- خادم VPS بنظام Linux مثبّت عليه Docker وDocker Compose. خصّص نحو 16 غيغابايت من الذاكرة للحزمة الكاملة القائمة على Forgejo؛ وتكفي 8 غيغابايت لتجربة مصغّرة تستغني عن أدوات إدارة المشاريع الأثقل وعمليات البناء المحلية.
- من 30 إلى 60 دقيقة من الانتباه لكل طبقة عند النشر الأول.
- ارتياح في قراءة ملف Compose وتعديل متغيرات البيئة.
- الاستعداد للالتزام بنافذة تحديث منتظمة، وتطبيق إصلاحات الأمان بسرعة، والتحقق من النسخ الاحتياطية بدل الاكتفاء بإعدادها.
إن كان أي من ذلك عائقًا حاسمًا، فحزمة SaaS هي الإجابة الصحيحة فعلًا لفريقك. هذا موقف يمكن الدفاع عنه، لا فشل.
ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.
عرض باقات Linuxالطبقة 1، الشيفرة: Forgejo أو Gitea أو GitLab CE
ثلاثة خيارات صالحة، وثلاث نقاط مختلفة على منحنى الموارد والحوكمة. وللمبتدئين في الاستضافة الذاتية في 2026، التوصية هي Forgejo أولًا.
صُمّم Forgejo لبنية تحتية متواضعة، ويقدّم طلبات السحب وتتبّع المهام ولوحات المشاريع وصفحات الويكي وسجلات الحزم وForgejo Actions. تستخدم سير عمله صيغة على غرار GitHub Actions، لكن التوافق ليس مطلقًا؛ فاختبر كل إجراء من طرف ثالث يعتمد عليه خط الإنتاج لديك.
لا تختر Gitea إلا إذا كنت تعتمد بالفعل على ميزة خاصة به أو كانت أدواتك مثبّتة على إصدار معيّن منه. لا عيب في الشيفرة نفسها. تقول المقارنة الرسمية لدى Forgejo إن الاشتقاق جاء بعد نقل نطاقات Gitea وعلامته التجارية في أكتوبر 2022 إلى شركة ربحية دون موافقة المجتمع؛ ويسجّل إعلان الترخيص لدى Forgejo رخصة GPL v3+ للإصدارات ابتداءً من v9.0.
اختر GitLab CE إن أردت منتجًا واحدًا لـ git وCI/CD وسجل الحاويات وتتبّع المهام، وكان بمقدورك تحمّل حدّه الأدنى من الموارد. متطلبات GitLab الحالية تحدّد 16 غيغابايت من الذاكرة و8 وحدات معالجة افتراضية كأساس للعقدة الواحدة؛ أما 8 غيغابايت فللبيئات المحدودة الذاكرة. وGitea خفيف بما يكفي لتشغيل نسخة خاصة صغيرة ضمن 1 إلى 2 غيغابايت من الذاكرة، وForgejo مماثل له، غير أن تحديد الحجم في الإنتاج لكليهما يظل رهنًا بالمستودعات والمنفّذين وعدد المستخدمين المتزامنين.
| الأداة | الموارد الابتدائية | الحوكمة | الرخصة | CI/CD مدمج | متى تختاره |
|---|---|---|---|---|---|
| Forgejo | 1-2 وحدة معالجة افتراضية / 1-2 غيغابايت ذاكرة (تقدير للاستخدام الخفيف) | يقوده المجتمع (Codeberg e.V.) | GPL v3+ (v9.0+) | Forgejo Actions؛ اختبر التوافق | الخيار الافتراضي للمبتدئين في الاستضافة الذاتية عام 2026 |
| Gitea | 1-2 وحدة معالجة افتراضية / 1-2 غيغابايت ذاكرة (تقدير للاستخدام الخفيف) | ربحية (Gitea Ltd، منذ أكتوبر 2022) | MIT | Gitea Actions؛ اختبر التوافق | اعتماد قائم على Gitea أو أدوات مثبّتة على إصدار محدّد |
| GitLab CE | 8 vCPU / 16 GB RAM baseline; 8 GB constrained | GitLab Inc | MIT (Community Edition) | أصلي وكامل الميزات | تريد منصة واحدة لـ git وCI/CD والسجل والمهام، ولديك الذاكرة الكافية |
تستحق مسألة التكامل المستمر التنويه. فقد صُمّم Gitea Actions ليكون متوافقًا في معظمه مع GitHub Actions، بينما يقصد Forgejo Actions الألفة عمدًا بدل التوافق الكامل. كثير من سير العمل لا يحتاج سوى تعديلات طفيفة، لكن صور المنفّذين والأذونات والسياقات والوسوم والإجراءات من طرف ثالث قد تتصرّف على نحو مختلف. اختبر كل سير عمل وكل إجراء يعتمد عليه خط الإنتاج لديك قبل الترحيل.
ثمة تحفّظ واحد ينطبق على الخيارات الثلاثة جميعًا. يفترض هذا الدليل استخدامًا خاصًا وجماعيًا، مع إبقاء سطح الإدارة خلف شبكة افتراضية خاصة أو قائمة عناوين IP مسموح بها. فخدمات git العامة تواجه حركة روبوتات وإساءة استخدام ومفاضلات في قابلية الاكتشاف لا يعرفها نشر خاص صغير. أما للمصادر المفتوحة العامة، فأنشئ مرآة على GitHub من أجل الظهور مع إبقاء Forgejo مصدر الحقيقة إن كان نموذج الحوكمة هذا مهمًا لك.
حدّد حجم الخادم انطلاقًا من عبء العمل، لا من أسماء باقات المزوّد. فخدمة Forgejo أو Gitea قائمة بذاتها للاستخدام الخاص الخفيف يمكن أن تبدأ بنحو 1 إلى 2 وحدة معالجة افتراضية و1 إلى 2 غيغابايت من الذاكرة. وحزمة مصغّرة بلا OpenProject أو Plane أو عمليات بناء محلية يمكن أن تبدأ بنحو 4 وحدات و8 غيغابايت. أما الحزمة الكاملة القائمة على Forgejo الموصوفة هنا فابدأها بنحو 8 وحدات و16 غيغابايت، ثم تحقّق منها تحت حِمل حقيقي للتكامل المستمر والتطبيقات. وأساس GitLab الرسمي البالغ 8 وحدات و16 غيغابايت ينطبق على GitLab نفسه، فلا تعدّه كافيًا لـ GitLab وبقية هذه الحزمة معًا. استخدم تخزين SSD أو NVMe، وخصّص ميزانية منفصلة للمستودعات وصور الحاويات والسجلات وقواعد البيانات والنسخ الاحتياطية، وأبقِ 20 إلى 30% من السعة حرة للتحديثات وذُرى الحِمل.
خلاصة القسم الرئيسية: Forgejo هو التوصية الافتراضية لطبقة الشيفرة في 2026؛ ويظل Gitea متينًا، أما GitLab CE فهو الخيار المتكامل فقط إن كان بمقدورك تحمّل أساسه البالغ 16 غيغابايت أو كنت تشغّله عن وعي في تهيئة مقيّدة بـ 8 غيغابايت.
الطبقة 2، البناء والنشر: Coolify (مع تحفّظات) أو Dokku أو Docker Compose وحده
لنضع الأمر بصراحة: Coolify هو خيار الـ PaaS الموصى به لهذه الحزمة إن كنت تشغّل أحدث إصدار إنتاجي، وتُبقي لوحة الإدارة بعيدة عن الإنترنت العام، وتتابع التنبيهات الأمنية. ووقت مراجعة الجودة، يضع GitHub علامة Coolify v4.3.0 Coolify v4.1.2 بأنه الأحدث. عامِل التصحيح وعزل مستوى الإدارة بوصفهما متطلبين تشغيليين، لا تحصينًا اختياريًا.
نصيحة احترافية: قيّد لوحة تحكم Coolify وواجهة برمجته بجدار ناري أو شبكة افتراضية خاصة أو وسيط وصول موثوق. ولا يزال بإمكان التطبيقات المنشورة استقبال حركة عامة؛ فالهدف هو تقليل انكشاف مستوى التحكم الإداري.
البديل للمطوّرين المنفردين هو Dokku، وهو PaaS مدمج يوفّر نشرًا بأسلوب Heroku عبر git push ويدعم حزم البناء. مساحته أصغر من Coolify، ومجموعة ميزاته أصغر تبعًا لذلك. وهذا يجعله «خيارًا مملًا» يمكن الدفاع عنه لمطوّر أو اثنين لا يحتاجان إلى لوحة تحكم.
أما الخيار الثالث الذي يلجأ إليه المشغّلون المخضرمون فهو لا PaaS إطلاقًا، بل Docker Compose فقط. فإن كان فريقك يكتب ملفات Compose أصلًا وتفضّل رؤية الأجزاء المتحركة، فهذه إجابة معقولة تمامًا. أضف Dockge أو Portainer كطبقة واجهة لإدارة الحزم متى أردت إعادة تشغيل بنقرة بدل docker compose restart. المفاضلة هنا تشغيلية: لا بيئات معاينة، ولا أتمتة TLS مدمجة، ولا عمليات نشر بلا توقّف من دون جهد. تُكتسب هذه الميزات بكتابة السكربتات؛ أما مع Coolify فهي جاهزة، ومعها سجل الأمان المرافق لها.
دليل Cloudzy لأفضل أدوات CI/CD يتناول خط البناء بعمق أكبر للفرق التي تحتاج منفّذًا منفصلًا، وهو ما لا تحتاجه فرق صغيرة كثيرة بمجرد توفّر Forgejo Actions أو CI/CD الخاص بـ GitLab.
خلاصة القسم الرئيسية: Coolify هو الـ PaaS الموصى به فقط على الإصدار المستقر الحالي ومع تقييد مستوى إدارته؛ وDokku هو الخيار المحافظ للعمل المنفرد؛ ويظل Docker Compose وحده خيارًا ثالثًا يمكن الدفاع عنه.
الطبقة 3، التشغيل: Vaultwarden وUptime Kuma وGlitchTip وإدارة الحاويات
هنا تكمن أوضح فجوة في الموارد ضمن هذه الحزمة. المتطلبات الرسمية لـ Sentry المستضاف ذاتيًا تذكر كحد أدنى 4 أنوية معالجة و16 غيغابايت من الذاكرة و16 غيغابايت من ذاكرة التبديل و20 غيغابايت من القرص الحر، مع التوصية بـ 32 غيغابايت من الذاكرة. دليل تثبيت GlitchTip يوصي بـ 512 ميغابايت من الذاكرة، ويشترط PostgreSQL، ويجعل Valkey اختياريًا. ولفريق صغير على خادم VPS واحد، يكون GlitchTip هو الخيار الافتراضي العملي.
| الأداة | الذاكرة (المعتادة) | عدد الحاويات | توافق واجهة البرمجة |
|---|---|---|---|
| Sentry المستضاف ذاتيًا | 16 GB RAM plus 16 GB swap minimum; 32 GB recommended | نشر كبير متعدد الخدمات | أصلي |
| GlitchTip | 512 MB recommended; 256 MB minimum for the all-in-one setup | خدمتان أساسيتان؛ وValkey اختياري | حركة حزم تطوير Sentry؛ اختبر تكافؤ الميزات |
أما الأدوات الأربع الباقية في هذه الطبقة فحكايتها قصيرة.
Vaultwarden مدير كلمات مرور متوافق مع Bitwarden، ويدعم تطبيقات Bitwarden للهواتف وإضافات المتصفح إلى جانب المشاركة الجماعية. أما بصمته الفعلية فتتوقف على المستخدمين والمرفقات واختيار قاعدة البيانات. مقارنة Cloudzy لمديري كلمات المرور المستضافين ذاتيًا تتناول المفاضلة الأعمق حين تحتاج أذونات أكثر تنظيمًا أو ضوابط تدقيق أو نموذج أمان مختلفًا.
Uptime Kuma هو أداة المراقبة والتنبيه الصغيرة: فحوص HTTP وTCP وping وpush وانتهاء الشهادات، مع صفحات حالة اختيارية. ويمكن توجيه الإشعارات عبر الدردشة أو البريد أو الـ webhooks. ويتباين استهلاك الموارد بحسب عدد المراقبات ومدة الاحتفاظ؛ والتنبيه عند الإخفاق الثاني على التوالي وسيلة عملية لكبح الاهتزازات العابرة.
GlitchTip هو متتبّع الأخطاء. ويمكن لمعظم تكاملات حزم تطوير Sentry أن ترسل إلى عنوان DSN خاص بـ GlitchTip، لكن تكافؤ الميزات ليس تامًا؛ فاختبر مراقبة الأداء وخرائط المصدر والتنبيهات وأي تكامل يعدّه فريقك حرجًا.
اختر Portainer أو Dockge كواجهة للحاويات. يغطّي Portainer نطاقًا أوسع من حالات إدارة الحاويات، بينما يظل Dockge مركّزًا على Docker Compose. وللحزمة الصغيرة القائمة على Compose وحده، يكون Dockge أنسب. ولا تنتقل إلى Portainer إلا حين تحتاج النطاق الأوسع.
من الممارسات المريحة مع Compose في هذه الطبقة: احتفظ بكل أداة في مجلد فرعي خاص بها وملف compose.yml خاص بها، ولا تشارك شبكة Docker إلا حيث تلزم حركة بين الأدوات، وضع وسيطًا عكسيًا واحدًا في المقدمة لإنهاء اتصالات TLS.
# /opt/stack/glitchtip/compose.yml (excerpt)
services:
web:
image: "glitchtip/glitchtip:${GLITCHTIP_VERSION:?Set GLITCHTIP_VERSION in .env}"
environment:
DATABASE_URL: "${DATABASE_URL:?Set DATABASE_URL in .env}"
SECRET_KEY: "${GLITCHTIP_SECRET_KEY:?Set GLITCHTIP_SECRET_KEY in .env}"
GLITCHTIP_DOMAIN: "https://errors.example.com"
DEFAULT_FROM_EMAIL: "[email protected]"
ports:
- "127.0.0.1:8000:8000"نصيحة احترافية: لا تثبت النسخة الاحتياطية إلا حين تتمكّن من استعادة الخدمة والتحقق من بياناتها. مرة كل شهر، استعِد خدمة واحدة تمثيلية إلى بيئة اختبار معزولة، وشغّلها، وسجّل الدخول، وافحص السجلات والمرفقات، وتأكّد أن التطبيق يتصرّف على نحو طبيعي. فسرد الملفات المستعادة لا يثبت سوى أن الأرشيف قابل للقراءة، لا أن قاعدة البيانات والوحدات التخزينية والأذونات وحالة التطبيق يمكن استرجاعها بنجاح.
خلاصة القسم الرئيسية: يؤدي GlitchTip جوهر مهمة تتبّع الأخطاء بنشر أصغر بكثير من Sentry المستضاف ذاتيًا، لكن تحقّق من ميزات Sentry وتكاملاته التي يستخدمها فريقك فعلًا.
الطبقة 4، التوثيق: Docmost وAFFiNE وتتبّع المهام عبر OpenProject أو Plane
واجهة Notion جيدة، إلى أن تجعل الويكي المتنامية التنقّل والبحث يبدوان بطيئين. والتقسيم الموصى به لفريق صغير هو Docmost للتوثيق والويكي، مع OpenProject لتتبّع المهام. واستبدل OpenProject بـ Plane إن كان فريقك يريد تحديدًا نموذجًا بصريًا على غرار Linear، ولا يمانع في إدارة نشره الذاتي المدعوم.
Docmost هنا هو أقرب بديل مستضاف ذاتيًا لـ Notion، من دون أن يتظاهر بأنه Notion. فمحرّره القائم على الكتل وتسلسل صفحاته وأذونات الفرق فيه تناسب ويكي داخلية تقليدية. حدّد حجم هذه الطبقة بحسب عدد المحرّرين المتزامنين والمرفقات، وما إذا كان PostgreSQL وRedis يتشاركان المضيف نفسه. أما AFFiNE فهو البديل للفرق التي تفضّل نموذج اللوحة والسبورة على الصفحات المتداخلة. وكلاهما معقول؛ فاختر واحدًا.
يغطّي OpenProject مهمة تتبّع المهام للفرق المرتاحة لسير عمل بنكهة Jira: الملاحم وحزم العمل والدورات وتتبّع الوقت. أما Plane فهو البديل على غرار Linear، بواجهة أسرع تتمحور حول المهام وببصمة تشغيلية مختلفة.
لنعترف بصدق: سرعة Linear المعتمدة على لوحة المفاتيح جيدة فعلًا، وPlane لا يعيد إنتاج كل تفاعل فيها. وإن كان سير عمل فريقك قائمًا على ذاكرة العضلات في قائمة أوامر Linear، فاحتكاك الترحيل حقيقي. وهذا ليس بالضرورة عائقًا حاسمًا، لكنه كلفة حقيقية.
خلاصة القسم الرئيسية: يتكفّل Docmost بدور التوثيق الداخلي، بينما يتكفّل OpenProject أو Plane بتتبّع المهام؛ وتظل الفجوة في تجربة لوحة المفاتيح مقارنةً بـ Linear هي الموضع الوحيد الذي تطلب فيه هذه الطبقة منك تنازلًا.
كم تكلّف هذه الحزمة وعلى أي شيء تعمل
نقطة البداية العملية للحزمة الكاملة القائمة على Forgejo في صندوق واحد هي نحو 8 وحدات معالجة افتراضية و16 غيغابايت من الذاكرة. اعتبر وحدتين و4 غيغابايت حجمًا مخبريًا لبضع خدمات خفيفة، و4 وحدات و8 غيغابايت تجربة مصغّرة تستغني عن OpenProject وPlane وعمليات البناء المحلية. وتتوقف المتطلبات الفعلية على المستخدمين المتزامنين ونشاط التكامل المستمر ونمو قواعد البيانات والمرفقات وتخزين الصور والسجلات ومدة الاحتفاظ، فتحقّق من الحزمة تحت حِمل حقيقي وأبقِ 20 إلى 30% من السعة حرة. ويمكن لمستوى البداية البالغ 16 غيغابايت أن يستوعب الخدمات التالية لفريق من مطوّرَين إلى ثلاثة بحمل خفيف، رهنًا باختبار الأحمال:
- Forgejo
- Coolify
- Vaultwarden
- Uptime Kuma
- GlitchTip
- Docmost
- OpenProject
- Dockge
خادم بسعة 4 غيغابايت لا يصلح إلا لبضع خدمات خفيفة. أما الخادم بسعة 8 غيغابايت فالأفضل التعامل معه كتجربة مصغّرة بلا OpenProject أو Plane أو عمليات بناء محلية. ابدأ الحزمة الكاملة القائمة على Forgejo عند 16 غيغابايت، وأضف سعة عند تشغيل GitLab أو عمليات بناء متزامنة أو Plane أو مدد احتفاظ طويلة أو أحمال قواعد بيانات أثقل. وتضم حزمة SaaS للفريق نفسه:
- GitHub Team
- Vercel Pro
- Sentry
- Linear
- Notion
- 1Password
باعتماد الأسعار الأساسية المنشورة على كل صفحة تسعير (بما فيها أسعار الفوترة السنوية حيثما انطبقت). وتبلغ المنتجات الخمسة المسعّرة نحو 158 دولارًا شهريًا لثلاثة أشخاص: GitHub Team بـ 4 دولارات لكل مستخدم خلال أول 12 شهرًا، وثلاثة مقاعد مطوّرين في Vercel Pro بـ 20 دولارًا للمقعد، Sentry Team ابتداءً من 26 دولارًا، Linear Basic بـ 10 دولارات لكل مستخدم، و Notion Plus بـ 10 دولارات لكل مستخدم. أما رسوم الاستخدام والضرائب والإضافات و1Password فتُحتسب إضافةً إلى ذلك. ويمكن للبنية التحتية أن تظل أرخص بفارق ملموس، لكن المقارنة بلا معنى من دون احتساب وقت المشغّل.
متى تزيد الحجم: أساس GitLab على عقدة واحدة هو 8 وحدات معالجة افتراضية و16 غيغابايت من الذاكرة. وقد تتطلّب عمليات البناء المتزامنة سعة إضافية حتى من دون GitLab. كما يبدأ Sentry المستضاف ذاتيًا عند 16 غيغابايت من الذاكرة إضافة إلى 16 غيغابايت من ذاكرة التبديل، ويوصي بـ 32؛ ولهذا يوصي هذا الدليل بـ GlitchTip لحزمة الصندوق الواحد.
الكلفة غير المسعّرة هي وقت التشغيل. وللتخطيط، خصّص ساعة إلى ساعتين شهريًا للتحديثات والتحقق من النسخ الاحتياطية، إضافة إلى تصفّح أسبوعي قصير للتنبيهات الأمنية للمشاريع التي تشغّلها. أما الرقم الحقيقي فيتوقف على حجم التغييرات والاستجابة للحوادث ومقدار ما تؤتمته. وهو ليس صفرًا، ومكانه في نموذج التكلفة.
طريقة النشر تغيّر مستوى الراحة، لا متطلبات التشغيل. وسواء استخدمت ملف Compose رسميًا أو قالبًا من متجر التطبيقات، ثبّت إصدارات الصور، وحدّد حدود المعالج والذاكرة، واحفظ بيانات الخدمات في وحدات تخزين مسمّاة، واختبر النسخ الاحتياطي والاستعادة معًا. كما أن جمع الحزمة كاملة على مضيف واحد يخلق نطاق فشل مشتركًا، فاعزل الخدمات الحرجة حين يكون أثر التوقف أو انكشاف بيانات الاعتماد كبيرًا.
إن أردت نشر هذه الحزمة، فقارن بين خطط cloud VPS السحابية لدينا من حيث المعالج والذاكرة والتخزين SSD أو NVMe وحصة النقل والمنطقة، ثم طبّق إطار تحديد الحجم أعلاه. وللإعداد الأسرع، تصفّح كتالوج التطبيقات بنقرة واحدة، لكن ثبّت الإصدارات على أي حال، وحدّد حدود الموارد، وتحقّق من النسخ الاحتياطية قبل الإنتاج.
خلاصة القسم الرئيسية: استخدم 4 غيغابايت لمختبر صغير، و8 غيغابايت لتجربة مصغّرة، ونحو 8 وحدات معالجة افتراضية مع 16 غيغابايت من الذاكرة كنقطة بداية عملية للحزمة الكاملة القائمة على Forgejo. وأضف سعة من أجل GitLab وعمليات البناء المتزامنة وأدوات إدارة المشاريع الأثقل وقواعد البيانات المتنامية.
أين تفشل الاستضافة الذاتية لهذه الحزمة فعلًا
أربعة أنماط للفشل، نسمّيها بصراحة، لأن بقية هذا الدليل كانت حجّة لصالح هذا النهج.
نمط الفشل 1: أثر الشبكة لدى GitHub في المشاريع مفتوحة المصدر العامة. الـ git المستضاف ذاتيًا هو الخيار الصحيح للشيفرة الخاصة. وهو الخيار الخاطئ لمشاريع تتوقف قيمتها كلها على أن يعثر عليك مساهمون خارجيون. فـ GitHub هو أول مكان ينظر إليه المطوّرون: طلبات السحب، والتفريعات، والنجوم، وإشارة الثقة الضمنية بأنك على github.com، وتكاملات الأدوات من أطراف ثالثة، كل ذلك. وإن كان مشروعك مفتوح المصدر وعامًا، فالنمط الصادق هو إنشاء مرآة على GitHub من أجل الظهور مع إبقاء مصدر الحقيقة على Forgejo. لا تتوقّع أن تحلّ نسخة مستضافة ذاتيًا محل قابلية الاكتشاف في GitHub بالنسبة للعمل العام. لن تفعل.
نمط الفشل 2: حركة الروبوتات وأدوات الكشط على خوادم Git العامة. تحتاج خدمات Forgejo وGitea المكشوفة للعامة إلى ضوابط ضد إساءة الاستخدام وحدود للمعدّل ومراقبة وسعة كافية لحركة لا يمكن التنبّؤ بها. ويفترض هذا الدليل استخدامًا خاصًا وجماعيًا، مع إبقاء سطح الإدارة خلف شبكة افتراضية خاصة أو قائمة عناوين IP مسموح بها. أما المِصهر العام فعلًا فله نموذج تهديد وسعة مختلف.
نمط الفشل 3: عبء الصيانة. «أنت قسم تقنية المعلومات» عبارة مبتذلة، لكنها صحيحة في معظمها. فالتحديثات تكسر أشياء. وملفات Compose تنجرف. والشهادات تنتهي صلاحيتها. والنسخ الاحتياطية تُخفق بصمت وبأكثر الطرق إهانة. وتنبيهات Coolify لعام 2026 تذكير مفيد بأن وتيرة التصحيح مهمة. وإن لم تستطع الالتزام بنافذة صيانة قبل أن تمضي قدمًا، فحزمة SaaS هي بصراحة الإجابة الصحيحة.
نمط الفشل 4: فقدان التكاملات. إجراءات GitHub من أطراف ثالثة، وعمليات نشر المعاينة في Vercel المرتبطة بطلبات السحب في GitHub، وتكاملات التنبيه المستضافة لدى Sentry مع PagerDuty وLinear، وكتالوج التكاملات الواسع في Notion. لمعظمها مكافئات مستضافة ذاتيًا (Forgejo Actions، ونشر Coolify عبر webhooks، وإشعارات GlitchTip، وn8n كصمغ بين سير العمل)، لكن البدائل ليست دائمًا واحدًا بواحد. جرّب نموذجًا أوليًا لسير العمل الأهم قبل أن تدفع الفريق إلى الترحيل. فالتكامل الذي تعدّه أمرًا مفروغًا منه هو الأرجح أن يفاجئك.
خلاصة القسم الرئيسية: تعمل هذه الحزمة مع الشيفرة الخاصة والفرق الصغيرة والمشغّلين الراغبين؛ ولا تعمل مع ظهور المصادر المفتوحة العامة، ولا مع الفرق التي لا تريد التدخّل، ولا مع توقّعات انعدام الصيانة.
حزمة المشغّل
أربع طبقات، وأربع توصيات، بأسماء صريحة. الشيفرة: Forgejo. البناء والنشر: Coolify مع تقييد مستوى الإدارة، أو Dokku، أو Compose. التشغيل: Vaultwarden وUptime Kuma وGlitchTip وPortainer أو Dockge. التوثيق: Docmost وOpenProject (أو Plane). ابدأ التجربة المصغّرة عند 8 غيغابايت، والحزمة الكاملة القائمة على Forgejo عند 16 غيغابايت. وأضف سعة من أجل GitLab أو عمليات البناء المتزامنة أو قواعد البيانات الأثقل أو الحِمل التطبيقي المستمر.
إن كنت ترحّل، فابدأ بـ Uptime Kuma وخدمة داخلية غير حرجة. فهما يتيحان طريقة أقل مخاطرة لتعلّم إيقاع التشغيل (التحديثات والمراقبة والتحقق من النسخ الاحتياطية وتجديد الشهادات) قبل نقل سير عمل جماعي أو مخزن بيانات اعتماد. ولا تجعل Vaultwarden أول نشر تجريبي: لا تنقله إلا بعد توفّر نسخ احتياطية مشفّرة خارج المضيف، واختبار استعادة ناجح، وإدارة مقيّدة، ومصادقة متعددة العوامل. ومتى صار ذلك الإيقاع موثوقًا، انتقل إلى Forgejo، ثم Coolify، ثم البقية.
أما الفرق التي تختار GitLab CE تحديدًا فعليها أن تقرّر ما إذا كان تكامله المستمر المدمج يغني عن منفّذ منفصل، أم أن عبء عملها ما زال يحتاج سعة بناء مخصصة.
الأسئلة الشائعة
ما أفضل بديل مستضاف ذاتيًا لـ Gitea في 2026؟
Forgejo هو الخيار الموصى به للمبتدئين في الاستضافة الذاتية عام 2026. فنقل علامة Gitea التجارية ونطاقه في أكتوبر 2022 إلى شركة ربحية من دون موافقة مسبقة من المجتمع هو ما دفع إلى اشتقاق Forgejo أواخر 2022. وابتداءً من v9.0 تصدر إصدارات Forgejo برخصة GPL v3+؛ أما إصدارات التصحيح الأسبق v8.0 وv7.0 فبقيت تحت MIT. وفي الاستخدام اليومي، تكافؤ الميزات قريب.
هل يمكن تشغيل Coolify بأمان في الإنتاج عام 2026؟
نعم، لكن بشرط الصيانة النشطة والدفاع المتعدد الطبقات. شغّل أحدث إصدار مستقر مراجَع، وراقب التنبيهات الجديدة، وقيّد أذونات الفريق، وأبقِ لوحة التحكم وواجهة البرمجة خلف جدار ناري أو شبكة افتراضية خاصة أو طبقة وصول موثوقة. ولا تعامل beta.451 أو beta.474 أو أي مستوى تصحيح تاريخي آخر كعتبة أمان دائمة.
كم من الذاكرة تحتاج فعلًا حزمة تطوير كاملة مستضافة ذاتيًا؟
لفريق من مطوّرَين إلى ثلاثة، اعتبر 4 غيغابايت حجمًا مخبريًا لبضع خدمات خفيفة، و8 غيغابايت تجربة مصغّرة بلا OpenProject أو Plane أو عمليات بناء محلية. ونحو 8 وحدات معالجة افتراضية و16 غيغابايت من الذاكرة هي نقطة البداية العملية للحزمة الكاملة القائمة على Forgejo. وأساس GitLab البالغ 8 وحدات و16 غيغابايت ينطبق على GitLab نفسه، بينما يشترط Sentry المستضاف ذاتيًا 16 غيغابايت من الذاكرة إضافة إلى 16 غيغابايت من ذاكرة التبديل، ويوصي بـ 32. وتحقّق من التهيئة النهائية تحت ظروف عبء عمل حقيقي.
لماذا GlitchTip بدل Sentry المستضاف ذاتيًا؟
الفارق في الموارد والتشغيل. فـ Sentry المستضاف ذاتيًا يشترط 16 غيغابايت من الذاكرة على الأقل إضافة إلى 16 غيغابايت من ذاكرة التبديل، وهو نشر كبير متعدد الخدمات. أما GlitchTip فيوصي بـ 512 ميغابايت لخدمته الشاملة، ويشترط PostgreSQL، ويجعل Valkey اختياريًا. وهو يستقبل حركة حزم تطوير Sentry، لكن تكافؤ الميزات ليس تامًا، فاختبر الميزات والتكاملات التي تعتمد عليها.
كم تكلّف هذه الحزمة فعلًا مقارنةً بمكافئاتها من SaaS؟
اعتبر 4 غيغابايت حجمًا مخبريًا لبضع خدمات خفيفة، و8 غيغابايت تجربة مصغّرة بلا OpenProject أو Plane أو عمليات بناء محلية. ونحو 8 وحدات معالجة افتراضية و16 غيغابايت من الذاكرة هي نقطة البداية العملية للحزمة الكاملة القائمة على Forgejo. وبالأسعار الأساسية المنشورة، يبلغ مجموع GitHub Team وVercel Pro وSentry Team وLinear Basic وNotion Plus نحو 158 دولارًا شهريًا لثلاثة أشخاص، قبل 1Password ورسوم الاستخدام والضرائب والإضافات. وقد تكون الاستضافة الذاتية أرخص بفارق ملموس، لكن وقت المشغّل وبنية النسخ الاحتياطي تكاليف حقيقية.
