حزمة استضافة ذاتية على VPS صغير: ما الذي يتسع في 2 GB و4 GB من الذاكرة

باختصار: يشغّل VPS بذاكرة 2 GB بسهولة نواة استضافة ذاتية مكونة من Caddy (reverse proxy مع HTTPS) وVaultwarden (كلمات المرور) وUptime Kuma (المراقبة) وForgejo (git) تحت Docker Compose، مستخدماً نحو 0.6 إلى 1 GB من الذاكرة. أضف Nextcloud وستحتاج إلى 4 GB؛ أو اختر أدوات أخف مثل Syncthing أو File Browser فتبقى 2 GB كافية.

يقدم هذا الدليل ملف Compose عاملاً، وميزانية ذاكرة لكل خدمة، والأمرين اللذين تتجاهلهما معظم إعدادات الاستضافة الذاتية حتى فوات الأوان: النسخ الاحتياطي خارج الموقع، وسطح شبكة مُحكم. تفترض الأوامر Debian 12/13 أو Ubuntu 24.04 مع Docker Engine وإضافة Compose مثبتين من مستودع Docker الرسمي.

ميزانية الذاكرة لكل خدمة

الأرقام هي الذاكرة المقيمة النموذجية في حالة الخمول إلى الاستخدام الخفيف لمستخدم إلى خمسة مستخدمين مع SQLite حيث يُدعم. قد تكون الذروات أعلى أثناء الترقيات، أو استنساخ git لمستودعات كبيرة، أو معاينات Nextcloud، لذا اترك هامشاً لا يقل عن 20% وأضف ملف swap بحجم 1 إلى 2 GB.

اختيار حجم الـ VPS

الحزمة الأساسية (Caddy وVaultwarden وUptime Kuma وForgejo) مع النظام الأساسي تصل إلى نحو 0.6 إلى 1 GB، وهو ما يتسع في خادم 2 vCPU / 2 GB مع مكان لـ Syncthing وRadicale. أما Nextcloud مع MariaDB وRedis فيرفع الإجمالي إلى نحو 1.5 إلى 2.2 GB، لذا فإن 4 GB هي الحد الأدنى الواقعي إن أردت الحزمة الكاملة مع كل شيء آخر. والقرص مهم أيضاً: مستودعات Forgejo والملفات المتزامنة تكبر، بينما الخدمات نفسها لا تحتاج سوى بضعة GB.

في NoctisNode تتسع خطة Pulse (2 vCPU، 2 GB RAM، 40 GB NVMe، $10 لكل 28 يوماً) للحزمة الأساسية، وتتسع Umbra (4 vCPU، 4 GB، 60 GB NVMe، $15 لكل 28 يوماً) للحزمة الأساسية مع Nextcloud. كلتاهما على KVM مع صلاحيات root كاملة وعنوان IPv4 مخصص، ويمكن دفع ثمنهما بـ Monero أو عملات رقمية أخرى. لا شيء في هذا الدليل يعتمد على المزوّد.

ملف Docker Compose

Caddy وحده ينشر منافذ الويب؛ ولا يمكن الوصول إلى التطبيقات إلا عبر شبكة Compose الداخلية. ينشر Forgejo أيضاً المنفذ 2222 لـ git عبر SSH، فيبقى OpenSSH على المضيف على منفذه الخاص. اضبط `FORGEJO_TAG` في ملف `.env` على الإصدار الرئيسي الحالي من Forgejo واستبدل النطاقات المثالية بسجلات DNS الخاصة بك.

# /srv/stack/compose.yaml
services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy/data:/data
      - ./caddy/config:/config

  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"   # set to "false" after creating your account
    volumes:
      - ./vaultwarden:/data

  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./uptime-kuma:/app/data

  forgejo:
    image: codeberg.org/forgejo/forgejo:${FORGEJO_TAG}
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      FORGEJO__service__DISABLE_REGISTRATION: "true"
    volumes:
      - ./forgejo:/data
    ports:
      - "2222:22"

# /srv/stack/Caddyfile
# vault.example.com {
#     reverse_proxy vaultwarden:80
# }
# status.example.com {
#     reverse_proxy uptime-kuma:3001
# }
# git.example.com {
#     reverse_proxy forgejo:3000
# }

التشغيل

1. 01.وجّه سجلات A (وAAAA) لـ `vault` و`status` و`git` إلى عنوان IP للخادم، كي يتمكن Caddy من الحصول على الشهادات عند أول تشغيل.
2. 02.أنشئ `/srv/stack`، وضع فيه `compose.yaml` و`Caddyfile` و`.env`، وشغّل `docker compose up -d`.
3. 03.افتح رابط Forgejo وأكمل المثبّت؛ أول حساب تنشئه عبره يصبح المسؤول، لأن التسجيل العام معطّل.
4. 04.أنشئ حسابك في Vaultwarden، ثم اضبط `SIGNUPS_ALLOWED` على `"false"` وشغّل `docker compose up -d` مجدداً. اترك لوحة الإدارة معطّلة ما لم تضبط `ADMIN_TOKEN` مُجزّأ بـ Argon2.
5. 05.أنشئ مستخدم المسؤول في Uptime Kuma فور التشغيل، لأن صفحة الإعداد مفتوحة لأي أحد حتى تفعل ذلك.
6. 06.أضف مراقبات لكل خدمة ولانتهاء صلاحية الشهادات، ويفضّل من موقع ثانٍ، لأن المراقب على الخادم نفسه لا يستطيع الإبلاغ عن انقطاعه هو.

Note · يتولى Caddy بروتوكول HTTPS تلقائياً. للترويسات وحدود المعدل والتوجيه الأكثر تعقيداً، راجع دليل Caddy كـ reverse proxy.

نسخ احتياطية تُستعاد فعلاً

كل ما يستحق الاحتفاظ به موجود تحت `/srv/stack`: قواعد بيانات SQLite، ومستودعات Forgejo، وشهادات Caddy، وإعداداتك. لا تعتمد على لقطات المزوّد؛ احتفظ بنسختك المشفرة الخاصة خارج الموقع عبر restic، كما هو موصوف في دليل النسخ الاحتياطي بـ restic.

ملفات SQLite المنسوخة أثناء كتابة الخدمة فيها قد تكون غير متسقة. أبسط طريقة آمنة على خادم صغير هي إيقاف الحزمة للدقيقة التي يستغرقها النسخ الاحتياطي. إن أضفت Nextcloud مع MariaDB، فافرغ قاعدة البيانات بالأمر `mariadb-dump` قبل تشغيل restic. اختبر الاستعادة إلى مجلد مؤقت مرة واحدة على الأقل؛ فالنسخة الاحتياطية التي لم تستعدها قط مجرد تخمين.

#!/bin/sh
# /usr/local/sbin/stack-backup (run nightly from cron or a systemd timer)
# needs RESTIC_REPOSITORY and RESTIC_PASSWORD_FILE in the environment
cd /srv/stack || exit 1
docker compose stop
rc=0
restic backup /srv/stack --tag stack || rc=$?
docker compose start
[ "$rc" -eq 0 ] || exit "$rc"
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

أساسيات الأمان

• ▹SSH: بالمفاتيح فقط، دون دخول root بكلمة مرور، واختيارياً منفذ غير قياسي؛ راجع [دليل تحصين SSH](/guides/ssh-hardening).
• ▹تحذير جدار الحماية: المنافذ التي ينشرها Docker تتجاوز قواعد `ufw`، لأن Docker يكتب سلاسل iptables/nftables الخاصة به. انشر فقط ما يجب أن يكون عاماً (80 و443 و2222) ولا تنشر أبداً منافذ قواعد البيانات أو الإدارة.
• ▹التحديثات: فعّل `unattended-upgrades` للمضيف، وشغّل `docker compose pull && docker compose up -d` وفق جدول تلتزم به فعلاً.
• ▹التسجيل: أبقِ التسجيل العام معطّلاً في Vaultwarden وForgejo؛ وادعُ المستخدمين بدلاً من ذلك.
• ▹تشفير القرص: ضع `/srv` على [جذر مشفر](/guides/luks-encrypted-root) كي لا تكشف صورة القرص المنسوخة شيئاً؛ وعلى خادم بعيد استخدم [فك تشفير LUKS عن بُعد عبر SSH](/guides/luks-remote-unlock-ssh)، وفضّل صيغة LUKS2 المشروحة في [LUKS2 مقابل LUKS1](/guides/luks2-vs-luks1).
• ▹الأسرار: يجب أن يكون `.env` ومجلد بيانات Vaultwarden قابلين للقراءة من root فقط (`chmod 600`/`700`).

الأسئلة الشائعة