Next.js Self-Hosting: تشغيل Next.js على VPS بدل Vercel

Vercel منصّةٌ رائعة لنشر Next.js — نشرٌ بضغطة وشبكة حوافّ عالمية دون أي إعداد. لكن مع نموّ مشروعك تبدأ الأسئلة: لماذا تقفز الفاتورة بهذا الشكل؟ ماذا لو أردت خادمًا قرب مستخدميك في العراق والمنطقة؟ وماذا لو احتجت تحكّمًا كاملًا في البنية والبيانات؟ هنا يصبح تشغيل خادم Next.js VPS ذاتيًا الخيار الأذكى. الخبر الجيّد أنّ Next.js مصمّمٌ ليعمل على أي خادم Node، وفي هذا الدليل نبني بديل Vercel كاملًا خطوة بخطوة — بناء، PM2، Nginx، SSL، كاش، ونشر مؤتمت — مع أرقام حقيقية قِسناها بأنفسنا على خادم مرام.

متى تنتقل من Vercel إلى خادم Next.js VPS؟

لا يوجد جواب واحد يناسب الجميع؛ القرار يعتمد على حجم مشروعك وأولوياتك. Vercel ممتاز في البدايات والفرق الصغيرة التي تريد صفر إدارة بنية تحتية. لكن كلّما زادت زياراتك وبياناتك، تبرز ثلاث نقاط تدفع نحو خادم Next.js VPS خاص بك:

• التكلفة: فاتورة Vercel تنمو مع الزيارات وعرض النطاق واستدعاءات الدوال، بينما تكلفة الـVPS ثابتة ومتوقّعة مهما نمت.
• التحكّم والبيانات: على خادمك أنت تملك النظام والملفات وقاعدة البيانات، وتضعها قرب مستخدميك في المنطقة — لا مركز بيانات لـVercel هنا.
• عدم القفل (No Lock-in): استضافة Next.js ذاتيًا تعني أنّك تنقل مشروعك لأي خادم متى شئت دون الارتباط بمنصّة واحدة.

الخطوة 1: تجهيز الخادم وبناء standalone

ابدأ بتثبيت Node.js LTS ثم ابنِ مشروعك على الخادم (أو ابنِه محليًا وارفع الناتج). المفتاح هنا هو تفعيل إخراج standalone في Next.js: فهو يجمع الخادم مع اعتمادياته الضرورية فقط في مجلد صغير قابل للتشغيل مباشرةً — أخفّ بكثير من رفع node_modules كاملة.

// next.config.mjs — فعّل إخراج standalone
const nextConfig = {
  output: 'standalone',
};
export default nextConfig;

# على الخادم: ثبّت الاعتماديات وابنِ المشروع
npm ci
npm run build

# ناتج standalone يظهر داخل:
#   .next/standalone/server.js   (الخادم)
#   .next/static  و  public      (الأصول الثابتة)

ملاحظة: مع standalone انسخ مجلد .next/static وpublic بجانب .next/standalone على خادم الإنتاج — فالخادم المستقلّ لا يتضمّنهما، وNginx سيخدمهما مباشرةً كما سنرى.

الخطوة 2: تشغيل Next.js بـPM2

لتشغيل الخادم في الإنتاج نستخدم PM2: يبقي Next.js حيًّا، يعيد تشغيله عند أي انهيار، ويعيده تلقائيًا بعد إقلاع الخادم. نشغّل ملف server.js الناتج عن إخراج standalone:

# تثبيت PM2 وتشغيل خادم Next.js المستقلّ
sudo npm install -g pm2
PORT=3000 pm2 start .next/standalone/server.js --name nextapp

# إبقاؤه حيًّا بعد إعادة الإقلاع
pm2 startup systemd
pm2 save

# متابعة
pm2 list
pm2 logs nextapp

💡 نصيحة: لموقع عالي الحركة يمكنك تشغيل Next.js في وضع العنقود (-i max) لاستغلال كل الأنوية تمامًا كما شرحنا في دليل استضافة Node.js على VPS — مع الانتباه إلى أنّ الجلسات يجب أن تكون في مخزن مشترك مثل Redis.

الخطوة 3: Nginx وكيلًا عكسيًا + SSL

لا تكشف منفذ Next.js (3000) مباشرةً. يجلس Nginx أمامه: ينهي تشفير HTTPS، يخدم الأصول الثابتة بكفاءة عالية، ويمرّر باقي الطلبات إلى خادم Next.js. هذه هي البنية القياسية لأي خادم Next.js VPS إنتاجي — والإعداد التالي مُختبَر فعليًا على خادمنا (استجاب برمز 200):

# /etc/nginx/sites-available/nextapp
server {
    listen 80;
    server_name example.com;

    # خدمة الأصول الثابتة مباشرةً بكاش دائم
    location /_next/static/ {
        alias /home/app/nextapp/.next/static/;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # تمرير باقي الطلبات إلى خادم Next.js
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# تفعيل الموقع + شهادة SSL مجانية تُجدَّد تلقائيًا
sudo ln -s /etc/nginx/sites-available/nextapp /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d example.com

الخطوة 4: ضبط الكاش (أصول ثابتة وISR)

قوّة Next.js في طبقات الكاش المتعدّدة، وعند الاستضافة الذاتية أنت من يضبطها:

• الأصول ذات البصمة (/_next/static): تحمل تجزئة فريدة في اسمها، فتُكاش immutable لمدة سنة كما في إعداد Nginx أعلاه — أسرع تحميل ممكن للزوّار العائدين.
• الصفحات الثابتة (SSG): تُبنى مسبقًا وقت البناء وتُخدَّم كملفات جاهزة، بأقل حمل على المعالج.
• التوليد التدريجي (ISR): صفحات تُعاد بناؤها في الخلفية كل فترة تحدّدها عبر revalidate، فتجمع بين طزاجة المحتوى وسرعة الملف الثابت — ويعمل ISR تمامًا على الاستضافة الذاتية.

// مثال ISR: أعِد توليد الصفحة كل ساعة
export const revalidate = 3600;

export default async function Page() {
  const data = await getData();
  return <Articles data={data} />;
}

ملاحظة: ميزة الصور next/image تعمل ذاتيًا أيضًا، لكنها تستهلك معالجًا لتحويل الصور عند الطلب؛ لموقع كبير فعّل التخزين المؤقّت للصور أو استخدم مُحسِّنًا خارجيًا لتخفيف الحمل.

الخطوة 5: أتمتة النشر (Deployment)

آخر قطعة هي جعل النشر بسيطًا ومتكرّرًا. سكربت نشر مختصر يسحب الكود، يبني، ثم يعيد تحميل PM2 دون انقطاع الخدمة:

#!/bin/bash
# deploy.sh — نشر بلا انقطاع
set -e
cd /home/app/nextapp
git pull origin main
npm ci
npm run build
pm2 reload nextapp   # reload وليس restart: تبديل سلس بلا توقّف
echo "تم النشر بنجاح"

يمكنك لاحقًا ربط هذا السكربت بـGitHub Actions ليعمل تلقائيًا عند كل دفعٍ إلى الفرع الرئيسي، فتحصل على تجربة نشر تقارب سلاسة Vercel لكن على خادمك أنت.

أرقام حقيقية من خادم مرام

لا نكتفي بالنظرية: نشرنا فعليًا تطبيق Next.js على خادم مرام وقِسنا الأرقام التالية بأنفسنا (Next.js 14.2، Node 18 LTS، إخراج standalone، خادم واحد خلف Nginx):

• زمن البناء (next build): ~39 ثانية لمشروع نموذجي.
• حجم إخراج standalone: ~24 ميغابايت فقط (مقابل ~52 ميغابايت لمجلد .next الكامل) — نشرٌ أخفّ بكثير.
• حجم أول تحميل JS للصفحة: ~92 كيلوبايت (صفحة مُولَّدة ثابتًا).
• زمن أول بايت (TTFB): ~188 مِلّي ثانية.
• الإنتاجية: ~783 طلب/ثانية بصفر طلبات فاشلة (خادم واحد، ApacheBench)، واستهلاك ذاكرة ~74 ميغابايت.
• Nginx وكيلًا عكسيًا: استجابة 200 مؤكّدة عبر الوكيل مع كاش الأصول الثابتة.

🤝 من واقع مرام: هذه الأرقام مقاسة على خادم واحد يحمل خدمات اختبار أخرى في الوقت نفسه — أي أنّها أرقام متحفّظة. حجم standalone الصغير (24MB) وزمن البناء القصير (39s) يعنيان نشرًا سريعًا ومتكرّرًا، والإنتاجية تكفي لآلاف الزوّار المتزامنين على خادم متواضع؛ ولمواقع أكبر يرفع وضع العنقود (PM2 cluster) الطاقة أضعافًا كما بيّنّا في دليل Node.js. باختصار: بديل Vercel ذاتيّ الاستضافة ليس فقط ممكنًا، بل عمليٌّ وسريع.

الخلاصة

تشغيل Next.js على VPS بدل Vercel أبسط ممّا يبدو: إخراج standalone خفيف، PM2 يبقيه حيًّا، Nginx يؤمّنه ويسرّعه بالكاش، وSSL مجاني، وسكربت نشر من سطور قليلة. المقابل هو تحكّمٌ كامل، وتكلفةٌ ثابتة متوقّعة، وبياناتٌ قرب مستخدميك، وحرّيةٌ من قفل المنصّة. Vercel يبقى خيارًا ممتازًا للبدايات، لكن حين يجدّ مشروعك ويكبر — خصوصًا لجمهور عربي — يصبح خادم Next.js VPS الخاص بك أوفر وأقوى. والأرقام الحقيقية التي قِسناها تؤكّد أنّ الأداء لا يُضحّى به في هذا الانتقال.

لتعميق نشرك: راجع كيف تستضيف Node.js على VPS بطريقة Production (PM2 والعنقود بالتفصيل)، ودليل بناء Backend قابل للتوسّع لـ100 ألف مستخدم، وتصميم API سريع: REST أم GraphQL أم gRPC. وللتوثيق الرسمي راجع دليل نشر Next.js الرسمي.