أصبحت Next.js إطار React المرجعي في عام 2026، لكن النشر في الإنتاج يبقى موضوعاً شائكاً عندما تريد تجنّب Vercel وأسعارها بالدولار التي تنفجر عند أدنى ارتفاع للأحمال. تسمح Coolify بنشر Next.js على VPS الخاص بك في دقائق معدودة، مع نشر مستمر من GitHub، HTTPS تلقائي، تحديثات بدون توقف (zero-downtime)، وتكلفة ثابتة بضعة يوروات شهرياً مهما كان حجم حركة المرور. إليك الدرس الكامل، مُختبَراً على Next.js 14 و15 في إنتاج فعلي لمشاريع عربية وأفريقية.
إن لم تكن قد ثبّتت Coolify بعد، ابدأ بـدليل تثبيت Coolify. يفترض هذا الدرس أن instance لديك يعمل، متاح عبر HTTPS، وأن مصدر GitHub مرتبط.
لماذا Coolify لـNext.js؟
Vercel هي مُنشئة Next.js والمنصة المرجعية لنشره. ممتازة على نطاق صغير (الخطة المجانية سخية) لكنها تصبح مكلفة بسرعة عند الصعود: 20 دولاراً لكل مستخدم في الخطة Pro، رسوم إضافية لـedge functions، لحركة المرور التي تتجاوز 100 GB، لعمليات البناء التي تتعدى الدقائق المُدرجة. لمؤسسة صغيرة عربية أو أفريقية بـ50 ألف زائر شهرياً، يمكن أن تتسلق فاتورة Vercel بسهولة إلى 200 يورو شهرياً.
Coolify على VPS Hetzner CX22 بـ4 يورو شهرياً يدعم بسهولة عدة تطبيقات Next.js مع قواعد بياناتها. « التكلفة » الوحيدة هي وقت التكوين الأولي (ساعة إلى ساعتين أول مرة) والصيانة الشهرية (تحديثات OS، مراجعة سجلات). لمن يعرف فعلاً كيف يتصل بـSSH، الاقتصاد لا يُضاهى.
المتطلبات الأساسية
- Coolify v4.x مثبتة ومتاحة عبر HTTPS
- تطبيق Next.js 14 أو 15 على GitHub (أو GitLab أو Forgejo أو Gitea)
- اسم نطاق يشير إلى VPS Coolify (سجل A أو AAAA)
- VPS بـ4 GB RAM كحد أدنى (Next.js يستهلك كثيراً أثناء البناء، خاصة للتطبيقات بعدد كبير من الصفحات الثابتة)
- المستوى المطلوب: متوسط (تعرف كتابة .env.local والنشر محلياً)
- الوقت: 15 إلى 25 دقيقة للنشر الأول، ثم كل نشر لاحق تلقائي
الخطوة الأولى — ربط GitHub بـCoolify
في Coolify، توجّه إلى Sources → New Source → GitHub App. انقر « Create new GitHub App »، اختر مؤسستك، وثبّت التطبيق على المستودعات المراد نشرها. تملأ Coolify تلقائياً جميع الصلاحيات اللازمة (read code، read deployments، write webhooks). ميزة نظام GitHub App مقابل رمز شخصي: تنطلق عمليات النشر تلقائياً عند كل push دون webhook يدوي للصيانة، والاتصال لا يعتمد على مستخدم واحد.
إن كان كودك على Forgejo أو Gitea (مستضافين ذاتياً على نفس Coolify مثلاً)، الإجراء مشابه لكن عبر رمز وصول شخصي. للمستودعات الخاصة عبر SSH كلاسيكي، تُولّد Coolify مفتاحاً تلصقه في إعدادات Deploy Keys للمستودع.
الخطوة الثانية — تحضير مشروع Next.js
قبل النشر، حسّن مشروعك للإنتاج. في next.config.js:
/** @type {import('next').NextConfig} */
const nextConfig = {
output: 'standalone', // build مستقل، أخف
reactStrictMode: true,
images: {
formats: ['image/avif', 'image/webp'],
remotePatterns: [{ protocol: 'https', hostname: '**' }],
},
experimental: {
optimizePackageImports: ['lodash', 'date-fns'],
},
};
module.exports = nextConfig;
الخيار output: 'standalone' حاسم: ينتج build مستقلاً مع التبعيات الضرورية فقط، مما يقلّص حجم الحاوية بشكل كبير ويُسرّع الإقلاع. بدونه، Next.js يضمّن node_modules بالكامل في runtime، مما قد ينتج حاويات بمئات الميغابايت.
أضف أيضاً endpoint بسيط لـhealthcheck، مثلاً /api/health يُعيد 200:
// app/api/health/route.ts
export async function GET() {
return Response.json({ status: 'ok', time: Date.now() });
}
الخطوة الثالثة — إنشاء المشروع والتطبيق في Coolify
في Projects، أنشئ مشروعاً (مثلاً « production »). أضف بيئة، ثم « + New Resource » → Application → Public Repository أو Private Repository حسب حالتك. اختر الفرع (عادةً main) وbuildpack Nixpacks. تكتشف Coolify Next.js تلقائياً وتقترح التكوين التالي:
# Build command (مكتشف تلقائياً)
npm run build
# Start command (مكتشف تلقائياً)
npm start
# المنفذ المعروض
3000
# بيئة البناء
NODE_ENV=production
هذه القيم الافتراضية تناسب 95% من مشاريع Next.js. إن كنت تستخدم pnpm أو yarn، تكتشف Coolify lockfile وتُكيّف الأمر تلقائياً.
الخطوة الرابعة — متغيرات البيئة
تبويب « Environment Variables ». أضف أسرارك: DATABASE_URL، NEXTAUTH_SECRET، NEXT_PUBLIC_API_URL، STRIPE_SECRET_KEY، إلخ. تُشفّر Coolify القيم في الراحة ولا تعرضها في السجلات أبداً.
نقطة حرجة: للمتغيرات التي يجب أن تكون متاحة أثناء npm run build (خاصة جميع NEXT_PUBLIC_* وبعض متغيرات Prisma)، فعّل خانة « Build variable ». يدمج Next.js المتغيرات NEXT_PUBLIC وقت البناء، فإن كانت غائبة أثناء npm run build، ستظهر undefined في الإنتاج — وستُمضي 30 دقيقة في تشخيص لماذا تطبيقك يستدعي undefined/api/users.
نصيحة: لإدارة عدة بيئات (dev، staging، prod) دون تكرار جميع المتغيرات، أنشئ بيئة Coolify منفصلة لكل مرحلة. لكل واحدة متغيراتها الخاصة.
الخطوة الخامسة — النطاق وHTTPS
تبويب « Domains ». أضف نطاقك (مثلاً app.exemple.sn). تحقّق أولاً من توجيه DNS نحو IP خادم Coolify (سجل A أو AAAA) بـdig app.exemple.sn أو nslookup. قد يستغرق انتشار DNS من بضع دقائق إلى بضع ساعات حسب مسجل النطاق.
فعّل « Force HTTPS Redirect » و »Generate SSL ». تُطلق Coolify Traefik مع تحدّي HTTP-01 نحو Let’s Encrypt — تحصل على شهادة صالحة في أقل من دقيقة. إن احتجت شهادة wildcard (*.exemple.sn)، فعّل تحدي DNS-01 مع مفتاح API لدى مسجل نطاقك.
الخطوة السادسة — أول نشر
اضغط على « Deploy ». تستنسخ Coolify المستودع، تُطلق Nixpacks الذي يكتشف Next.js، ينفّذ npm ci && npm run build ثم يُشغّل npm start في حاوية. يستغرق البناء عادةً 3 إلى 8 دقائق حسب حجم المشروع وقوة VPS. على Hetzner CX22 (4 GB RAM، 2 vCPU)، مشروع Next.js متوسط (50 صفحة، 30 تبعية) يُبنى في حوالي 5 دقائق.
يعرض تبويب « Logs » العملية مباشرةً. بمجرد ظهور « Application started »، افتح نطاقك وتحقّق. أي push لاحق على الفرع سيُطلق نشراً تلقائياً جديداً مع إمكانية rollback بنقرة واحدة.
الخطوة السابعة — تحسين للإنتاج
- Standalone output: مُنجَز في الخطوة الثانية. الحاوية النهائية تزن 100-150 MB بدلاً من 500 MB+
- تحسين الصور: Next.js Image يعمل أصلياً مع sharp. على VPS بـCPU محدود، فكّر في تقديم الصور عبر CDN مثل Cloudflare Free، الذي يعمل ممتازاً انطلاقاً من العالم العربي وأفريقيا ويوفّر CPU وbandwidth
- تخزين دائم: إن كان تطبيقك يكتب ملفات (رفعات المستخدمين)، أضف volume دائم في Coolify (تبويب Storage). وإلا تختفي الملفات عند كل redeploy. الأفضل، خزّن الرفعات على خدمة S3 من نوع Backblaze B2
- Healthcheck: كوّن المسار
/api/healthفي Coolify (تبويب General → Health Check). تعتمد إعادة النشر zero-downtime على ذلك: تنتظر Coolify أن تُجيب الحاوية الجديدة 200 على healthcheck قبل قطع القديمة - Resource limits: إن كانت عدة تطبيقات على نفس VPS، حدّد limits CPU/RAM لكل تطبيق (تبويب Advanced) لتجنّب أن يستنزف تطبيق ثقيل الـVPS بأكمله
الخطوة الثامنة — قاعدة بيانات وخدمات مرتبطة
كل مشروع Next.js جدّي يحتاج قاعدة بيانات. وفّر PostgreSQL بنقرة واحدة عبر Coolify (راجع دليل PostgreSQL Coolify) واستخدم URL الداخلي كـDATABASE_URL في تطبيقك. الأمر سيان لـRedis إن كنت تستخدم caching server-side أو sessions.
لـPrisma، أضف prisma generate في سكربت postinstall في package.json ليُشغَّل تلقائياً عند كل بناء:
{
"scripts": {
"postinstall": "prisma generate",
"build": "prisma migrate deploy && next build"
}
}
التكييف للسوق العربي وغرب أفريقيا
للزوار في الرياض أو الدار البيضاء أو دكار الذين يصلون إلى تطبيقك المنشور على VPS أوروبي، أضف Cloudflare أمام نطاقك (مجاناً): يقلّل edge cache زمن التحميل بشكل دراماتيكي ويوفّر bandwidth من VPS. وضع « Proxied » (البرتقالي) يكفي، احتفظ بـSSL « Full strict » بما أن Coolify لديها بالفعل شهادة صالحة. يصل العرب والأفارقة عندئذٍ إلى تطبيقك عبر datacenter Cloudflare في لاغوس أو الدار البيضاء أو القاهرة (عشرات الميلي ثانية) بدلاً من فرانكفورت (200 ms).
إن كان تطبيقك يقوم بدفع Mobile Money عبر Wave أو Orange Money أو Mada في السعودية، انشر التطبيق + قاعدة البيانات + worker queue (BullMQ مثلاً) على نفس Coolify. يعرض دليل APIs Mobile Money 2026 التكامل الكامل.
أخطاء شائعة
| الخطأ | السبب | الحل |
|---|---|---|
| OOM أثناء npm run build | VPS أقل من 4 GB أو تطبيق كبير | إضافة 2 GB swap، أو ترقية VPS |
| NEXT_PUBLIC_* undefined في الإنتاج | المتغير لم يُحدَّد كـ »Build variable » | تفعيل خانة في تبويب Variables |
| خطأ Prisma « Cannot find module » | prisma generate لم يُنفَّذ | إضافة في postinstall أو في build script |
| 404 على API routes | منفذ خاطئ أو إعادة توجيه Traefik | تحقق من المنفذ 3000 في تكوين Coolify |
| Build لا ينتهي على صفحات ISR | API خارجي بطيء أثناء getStaticProps | إضافة timeout، أو الانتقال إلى SSR/dynamic |
| الحاوية تُقتل OOM بعد دقائق | تسرّب ذاكرة في التطبيق | تحليل بـnode –inspect، إصلاح التسرّب |
للمزيد
- الدليل الكامل لـCoolify
- PostgreSQL مُدارة مع Coolify
- Coolify مقابل Dokploy مقابل CapRover
- النسخ الاحتياطي Coolify إلى S3 وMinIO
- التوثيق الرسمي Next.js: nextjs.org/docs
- التوثيق الرسمي Coolify: coolify.io/docs
الأسئلة الشائعة
هل تدعم Coolify Next.js App Router (Next.js 14+)؟
نعم، تماماً. لا تفترض Coolify شيئاً عن إصدار Next.js أو معماريته: تنفّذ ببساطة الأوامر npm run build وnpm start التي يُحدّدها package.json الخاص بك. App Router وPages Router وTurbopack، كلها تعمل.
كيف أدير ISR (Incremental Static Regeneration)؟
ISR يعمل أصلياً، لكن يتطلب volume دائم لتخزين cache الصفحات المُولَّدة. وإلا يُفقد cache عند كل redeploy. كوّن volume Coolify مُركَّباً على /app/.next/cache.
هل يمكن استخدام Edge Runtime على Coolify؟
لا، Edge Runtime خاص بـVercel. على Coolify، تعمل API routes وmiddleware في Node.js قياسي، وهو ممتاز في 99% من الحالات (بل أفضل من حيث الميزات، لأنك تصل إلى جميع APIs Node.js).
كيف أنفّذ A/B testing أو canary deployment؟
تدعم Coolify v4 النشر متعدد البيئات. يمكنك استضافة نسخة « canary » على نطاق فرعي منفصل وتوجيه جزء من حركة المرور عبر Cloudflare Workers أو middleware Next.js يقرأ cookie. لـblue-green أبسط، استخدم تطبيقَين Coolify متطابقَين وبدّل DNS.