[{"data":1,"prerenderedAt":206},["ShallowReactive",2],{"seo-verification":3,"blog-نشر-تطبيق-payload-cms-على-خادم-vps-ma-ar":6,"promo-bar-likely":205},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-نشر-تطبيق-payload-cms-على-خادم-vps-ma-ar",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":145,"ctaBody":146,"ctaButton":147,"ctaUrl":148,"relatedPosts":149},55,"نشر-تطبيق-payload-cms-على-خادم-vps",{"fr":12,"en":13,"ar":10,"es":14},"deployer-payload-cms-vps","deploying-a-payload-cms-application-on-a-vps","desplegar-payload-cms-en-un-vps","نشر Payload CMS على VPS: دليل شامل","دليل شامل لاستضافة Payload CMS 3 ذاتياً على VPS: Docker Compose وإدارة المصادقة والـ hooks والترحيل وحل الأخطاء الشائعة في الإنتاج.",10,2,false,"2026-04-26T00:00:00+00:00","2026-11-08T01:13:14+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},4,"التطوير","developpement","bg-warning\u002F10 text-warning","dev",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdeployer-payload-cms-vps-poster.svg","يتثبت Payload CMS 3 مباشرة داخل تطبيق Next.js، مما يجعله من أكثر أنظمة إدارة المحتوى Headless قرباً من الكود. يغطي هذا الدليل النشر الكامل على VPS: إعداد Docker Compose مع healthchecks، وإدارة المستخدمين ومفاتيح API، وخطافات المجموعة، وسير عمل الترحيل، وحل الأخطاء الأكثر شيوعاً في الإنتاج.",[35,39,50,53,75,78,81,84,87,90,142],{"type":36,"title":37,"body":38},"h2","لماذا استضافة Payload CMS ذاتياً على VPS","يعتمد Payload CMS نهجاً قائماً على الكود بشكل جذري: يُعرَّف مخطط المحتوى في TypeScript ضمن ملفات إعداد مُصنَّفة بـ Git، ومنذ الإصدار 3 يتثبت Payload مباشرة داخل تطبيق Next.js عبر App Router. هذا يعني أن VPS يتيح لك استضافة نظام إدارة المحتوى والواجهة الأمامية في عملية Node واحدة، تشترك في نفس البناء والـ runtime. تحصل على typing شامل من طرف إلى طرف، وترحيل مخطط مُدار في الكود، دون أي اعتماد على واجهة رسومية لنمذجة المحتوى. الاستضافة الذاتية هي الخيار الطبيعي هنا: صُمِّم Payload للنشر مثل أي تطبيق Next.js، ويمنحك VPS السيطرة الكاملة على قاعدة البيانات (MongoDB أو PostgreSQL)، والرفوعات، ومتغيرات البيئة، دون وسيط.",{"type":40,"title":41,"items":42},"ul","الفوائد الملموسة",[43,44,45,46,47,48,49],"مخطط المحتوى مُعرَّف بـ TypeScript ومُصنَّف بـ Git: مراجعة كاملة للكود والتاريخ","نظام إدارة المحتوى والواجهة الأمامية في runtime واحد: بناء واحد وعملية واحدة للنشر","Typing شامل بين إعداد Payload وAPI والواجهة، دون توليد يدوي","اختيار قاعدة البيانات: MongoDB أو PostgreSQL أو SQLite عبر المحولات الرسمية","ترحيل المخطط مُقاد بالكود (`payload migrate`)، قابل للتكرار بين البيئات","Local API: وصول مباشر للبيانات دون استدعاءات HTTP من كود Next.js الخادم","لا تكاليف ترخيص: Payload CMS 3 مفتوح المصدر (MIT) — تدفع فقط مقابل VPS",{"type":36,"title":51,"body":52},"المتطلبات الأجهزية والبرمجية","بما أن Payload يعمل على Next.js، فإن البناء مُطالِب بالموارد: خطط لـ VPS بـ 2 vCPU و4 GB RAM لبناء التطبيق وتشغيله بشكل مريح. ثبِّت Node.js 22 أو 24 (يتطلب Payload 3.93 الإصدار `^22.23.4 || >=24.22.1`، ولم يعد Node 20 مقبولًا) وDocker وDocker Compose. لقاعدة البيانات، جهِّز MongoDB 7 أو PostgreSQL 16 وفق المحوِّل المختار (`@payloadcms\u002Fdb-mongodb` أو `@payloadcms\u002Fdb-postgres`). وجِّه نطاقك نحو IP الـ VPS. خصص 15 GB قرصياً لـ `node_modules` وبناء `.next` والرفوعات ونسخ قاعدة البيانات الاحتياطية.",{"type":54,"title":55,"steps":56},"steps","خطوات النشر",[57,60,63,66,69,72],{"title":58,"body":59},"اختيار محوِّل قاعدة البيانات وإعداده","في `payload.config.ts`، صرِّح بالمحوِّل: `mongooseAdapter` لـ MongoDB أو `postgresAdapter` لـ PostgreSQL، مع قراءة URL الاتصال من `DATABASE_URI`. هذا خيار هيكلي: PostgreSQL يستلزم ترحيلات، بينما MongoDB أكثر مرونة في المخطط.",{"title":61,"body":62},"تحضير متغيرات البيئة","أنشئ ملف `.env.production` يحتوي على الحد الأدنى:\n\n```bash\nPAYLOAD_SECRET=سرك-32-حرفاً-على-الأقل\nDATABASE_URI=postgresql:\u002F\u002Fuser:pass@postgres:5432\u002Fpayload\nNEXT_PUBLIC_SERVER_URL=https:\u002F\u002Fexample.com\nNODE_ENV=production\nPAYLOAD_CONFIG_PATH=src\u002Fpayload.config.ts\n```\n\n`PAYLOAD_SECRET` يوقِّع رموز JWT للجلسات ويُشفِّر مفاتيح API — قيمة قصيرة أو متوقعة تُضعِف نظام المصادقة بأكمله. ولِّدها بـ `openssl rand -hex 32`. يجب أن يطابق `NEXT_PUBLIC_SERVER_URL` URL العام النهائي: يستخدمه Payload لبناء روابط الوسائط وعناوين البريد الإلكتروني.",{"title":64,"body":65},"كتابة Docker Compose مع healthchecks","يتضمن `docker-compose.yml` المتين healthchecks لضمان عدم بدء التطبيق إلا بعد جاهزية قاعدة البيانات:\n\n```bash\nservices:\n  app:\n    build: .\n    ports:\n      - \"127.0.0.1:3000:3000\"\n    env_file: .env.production\n    depends_on:\n      postgres:\n        condition: service_healthy\n    volumes:\n      - uploads:\u002Fapp\u002Fpublic\u002Fmedia\n\n  postgres:\n    image: postgres:16-alpine\n    environment:\n      POSTGRES_USER: payload\n      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}\n      POSTGRES_DB: payload\n    volumes:\n      - pgdata:\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata\n    healthcheck:\n      test: [\"CMD-SHELL\", \"pg_isready -U payload\"]\n      interval: 5s\n      timeout: 5s\n      retries: 10\n\nvolumes:\n  pgdata:\n  uploads:\n```\n\nبدون healthcheck وشرط `service_healthy`، يبدأ التطبيق قبل قبول PostgreSQL للاتصالات، ويفشل تجمع الاتصالات ويعيد تشغيل الحاوية في حلقة.",{"title":67,"body":68},"بناء الصورة وتنفيذ الترحيلات","ابنِ ثم نفِّذ الترحيلات بهذا الترتيب:\n\n```bash\ndocker compose build\ndocker compose up -d postgres\ndocker compose run --rm app npx payload migrate\ndocker compose up -d app\n```\n\nلـ PostgreSQL، يطبق `npx payload migrate` ملفات الترحيل المولَّدة في `src\u002Fmigrations\u002F`. إن لم تكن موجودة بعد، ولِّدها أولاً بـ `npx payload migrate:create`. لـ MongoDB، لا يحتاج المخطط إلى ترحيل: لا يُنفِّذ `migrate` إلا ترحيلات البيانات التي كتبتها بنفسك عبر `migrate:create`.",{"title":70,"body":71},"إعداد Nginx كـ reverse proxy","وجِّه vhost نحو `http:\u002F\u002F127.0.0.1:3000` (المنفذ الافتراضي لـ Next.js). زِد `client_max_body_size` لرفع الوسائط وأضف ترويسات `X-Forwarded-Proto` لكي يولِّد Payload URLs صحيحة بـ HTTPS.",{"title":73,"body":74},"التأمين بـ SSL وتثبيت URL الخادم","نفِّذ `certbot --nginx -d example.com`، ثم تحقق من تعريف `serverURL: 'https:\u002F\u002Fexample.com'` في `payload.config.ts`. هذا URL يتحكم في روابط الوسائط ورسائل إعادة تعيين كلمة المرور والعمل الصحيح للوحة إدارة خلف الـ proxy.",{"type":36,"title":76,"body":77},"المصادقة وإدارة الوصول","يدير Payload 3 المستخدمين عبر مجموعة `users` المعرَّفة في `payload.config.ts`. فعِّل المصادقة على المجموعة بـ `auth: true` — هذا يضيف تلقائياً نقاط النهاية `\u002Fapi\u002Fusers\u002Flogin` و`\u002Fapi\u002Fusers\u002Flogout` و`\u002Fapi\u002Fusers\u002Fme` و`\u002Fapi\u002Fusers\u002Frefresh-token`.\n\nللأدوار، لا يفرض Payload نموذجاً: عرِّف حقل `role` (نوع `select`) على مجموعة `users`، ثم تحكم في الوصول عبر دوال `access` على مستوى كل مجموعة وكل عملية:\n\n```bash\naccess: {\n  read: ({ req: { user } }) => user?.role === 'admin',\n  create: isAdmin,\n  update: isAdminOrSelf,\n  delete: isAdmin,\n}\n```\n\nللوصول البرمجي (CI والتكاملات الخارجية)، استخدم **مفاتيح API**: فعِّل `useAPIKey: true` في إعداد مصادقة المجموعة. يمكن حينئذٍ للمستخدمين الذين لديهم صلاحية الإدارة توليد مفتاح أو إعادة توليده أو إلغاؤه من لوحة الإدارة. مرِّره في ترويسة `Authorization: users API-Key مفتاحك`. يُعرض المفتاح مرة واحدة فقط: يُشفِّره Payload في قاعدة البيانات بـ `PAYLOAD_SECRET` ولا يعرضه بعد ذلك — المفتاح المفقود يُعاد توليده، وتغيير `PAYLOAD_SECRET` يُبطل كل المفاتيح الموجودة.",{"type":36,"title":79,"body":80},"خطافات المجموعة: الاستجابة لأحداث المحتوى","تتيح **خطافات المجموعة** في Payload 3 تنفيذ كود قبل أو بعد كل عملية CRUD. تحلّ محلّ الـ webhooks بشكل أنيق حين تعيش المنطق في نفس الـ runtime:\n\n```bash\nhooks: {\n  afterChange: [\n    async ({ doc, operation }) => {\n      if (operation === 'create') {\n        await notifySubscribers(doc)\n      }\n    },\n  ],\n  beforeDelete: [\n    async ({ id }) => {\n      await cleanupMedia(id)\n    },\n  ],\n}\n```\n\nخطافات المجموعة: `beforeOperation` و`beforeValidate` و`beforeChange` و`afterChange` و`beforeRead` و`afterRead` و`beforeDelete` و`afterDelete` و`afterOperation` و`afterError`، وتضيف مجموعات المصادقة خصوصًا `beforeLogin` و`afterLogin` و`afterLogout`. خطاف `afterChange` مثالي لإبطال كاش CDN أو إرسال إشعار أو مزامنة مع خدمة خارجية بعد النشر.",{"type":36,"title":82,"body":83},"التحديثات وترحيل المخطط","يتبع Payload 3 الإصدار الدلالي. تحديثات الـ patch (`3.x.y → 3.x.z`) آمنة التطبيق دون ترحيلات. قد تضيف تحديثات الـ minor (`3.x → 3.y`) أعمدة أو فهارس وتستلزم تشغيل `payload migrate`.\n\nسير العمل الموصى به لكل تحديث:\n\n```bash\n# 1. تحديث الإصدار في package.json\nnpm install payload@3.93.0 @payloadcms\u002Fdb-postgres@3.93.0\n\n# 2. توليد ملف ترحيل إذا تغيّر المخطط\nnpx payload migrate:create\n\n# 3. الاختبار محلياً على نسخة قاعدة البيانات\nnpx payload migrate\n\n# 4. حفظ ملف الترحيل مع تحديث الإصدار\ngit add src\u002Fmigrations\u002F package.json package-lock.json\ngit commit -m \"chore: payload 3.93.0\"\n\n# 5. في الإنتاج: إيقاف التطبيق، تطبيق الترحيلات، إعادة التشغيل\ndocker compose run --rm app npx payload migrate\ndocker compose up -d app\n```\n\nلا تعدِّل يدويًا ترحيلًا طُبِّق من قبل في `src\u002Fmigrations\u002F`: يسجِّل Payload كل ترحيل مُنفَّذ باسمه في مجموعة `payload-migrations` ولا يعيد تشغيله، فلا يصل التعديل إلى الإنتاج أبدًا. اكتب ترحيلًا جديدًا بدلًا من ذلك.",{"type":36,"title":85,"body":86},"عندما يرفض `sharp` التحميل","هذا أكثر عائق شائع عند النشر على VPS، ويأخذ ثلاثة أشكال متميزة. الأكثر إرباكاً هو `Unsupported CPU: Prebuilt binaries for Linux x64 require v2 microarchitecture` («linux-x64» قبل sharp 0.35): يصدر من **معالج الجهاز**، لا من كودك أو تبعياتك. الثنائيات المُجمَّعة مسبقاً تستهدف مجموعة تعليمات لا تتوفر في المعالجات الأقدم — هذا معيار اختيار VPS، لا خطأ يُصلَح. الثاني `Could not load the \"sharp\" module using the linux-x64 runtime`، يشير عادةً إلى `node_modules` مبني على منصة مختلفة — أعِد التثبيت على الجهاز الهدف. الثالث خاص بـ Docker متعدد المراحل: `sharp` مُثبَّت في مرحلة البناء فقط غائب عن مرحلة التشغيل — ثبِّته صراحةً في المرحلة النهائية.",{"type":36,"title":88,"body":89},"الحل: الأخطاء الشائعة في الإنتاج","**نفاد ذاكرة البناء — `Killed` أو `JavaScript heap out of memory`.**\nيحدث أثناء `npm run build` حين تكون ذاكرة الـ VPS محدودة ويبلغ الـ heap في Node.js حدَّه الأقصى. مرِّر `NODE_OPTIONS=--max-old-space-size=3072` قبل البناء، أو ابنِ الصورة على جهاز أقوى وادفعها إلى registry.\n\n**PostgreSQL — `Error: connect ECONNREFUSED 127.0.0.1:5432`.**\nالتطبيق يحاول الاتصال قبل جاهزية PostgreSQL، أو URL الاتصال يشير إلى `localhost` بدلاً من اسم خدمة Docker (`postgres`). تحقق من استخدام `DATABASE_URI` لاسم الخدمة ووجود healthcheck (انظر الخطوة 3).\n\n**لوحة الإدارة غير متاحة في الإنتاج — `\u002Fadmin` يُعيد 404 أو حلقة إعادة توجيه.**\nسببان رئيسيان: `serverURL` غير مُعرَّف أو غير مطابق للـ URL الفعلي، أو ترويسة `X-Forwarded-Proto: https` غائبة من Nginx. أضف `proxy_set_header X-Forwarded-Proto $scheme;` للـ vhost وتحقق من تطابق `serverURL` مع الأصل العام دون شرطة مائلة نهائية.\n\n**CORS — `Access-Control-Allow-Origin` غائبة عن الـ API.**\nPayload يقرأ `cors` من `payload.config.ts`. في الإنتاج، اذكر الأصول المسموحة صراحةً: `cors: { origins: ['https:\u002F\u002Fexample.com'] }`. `cors: { origins: [serverURL] }` هو الإعداد الآمن الأدنى.\n\n**ترحيل معدَّل لا يُطبَّق.**\nملف في `src\u002Fmigrations\u002F` عُدِّل بعد تطبيقه. يسجِّل Payload كل ترحيل مُنفَّذ باسمه ولا يعيد تشغيله أبدًا: يُتجاهَل التعديل دون أي خطأ. استعِد الأصلي من Git، ولِّد ملف ترحيل جديدًا إذا تغيّر المخطط، ثم طبِّقه.",{"type":91,"title":92,"headers":93,"rows":97},"comparison","Payload CMS مقابل Strapi: أي CMS headless تستضيفه ذاتياً؟",[94,95,96],"المعيار","Payload CMS","Strapi",[98,102,106,110,114,118,122,126,130,134,138],[99,100,101],"نهج الإعداد","Code-first بـ TypeScript مُصنَّف بـ Git","GUI-first عبر Content-Type Builder",[103,104,105],"تكامل الواجهة الأمامية","أصيل في Next.js (runtime واحد)","منفصل، واجهة أمامية ونظام CMS منفصلان",[107,108,109],"قواعد البيانات المدعومة","MongoDB وPostgreSQL وSQLite","PostgreSQL وMySQL وMariaDB وSQLite",[111,112,113],"Typing","TypeScript أصيل من طرف إلى طرف","أنواع مولَّدة، تكامل أقل إحكاماً",[115,116,117],"الوصول للبيانات من الخادم","Local API دون استدعاءات HTTP","API REST\u002FGraphQL عبر HTTP",[119,120,121],"نمذجة المحتوى","في الكود، من قِبل المطورين","في الواجهة، متاح لغير المطورين",[123,124,125],"RAM اللازمة للبناء","عالية (بناء Next.js)","عالية (بناء React admin)",[127,128,129],"إدارة الترحيلات","ملفات مُصنَّفة، `payload migrate`","مزامنة المخطط عند التشغيل، وترحيلات في `database\u002Fmigrations` (دون CLI)",[131,132,133],"مفاتيح API الأصيلة","نعم، لكل مجموعة، مُشفَّرة في قاعدة البيانات","نعم، عبر رموز API",[135,136,137],"خطافات المجموعة","أصيلة ومكتوبة بـ TypeScript","lifecycle hooks (`lifecycles.js`) وmiddlewares الـ Document Service",[139,140,141],"مثالي لـ","فرق المطورين، مشاريع Next.js المكتوبة","الفرق المختلطة، النمذجة المرئية",{"type":143,"body":144},"tip","استغل Local API الخاصة بـ Payload في مكونات الخادم Next.js: بدلاً من استدعاء API الخاصة بك عبر `fetch`، استورد `getPayload` واستعلم قاعدة البيانات مباشرةً (`payload.find({ collection: 'posts' })`). تلغي رحلة HTTP وتكسب في زمن الاستجابة والأمان. للوسائط، ثبِّت إضافة `@payloadcms\u002Fstorage-s3` لتخزين الرفوعات خارج الـ VPS، وأتمت نسخاً احتياطية يومية لقاعدة البيانات عبر cron. أخيراً، فعِّل سير عمل **المسودة\u002Fالمعاينة** الأصيل في Payload لتقديم خطوة معاينة للمحررين قبل النشر.","انشر Payload CMS على حزمة موحّدة","يوفّر خادم VPS Cloud من ServOrbit القدرة اللازمة لبناء Next.js الخاص بـ Payload وبيئة Docker جاهزة لـ MongoDB أو PostgreSQL، لاستضافة نظام إدارة المحتوى الذي يعتمد الشيفرة أوّلًا وواجهتك الأمامية على الآلة نفسها.","اكتشف خادم VPS Cloud","\u002Fvps-cloud",[150,168,186],{"id":151,"slug":152,"slugs":153,"title":157,"excerpt":158,"readTime":23,"views":159,"isPinned":19,"noindex":19,"publishedAt":160,"updatedAt":161,"category":162,"categories":163,"featuredImage":30,"bgImage":31,"posterImage":165,"relatedSolution":166},5,"نشر-laravel-على-خادم-vps-دليل-الإنتاج",{"fr":154,"en":155,"ar":152,"es":156},"deployer-laravel-vps","deploying-laravel-on-a-vps-a-production-guide","desplegar-laravel-en-un-vps","نشر Laravel على خادم VPS: دليل الإنتاج","انقل Laravel إلى بيئة الإنتاج على خادم VPS: PHP وworkers والذاكرة المؤقتة وقاعدة البيانات وreverse proxy وHTTPS مُهيّأة بشكل نظيف.",1,"2026-02-09T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[164],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-laravel-vps-poster.svg",{"categorySlug":27,"appSlug":167},"laravel-stack",{"id":169,"slug":170,"slugs":171,"title":175,"excerpt":176,"readTime":177,"views":159,"isPinned":19,"noindex":19,"publishedAt":178,"updatedAt":179,"category":180,"categories":181,"featuredImage":30,"bgImage":31,"posterImage":183,"relatedSolution":184},43,"نشر-تطبيق-nodejs-على-vps",{"fr":172,"en":173,"ar":170,"es":174},"deployer-nodejs-vps","deploy-a-nodejs-application-on-a-vps","desplegar-una-aplicacion-nodejs-en-un-vps","نشر تطبيق Node.js على VPS","انشر تطبيق Node.js في بيئة الإنتاج على VPS: PM2 وبروكسي عكسي Nginx وشهادة SSL من Let's Encrypt وبدء تشغيل تلقائي عند الإقلاع.",8,"2026-05-08T00:00:00+00:00","2026-11-08T01:13:12+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[182],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-nodejs-vps-poster.svg",{"categorySlug":24,"appSlug":185},"nodejs-stack",{"id":187,"slug":188,"slugs":189,"title":193,"excerpt":194,"readTime":195,"views":196,"isPinned":19,"noindex":19,"publishedAt":197,"updatedAt":198,"category":199,"categories":200,"featuredImage":30,"bgImage":31,"posterImage":202,"relatedSolution":203},44,"نشر-تطبيق-django-على-vps",{"fr":190,"en":191,"ar":188,"es":192},"deployer-django-vps","deploy-a-django-application-on-a-vps","desplegar-una-aplicacion-django-en-un-vps","نشر تطبيق Django على VPS","انشر Django على VPS: Gunicorn وNginx وPostgreSQL وDocker وSSL. دليل كامل لمطوّري Python الراغبين في الاستضافة الذاتية.",3,7,"2026-05-07T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[201],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-django-vps-poster.svg",{"categorySlug":24,"appSlug":204},"django",true,1794270313379]