لماذا تستضيف 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
تجهيز خادم VPS وDocker
اتصل عبر SSH، وحدّث النظام ثم ثبّت Docker وإضافة Compose. أنشئ مجلدًا مخصّصًا:
mkdir -p /opt/gitea && cd /opt/gitea. أنشئ أيضًا وحدة تخزين بيانات تبقى بعد تحديثات الحاوية.كتابة ملف docker-compose.yml
عرّف خدمتين:
gitea (الصورةgitea/gitea:1.25) وقاعدة بياناتpostgres:16. ركّب./gitea:/dataللاستمرارية، واضبطUSER_UID/USER_GIDعلى 1000، واربط SSH الخاص بـGitea بمنفذ المضيف 2222:"2222:22". اترك منفذ HTTP رقم 3000 داخليًا، فسيخدمه reverse proxy.تشغيل الحاويات
نفّذ
docker compose up -dثمdocker compose logs -f giteaلمتابعة عملية التهيئة. تحقّق من نجاح الاتصال بـPostgreSQL قبل المتابعة.إعداد 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.إنهاء التثبيت عبر الويب
افتح
https://git.yourdomain.com، وأكمِل المعالج بإدخال عنوان URL الأساسي بصيغة HTTPS ومضيف قاعدة البيانات (db:5432). اضبط ROOT_URL بشكل صحيح، وإلا ستكون روابط الاستنساخ خاطئة. وسّع قسم «Optional Settings > Administrator Account Settings»، وأنشئ فيه حساب المسؤول الخاص بك، ثم أكّد.تأمين SSH الخاص بالمستودعات
اضبط عملاءك للاستنساخ عبر
ssh://[email protected]:2222/...، أو أضِف كتلة Host في~/.ssh/configلإخفاء المنفذ. عطّل التسجيل العام في لوحة الإدارة إذا كانت المنصة خاصة.
Gitea Actions: نظام CI/CD ذاتي الاستضافة على VPS
Gitea Actions هو محرك CI/CD الأصلي لـGitea، متوافق مع صياغة مسارات عمل GitHub Actions. يتيح تشغيل المسارات مباشرةً على بنيتك التحتية دون أي تبعية لخدمة خارجية.
لتفعيله، أضِف إلى ملف app.ini:
[actions]
ENABLED = trueثم سجّل runner باسم act_runner في حاوية منفصلة على خادم VPS نفسه. حُدّ ذاكرته عبر mem_limit كي لا يخنق بناءٌ ثقيل Gitea نفسها. للمسارات الثقيلة (التصريف واختبارات التكامل)، خصّص بدلًا من ذلك خادم VPS ثانيًا للـrunner.
مسار عمل أدنى لمشروع Node.js يُوضع في .gitea/workflows/ci.yml:
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm ci
- run: npm testيُنفِّذ الـrunner هذا المسار عند كل push. يمكنك الجمع بين مهام متعددة، واستخدام مصفوفات الإصدارات، ومشاركة القطع الأثرية بين الخطوات — تمامًا كـGitHub Actions، لكن على خادمك الخاص.
حُدّ ذاكرة الحاوية act_runner بـ2 غيغابايت عبر mem_limit: 2g في ملف docker-compose.yml إذا كان خادم VPS يملك 4 غيغابايت إجمالًا. بهذه الطريقة، حتى لو استنفد بناءٌ ما كل الذاكرة المخصَّصة له، تبقى 2 غيغابايت لـGitea — كافية لمواصلة استقبال عمليات الدفع وطلبات السحب أثناء التصريف. للبناءات التي تنتج قطعًا أثرية ضخمة (صور Docker وملفات ثنائية)، أضِف وحدة تخزين منفصلة مثبَّتة على /home/runner/work تفاديًا لامتلاء وحدة تخزين Gitea الرئيسية.
Gitea أم Forgejo في 2026: أيهما تختار؟
مرّر الجدول أفقيًا
| المعيار | Gitea 1.25 | Forgejo v16 |
|---|---|---|
| الحوكمة | شركة تجارية (Gitea Ltd) | جمعية غير ربحية (Codeberg e.V.) |
| الرخصة | MIT | MIT — برمجيات حرة 100٪ دون إصدار مؤسسي |
| موصى به من Awesome-Selfhosted | لا (حُذف في 2022) | نعم — التوصية الافتراضية منذ 2024 |
| تفدير ActivityPub | غير مخطط | يُنشر تدريجيًا منذ Forgejo v7 (أبريل 2024)، GA في v16 |
| توافق واجهة برمجة Gitea | المرجع | متوافق: نفس الـAPI ونفس الـwebhooks ونفس تنسيق البيانات |
| الأمان — تدقيقات علنية | نادرة | تدقيقات شيفرة منشورة من مجتمع Codeberg |
| خارطة الطريق المجتمعية | تقودها Gitea Ltd | حوكمة مفتوحة، RFC علنية، تصويت المساهمين |
| الهجرة من Gitea | — | دون فقدان بيانات: نفس مخطط القاعدة ونفس تنسيق الحجم |
الهجرة من Gitea إلى Forgejo
نسخ احتياطي كامل لـGitea
قبل أي عملية، أنجز dump كاملًا:
docker exec -u git gitea gitea admin dump -c /data/gitea/conf/app.ini. استرجع الأرشيف المُنتَج خارج الحاوية وتحقّق من أن الحجم./giteaمُدرج في لقطة (snapshot) خادم VPS.التحقق من توافق الإصدار
يدعم Forgejo v16 الهجرة من Gitea 1.20 وما بعده. إذا كانت منصتك تشغّل إصدارًا أقدم، فارقَ أولًا إلى Gitea 1.21 أو 1.22 عبر
docker compose pull && docker compose up -d، ثم تحقّق من غياب الأخطاء في السجلات قبل المتابعة.استبدال صورة Docker
في ملف
docker-compose.yml، استبدلimage: gitea/gitea:latestبـimage: codeberg.org/forgejo/forgejo:latest. يبقى حجم البيانات (./gitea:/data) وقاعدة PostgreSQL دون تغيير — يقرأ Forgejo نفس المخطط ونفسapp.ini.إعادة التشغيل والسماح بالهجرة
نفّذ
docker compose pull && docker compose up -d. يطبّق Forgejo تلقائيًا ترحيلات المخطط اللازمة عند بدء التشغيل. تابعdocker compose logs -f forgejoحتى تظهر رسالة تفيد بأن خادم HTTP يستمع على المنفذ 3000.إعادة توليد مفاتيح SSH
كما في أي ترقية تغيّر الملف التنفيذي المُشار إليه في
authorized_keys، أعِد توليد المدخلات:docker exec -u git forgejo forgejo admin regenerate keys. تحقّق بعد ذلك من نجاحgit cloneعبر SSH من جهاز عميل.الاختبار والتحقق
افتح واجهة الويب، وتحقّق من المستودعات والـwebhooks وعمليات Forgejo Actions. تُعدّ runners الـ
act_runnerالمسجَّلة تحت Gitea متوافقة — أعِد ربطها برمز التسجيل الجديد إذا تغيّر المفتاح.
Forgejo v16: أبرز المستجدات (يوليو 2026)
يُتيح Forgejo v16.0.0 تفدير ActivityPub بشكل عام للـissues وطلبات السحب: يمكن لـissue مفتوحة على منصة Forgejo أن تستقبل تعليقات من مستخدمي منصة أخرى دون حساب مشترك. يتضمّن الإصدار أيضًا مدير أسرار على مستوى النسخة (تشفير AES-256 أثناء التخزين)، ومحرك بحث جديد في الشيفرة مبني على Bleve v2 مع دعم التعبيرات النمطية، وتحسينات جوهرية في مجدول المهام الخلفية. على صعيد الأمان، تُخزَّن رموز API الآن بشكل مُجزَّأ في قاعدة البيانات (bcrypt) بدلًا من النص الصريح — ترحيل تلقائي عند بدء التشغيل يحوّل الرموز الموجودة.
الإدارة اليومية: الـwebhooks والمستودعات وحذف الأيتام
بمجرد أن تعمل Gitea في الإنتاج، تعود بعض عمليات الصيانة بانتظام.
إدارة الـwebhooks. تسجّل Gitea تاريخ كل إرسال في «إعدادات المستودع → Webhooks → آخر التسليمات». يمكن إعادة تشغيل webhook فاشل (مهلة انتهت أو خطأ HTTP 5xx) يدويًا من هذا السجل. إذا كانت runners تعمل على الشبكة الخاصة نفسها لـGitea، أضِف نطاقاتها IP إلى ALLOWED_HOST_LIST في قسم [webhook] من app.ini — وإلا تُحجب الاستدعاءات نحو localhost افتراضيًا منذ Gitea 1.20.
حذف المستودعات الأيتام. مستودع محذوف عبر الواجهة يترك بيانات Git الخاصة به (objects/) على القرص حتى تشغيل مهام الخلفية التالية. أجبر التشغيل الفوري من لوحة الإدارة: «إدارة الموقع → مهام الخلفية → تشغيل: حذف المستودعات المحذوفة». لا يظهر الفضاء المحرَّر إلا بعد docker exec -u git gitea gitea admin storage --remove-unlisted.
حصة التخزين لكل مؤسسة. للنسخ متعددة المستأجرين، حدّد حصة مستودعات لكل مؤسسة في app.ini ضمن [repository]: MAX_CREATION_LIMIT = 50. هذا يمنع حسابًا من إنشاء مئات المستودعات دون رقابة وملء وحدة التخزين.
استكشاف أخطاء متقدم: SSH واستنساخ HTTPS
Permission denied (publickey) بعد ترقية. تغيّر مسار الملف التنفيذي المُشار إليه في authorized_keys (ثابت في الإصدار 1.27). تستجيب خدمة Gitea بشكل طبيعي عبر HTTPS مما يُخفي المشكلة. الإصلاح: docker exec -u git gitea gitea admin regenerate keys. تحقّق من نجاح git clone عبر SSH قبل إعلان اكتمال الترقية.
مهلة أو خطأ SSL عند الاستنساخ عبر HTTPS. ثلاثة أسباب شائعة: لا يتطابق ROOT_URL في app.ini مع النطاق الفعلي (روابط معطوبة + حلقة إعادة توجيه محتملة)، أو لا يُمرِّر الـreverse proxy ترويسة X-Forwarded-Proto: https (فتولّد Gitea عناوين URL بـHTTP)، أو انتهت صلاحية شهادة Let's Encrypt (يجدّدها Caddy وcertbot تلقائيًا لكن فقط إذا كان DNS يشير إلى VPS). تحقّق من ROOT_URL أولًا: هو السبب الأكثر شيوعًا بعد هجرة النطاق.
استنساخ SSH بطيء أو يتعلّق. يستخدم upload-pack عبر SSH نفس عملية Git التي تخدم العمليات عبر الويب. إذا كان act_runner يشغل كل أنوية المعالج المتاحة أثناء بناء، قد تجد عمليات Git نفسها في انتظار الموارد. أضِف cpus: '1.5' للـrunner في ملف compose لتخصيص أنوية له دون حرمانه كليًا.
Database migration failed: column already exists. تلقّت قاعدة البيانات ترحيلًا جزئيًا (توقف في منتصف الترقية). استعِد الـdump المُنجَز قبل الترقية، ابدأ من حجم نظيف، ثم أعِد التشغيل.
الترقية إلى Gitea 1.27 دون فقدان وصول SSH
يغيّر الإصدار 1.27 المسار الداخلي للملف التنفيذي gitea المُدرج في authorized_keys. عند الترقية، تشير المدخلات الموجودة إلى المسار القديم: يفشل كل استنساخ أو دفع عبر SSH بصمت برسالة Permission denied (publickey)، دون أي رسالة خطأ من جهة الخادم تشير إلى الترقية. بعد كل ترقية إلى الإصدار 1.27 (أو إلى أي إصدار يغيّر هذا المسار)، نفّذ داخل الحاوية: docker exec -u git gitea gitea admin regenerate keys. تُعيد هذه الأمر كتابة جميع مدخلات authorized_keys بالمسار الصحيح للملف التنفيذي. تحقّق بعد ذلك من نجاح git clone عبر SSH قبل إعلان اكتمال الترقية.
لا يجوز أن يتعايش JWT_SECRET_URI وJWT_SECRET في ملف app.ini. إذا كان كلا المفتاحَين موجودَين، يحمِّل Gitea أو Forgejo أحدهما أو الآخر بحسب ترتيب القراءة، فيُبطل بصمت جميع رموز OAuth2 وأعمال Actions الصادرة قبل الترقية. يرى المستخدمون أخطاء مصادقة متقطعة دون أي رسالة تُشير إلى app.ini بوصفه السبب. اختَر آليةً واحدة: JWT_SECRET (قيمة نصية صريحة) أو JWT_SECRET_URI (مسار إلى ملف سري)، ثم احذف الأخرى. أعِد تشغيل الحاوية بعد التعديل.
للمضي أبعد: Forgejo وCI/CD المتقدم
إذا أردت توسيع الأتمتة حول منصة Git الخاصة بك، يُفصّل مقال استضافة Forgejo على خادم VPS إعداد نسخة Forgejo مع runners مخصّصة لـActions، وضبط سجل OCI المدمج، وتصليب الأمان (fail2ban، تقييد نطاقات IP). للفرق التي تريد سلسلة نشر مستمر متكاملة، هذا المقال هو الامتداد الطبيعي لهذا الدليل.
الوثائق الرسمية
للإعداد المتقدّم والخيارات الخاصة بالأداة، ارجع إلى الوثائق الرسمية لـGitea أو وثائق Forgejo. يغطّي هذا الدليل النشر على خادم VPS والهجرة؛ وتبقى وثائق الناشرَين المرجعَ للضبط الدقيق وحالات الاستخدام الخاصة.
