دليل النشر

استضافة Gitea على خادم VPS الخاص بك في 2026

انشر على VPS Cloud ←

دليل عملي

استضافة Gitea على خادم VPS الخاص بك في 2026

الاستضافة الذاتية8 دقائق للقراءةعدد الخطوات: 13

‏Gitea‏ هي منصة Git ذاتية الاستضافة مكتوبة بلغة Go، معروفة بخفّتها وسرعتها. نشرها على خادم VPS الخاص بك يمنحك GitHub خاصًا دون اشتراك لكل مستخدم ودون حدّ على المستودعات الخاصة. في عام 2026، رسّخ ‏Forgejo v16‏ نفسه بوصفه الفرع المجتمعي المرجعي — يغطّي هذا الدليل تثبيت ‏Gitea‏ والمقارنة مع ‏Forgejo‏ وخطوات الهجرة.

المحتويات· لماذا تستضيف Gitea ذاتيًا على خادم VPS1/10
  1. 01لماذا تستضيف Gitea ذاتيًا على خادم VPS
  2. 02فوائد ملموسة لـGitea ذاتية الاستضافة
  3. 03المتطلبات العتادية والبرمجية
  4. 04نشر Gitea مع Docker وSSL
  5. 05Gitea أم Forgejo في 2026: أيهما تختار؟
  6. 06الهجرة من Gitea إلى Forgejo
  7. 07‏Forgejo v16‏: أبرز المستجدات (يوليو 2026)
  8. 08الترقية إلى Gitea 1.27 دون فقدان وصول SSH
  9. 09استكشاف الأخطاء: أخطاء شائعة أثناء الهجرة
  10. 10الوثائق الرسمية

لماذا تستضيف Gitea ذاتيًا على خادم VPS

تستهلك ‏Gitea‏ بالكاد من 200 إلى 300 ميغابايت من الذاكرة (RAM) في وضع الخمول، ما يجعلها من أكفأ منصات Git للاستضافة الذاتية. على خادم VPS، تحتفظ بالسيطرة الكاملة على شيفرتك المصدرية: لا يحلّل أي طرف ثالث بياناتك، ولا حدّ اعتباطي على عدد المستودعات الخاصة أو المتعاونين، ولا تكلفة تتصاعد مع فريقك. لوكالة أو مطوّر مستقل، يمكن لخادم VPS واحد أن يستضيف مجمل مشاريع العملاء بأذونات مقسَّمة حسب المؤسسة. تتضمّن ‏Gitea‏ أصلًا نظام CI/CD متوافقًا مع مسارات عمل ‏GitHub Actions‏ (‏Gitea Actions‏)، وسجلّ حزم، ومحرّرًا عبر الويب، ما يغطّي شبه كامل دورة التطوير دون تبعية خارجية.

فوائد ملموسة لـGitea ذاتية الاستضافة

  • بصمة ذاكرة ضئيلة: تعمل بأريحية على خادم VPS بذاكرة 2 غيغابايت حتى مع عشرات المستخدمين.
  • مستودعات خاصة دون فوترة لكل مقعد أو حدود مفروضة، خلافًا لعروض SaaS.
  • ‏Gitea Actions‏ مدمج لتشغيل مسارات CI/CD الخاصة بك دون خدمة خارجية.
  • سجلّ حزم (‏Docker‏ و‏npm‏ و‏Composer‏ و‏Maven‏) مستضاف على المنصة نفسها.
  • مصادقة دقيقة: ‏LDAP‏ و‏OAuth2‏ ورموز وصول شخصية ومفاتيح SSH لكل مستخدم.
  • نسخ احتياطي بسيط للغاية: كل شيء يتّسع في وحدة تخزين بيانات وقاعدة بيانات.

المتطلبات العتادية والبرمجية

‏Gitea‏ مقتصدة للغاية. لفريق صغير (حتى 20 مستخدمًا)، يكفي خادم VPS بمعالجَين افتراضيَّين (2 vCPU) و2 غيغابايت من الذاكرة (RAM)؛ احسب 4 غيغابايت إذا فعّلت ‏Gitea Actions‏ مع ‏runners‏ محلية تصرّف الشيفرة. خصّص ما لا يقل عن 20 إلى 40 غيغابايت من تخزين SSD بحسب حجم مستودعاتك. على الجانب البرمجي: ‏Docker Engine‏ وإضافة ‏Docker Compose‏ مثبَّتتان، واسم نطاق (أو نطاق فرعي مثل git.yourdomain.com) يشير إلى عنوان IP الخاص بخادم VPS عبر سجل A، والمنفذ 22 محجوز لـSSH الخادم — إذ ستعرض ‏Gitea‏ خدمة SSH خاصة بها على منفذ آخر لتفادي التعارض.

نشر Gitea مع Docker وSSL

  1. تجهيز خادم VPS وDocker

    اتصل عبر SSH، وحدّث النظام ثم ثبّت ‏Docker‏ وإضافة ‏Compose‏. أنشئ مجلدًا مخصّصًا: mkdir -p /opt/gitea && cd /opt/gitea. أنشئ أيضًا وحدة تخزين بيانات تبقى بعد تحديثات الحاوية.

  2. كتابة ملف docker-compose.yml

    عرّف خدمتين: ‏gitea‏ (الصورة gitea/gitea:latest) وقاعدة بيانات postgres:16. ركّب ./gitea:/data للاستمرارية، واضبط USER_UID/USER_GID على 1000، واربط ‏SSH‏ الخاص بـ‏Gitea‏ بمنفذ المضيف 2222: "2222:22". اترك منفذ HTTP رقم 3000 داخليًا، فسيخدمه ‏reverse proxy‏.

  3. تشغيل الحاويات

    نفّذ docker compose up -d ثم docker compose logs -f gitea لمتابعة عملية التهيئة. تحقّق من نجاح الاتصال بـ‏PostgreSQL‏ قبل المتابعة.

  4. إعداد reverse proxy

    مع ‏Caddy‏، يكفي سطر واحد: git.yourdomain.com { reverse_proxy localhost:3000 }. يحصل ‏Caddy‏ تلقائيًا على شهادة ‏Let's Encrypt‏ ويجدّدها. مع ‏Nginx‏، أنشئ كتلة ‏server‏ تُمرّر الطلبات إلى http://127.0.0.1:3000 واستخدم certbot --nginx لـSSL.

  5. إنهاء التثبيت عبر الويب

    افتح https://git.yourdomain.com، وأكمِل المعالج بإدخال عنوان URL الأساسي بصيغة HTTPS ومضيف قاعدة البيانات (db:5432). اضبط ‏ROOT_URL‏ بشكل صحيح، وإلا ستكون روابط الاستنساخ خاطئة.

  6. تأمين SSH الخاص بالمستودعات

    اضبط عملاءك للاستنساخ عبر ssh://[email protected]:2222/...، أو أضِف كتلة ‏Host‏ في ~/.ssh/config لإخفاء المنفذ. عطّل التسجيل العام في لوحة الإدارة إذا كانت المنصة خاصة.

  7. أول تسجيل دخول

    افتح الرابط: يعرض ‏Gitea‏ صفحة التثبيت، وبيانات قاعدة البيانات مملوءة مسبقًا — لا تغيّرها. وسّع قسم ‏«‏Optional Settings > Administrator Account Settings‏»‏، وأنشئ فيه حساب المسؤول الخاص بك، ثم أكّد.

فعّل ‏Gitea Actions‏ منذ التثبيت بإضافة [actions] ENABLED = true إلى ‏app.ini‏، ثم سجّل ‏runner‏ باسم ‏act_runner‏ في حاوية منفصلة على خادم VPS نفسه. حُدّ ذاكرته عبر mem_limit كي لا يخنق بناءٌ ثقيل ‏Gitea‏ نفسها. للمسارات الثقيلة (التصريف واختبارات التكامل)، خصّص بدلًا من ذلك خادم VPS ثانيًا لـ‏runner‏ واربطه برمز التسجيل — تُبقي المنصة سريعة الاستجابة حتى أثناء عمليات البناء.

Gitea أم Forgejo في 2026: أيهما تختار؟

مرّر الجدول أفقيًا

المعيار‏Gitea‏‏Forgejo v16‏
الحوكمةشركة تجارية (‏Gitea Ltd‏)جمعية غير ربحية (‏Codeberg e.V.‏)
الرخصة‏MIT‏‏MIT‏ — برمجيات حرة 100٪ دون إصدار مؤسسي
موصى به من Awesome-Selfhostedلا (حُذف في 2022)نعم — التوصية الافتراضية منذ 2024
تفدير ActivityPubغير مخططيُنشر تدريجيًا منذ ‏Forgejo v7‏
توافق واجهة برمجة Giteaالمرجعمتوافق: نفس الـAPI ونفس الـwebhooks ونفس تنسيق البيانات
الأمان — تدقيقات علنيةنادرةتدقيقات شيفرة منشورة من مجتمع ‏Codeberg‏
خارطة الطريق المجتمعيةتقودها ‏Gitea Ltd‏حوكمة مفتوحة، RFC‏ علنية، تصويت المساهمين
الهجرة من Giteaدون فقدان بيانات: نفس مخطط القاعدة ونفس تنسيق الحجم

الهجرة من Gitea إلى Forgejo

  1. نسخ احتياطي كامل لـGitea

    قبل أي عملية، أنجز dump كاملًا: docker exec -u git gitea gitea admin dump -c /data/gitea/conf/app.ini. استرجع الأرشيف المُنتَج خارج الحاوية وتحقّق من أن الحجم ./gitea مُدرج في لقطة (snapshot) خادم VPS.

  2. التحقق من توافق الإصدار

    يدعم ‏Forgejo v16‏ الهجرة من ‏Gitea 1.20‏ وما بعده. إذا كانت منصتك تشغّل إصدارًا أقدم، فارقَ أولًا إلى ‏Gitea 1.21‏ أو 1.22 عبر docker compose pull && docker compose up -d، ثم تحقّق من غياب الأخطاء في السجلات قبل المتابعة.

  3. استبدال صورة Docker

    في ملف docker-compose.yml، استبدل image: gitea/gitea:latest بـ image: codeberg.org/forgejo/forgejo:latest. يبقى حجم البيانات (./gitea:/data) وقاعدة ‏PostgreSQL‏ دون تغيير — يقرأ ‏Forgejo‏ نفس المخطط ونفس app.ini.

  4. إعادة التشغيل والسماح بالهجرة

    نفّذ docker compose pull && docker compose up -d. يطبّق ‏Forgejo‏ تلقائيًا ترحيلات المخطط اللازمة عند بدء التشغيل. تابع docker compose logs -f forgejo حتى تظهر رسالة تفيد بأن خادم HTTP يستمع على المنفذ 3000.

  5. إعادة توليد مفاتيح SSH

    كما في أي ترقية تغيّر الملف التنفيذي المُشار إليه في authorized_keys، أعِد توليد المدخلات: docker exec -u git forgejo forgejo admin regenerate keys. تحقّق بعد ذلك من نجاح git clone عبر SSH من جهاز عميل.

  6. الاختبار والتحقق

    افتح واجهة الويب، وتحقّق من المستودعات والـwebhooks وعمليات ‏Forgejo Actions‏. تُعدّ ‏runners‏ الـact_runner المسجَّلة تحت ‏Gitea‏ متوافقة — أعِد ربطها برمز التسجيل الجديد إذا تغيّر المفتاح.

‏Forgejo v16‏: أبرز المستجدات (يوليو 2026)

يُتيح ‏Forgejo v16.0.0‏ تفدير ‏ActivityPub‏ بشكل عام للـ‏issues‏ وطلبات السحب: يمكن لـ‏issue‏ مفتوحة على منصة ‏Forgejo‏ أن تستقبل تعليقات من مستخدمي منصة أخرى دون حساب مشترك. يتضمّن الإصدار أيضًا مدير أسرار على مستوى النسخة (تشفير AES-256 أثناء التخزين)، ومحرك بحث جديد في الشيفرة مبني على ‏Bleve v2‏ مع دعم التعبيرات النمطية، وتحسينات جوهرية في مجدول المهام الخلفية. على صعيد الأمان، تُخزَّن رموز API الآن بشكل مُجزَّأ في قاعدة البيانات (‏bcrypt‏) بدلًا من النص الصريح — ترحيل تلقائي عند بدء التشغيل يحوّل الرموز الموجودة.

الترقية إلى Gitea 1.27 دون فقدان وصول SSH

يغيّر الإصدار 1.27 المسار الداخلي للملف التنفيذي ‏gitea‏ المُدرج في ‏authorized_keys‏. عند الترقية، تشير المدخلات الموجودة إلى المسار القديم: يفشل كل استنساخ أو دفع عبر SSH بصمت برسالة ‏Permission denied (publickey)‏، دون أي رسالة خطأ من جهة الخادم تشير إلى الترقية. تستجيب خدمة ‏Gitea‏ بشكل طبيعي عبر HTTPS، مما يُخفي المشكلة. السبب ليس مفتاح المستخدم بل غلاف الأمر الذي تُدرجه ‏Gitea‏ في ‏authorized_keys‏. بعد كل ترقية إلى الإصدار 1.27 (أو إلى أي إصدار يغيّر هذا المسار)، نفّذ داخل الحاوية: docker exec -u git gitea gitea admin regenerate keys. تُعيد هذه الأمر كتابة جميع مدخلات ‏authorized_keys‏ بالمسار الصحيح للملف التنفيذي. تحقّق بعد ذلك من نجاح ‏git clone‏ عبر SSH قبل إعلان اكتمال الترقية.

استكشاف الأخطاء: أخطاء شائعة أثناء الهجرة

Permission denied (publickey)‏ بعد الهجرة إلى ‏Forgejo‏. تغيّر الملف التنفيذي المُشار إليه في ‏authorized_keys‏. أعِد توليد المدخلات: docker exec -u git forgejo forgejo admin regenerate keys.

Database migration failed: column already exists‏. تلقّت قاعدة البيانات ترحيلًا جزئيًا (توقف في منتصف الترقية). استعِد الـ‏dump‏ الكامل من الخطوة الأولى، ابدأ من حجم نظيف، ثم أعِد التشغيل.

الـ‏webhooks‏ لا تُشغَّل بعد الهجرة. يُشدِّد ‏Forgejo v16‏ التحقق من عناوين URL للـ‏webhooks‏: تُحجب عناوين تشير إلى ‏localhost‏ أو نطاقات ‏RFC-1918‏ افتراضيًا. فعّل خيار ‏ALLOWED_HOST_LIST‏ في القسم ‏[webhook]‏ من ‏app.ini‏ إذا كانت ‏runners‏ على الشبكة الخاصة نفسها.

‏act_runner‏ تُبلّغ بـ‏token invalid‏. يُجزِّئ ‏Forgejo v16‏ رموز ‏runners‏ في قاعدة البيانات. احذف الـ‏runner‏ القديم من واجهة الإدارة، وأعِد تسجيله بـact_runner register والرمز الجديد المُولَّد.

لا يجوز أن يتعايش ‏JWT_SECRET_URI‏ و‏JWT_SECRET‏ في ملف ‏app.ini‏. إذا كان كلا المفتاحَين موجودَين، يحمِّل ‏Gitea‏ أو ‏Forgejo‏ أحدهما أو الآخر بحسب ترتيب القراءة، فيُبطل بصمت جميع رموز ‏OAuth2‏ وأعمال ‏Actions‏ الصادرة قبل الترقية. يرى المستخدمون أخطاء مصادقة متقطعة دون أي رسالة تُشير إلى ‏app.ini‏ بوصفه السبب. اختَر آليةً واحدة: ‏JWT_SECRET‏ (قيمة نصية صريحة) أو ‏JWT_SECRET_URI‏ (مسار إلى ملف سري)، ثم احذف الأخرى. أعِد تشغيل الحاوية بعد التعديل.

الوثائق الرسمية

للإعداد المتقدّم والخيارات الخاصة بالأداة، ارجع إلى الوثائق الرسمية لـGitea أو وثائق Forgejo. يغطّي هذا الدليل النشر على خادم VPS والهجرة؛ وتبقى وثائق الناشرَين المرجعَ للضبط الدقيق وحالات الاستخدام الخاصة.

انشُر Gitea أو Forgejo في دقائق على خادم VPS Cloud من ServOrbit

يتيح لك خادمنا VPS Cloud المزوَّد بـDocker مُعَدًّا مسبقًا إقامة منصة Git الخاصة بك مع SSL تلقائي، دون عبث بالنظام. موارد مخصّصة ولقطات (snapshots) وعنوان IP ثابت مضمَّنة.

بحاجة إلى مساعدة؟

تصفّح مركز المساعدة والأسئلة الشائعة، أو تواصل مع فريقنا — معاودة اتصال أو WhatsApp أو بريد إلكتروني. الدعم بـالعربية والفرنسية والإنجليزية.

راسلنا على WhatsAppيُفتح في علامة تبويب جديدة