نشر تطبيق Node.js أو Next.js على VPS باستخدام Docker وNginx

إذا كنت تبحث عن نشر تطبيق Node.js على VPS أو تريد نقل مشروع Next.js من بيئة التطوير إلى production حقيقي، فالموضوع لا يتوقف عند تشغيل npm start على السيرفر. النشر الصحيح يعني أن التطبيق يعمل خلف Nginx، داخل Container واضح، مع SSL، وملفات بيئة آمنة، وخطة تحديث لا تكسر الموقع عند كل تعديل.

هذا الدليل يشرح طريقة عملية لنشر تطبيق Node.js أو Next.js على VPS باستخدام Docker Compose وNginx reverse proxy وSSL. الهدف ليس أن تحفظ أوامر كثيرة، بل أن تفهم شكل البنية التي يمكنك الاعتماد عليها عندما يصبح المشروع حقيقيا: موقع شركة مبني بـ Next.js، لوحة تحكم Node.js، API، أو تطبيق SaaS صغير يحتاج استقرارا وسهولة تحديث.

لو كنت ما زلت تقارن بين cPanel وVPS وCloud، ابدأ أولا من مقارنة cPanel وVPS وCloud Hosting. أما هذا المقال فهو للمرحلة التالية: اخترت VPS بالفعل، وتريد نشر التطبيق بطريقة مرتبة.

الخلاصة السريعة

البنية المقترحة في أغلب المشاريع الصغيرة والمتوسطة تكون كالتالي:

User
  ↓
Domain DNS
  ↓
Nginx على السيرفر
  ↓
Docker container للتطبيق
  ↓
Node.js / Next.js runtime
  ↓
Database / Redis / External APIs

لماذا هذه البنية جيدة؟

Nginx يستقبل الزيارات العامة على 80 و443.
التطبيق لا يظهر مباشرة للإنترنت، بل يعمل داخليا على port مثل 3000.
Docker يجعل بيئة التشغيل قابلة للتكرار، فلا تعتمد على إعدادات عشوائية داخل السيرفر.
Docker Compose يدير التطبيق وقاعدة البيانات والخدمات المساعدة من ملف واحد.
SSL يحمي الاتصال ويمنع تحذيرات المتصفح.
التحديث يصبح أوضح: build جديد، ثم recreate للـ container، ثم مراقبة logs.

هذه ليست البنية الوحيدة، لكنها نقطة بداية قوية لمعظم تطبيقات Node.js وNext.js التي لا تحتاج Kubernetes أو منصة معقدة.

متى يناسبك نشر التطبيق على VPS؟

نشر تطبيق Node.js أو Next.js على VPS مناسب عندما تحتاج:

تحكما أعلى من الاستضافة المشتركة.
تشغيل API أو background workers أو WebSocket.
إعدادات Nginx مخصصة.
ربط التطبيق بقاعدة بيانات أو Redis أو خدمات داخلية.
تكلفة ثابتة أوضح من بعض منصات serverless.
نشر مشروع عميل على سيرفر مستقل.
تعلم production deployment بطريقة عملية.

لكن VPS ليس مناسبا إذا لم تكن مستعدا لتحمل مسؤولية الأمان والتحديثات والنسخ الاحتياطي. الاستضافة المرنة لا تعني أنها تدير نفسها.

إذا كان مشروعك أكبر ويحتاج autoscaling وclusters وفريق تشغيل، فراجع لاحقا كورس Kubernetes بالعربي. أما لو عندك تطبيق واحد أو عدة خدمات صغيرة، فـ Docker Compose على VPS غالبا كاف كبداية.

المتطلبات قبل البدء

قبل تنفيذ أي خطوة، تأكد أن لديك:

المطلوب	لماذا تحتاجه؟
VPS بنظام Ubuntu أو Debian	بيئة Linux مستقرة وسهلة التوثيق
Domain موجه إلى IP السيرفر	حتى يعمل SSL وNginx باسم نطاق حقيقي
SSH access	لإدارة السيرفر بأمان
Docker وDocker Compose	لتشغيل التطبيق داخل containers
Nginx	ليعمل reverse proxy أمام التطبيق
Certbot أو SSL من مزودك	لتفعيل HTTPS
ملف `.env` منفصل	لحفظ المتغيرات الحساسة خارج الكود
خطة نسخ احتياطي	لأن السيرفر بدون backup مخاطرة حقيقية

هذا الدليل يفترض أنك تستخدم Ubuntu حديث، وأن التطبيق يعمل محليا قبل نقله للسيرفر.

القرار الأول: Node.js عادي أم Next.js؟

طريقة النشر تختلف قليلا حسب نوع المشروع.

تطبيق Node.js API

إذا كان لديك Express أو Fastify أو NestJS، فالـ container غالبا يشغل أمرا مثل:

npm run start

أو:

node dist/server.js

حسب طريقة build في مشروعك.

تطبيق Next.js

إذا كنت تنشر Next.js على VPS، الأفضل غالبا تفعيل وضع standalone حتى ينتج Next.js نسخة production أخف تحتوي الملفات المطلوبة للتشغيل.

مثال في next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "standalone"
};

module.exports = nextConfig;

هذا مهم لأن Next.js في production ليس مجرد ملفات static دائما. إذا كنت تستخدم Server Components أو API routes أو dynamic rendering، فأنت تحتاج runtime يعمل على Node.js.

تجهيز السيرفر بشكل مبدئي

ابدأ بتحديث النظام:

sudo apt update
sudo apt upgrade -y

ثم أنشئ مستخدما خاصا بالنشر بدلا من العمل الدائم على root:

sudo adduser deploy
sudo usermod -aG sudo deploy

بعدها فعّل الجدار الناري للسماح فقط بالمنافذ الأساسية:

sudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

الفكرة هنا بسيطة: السيرفر يجب أن يسمح بـ SSH وHTTP وHTTPS فقط في البداية. لا تفتح port التطبيق مثل 3000 للعالم الخارجي.

تثبيت Docker وDocker Compose

بعد تثبيت Docker بالطريقة المناسبة لنظامك، تأكد من عمله:

docker --version
docker compose version

ثم أضف مستخدم النشر إلى مجموعة Docker إذا كنت تريد تشغيل الأوامر بدون sudo:

sudo usermod -aG docker deploy

بعدها اخرج من SSH وادخل مرة أخرى حتى يتم تطبيق الصلاحيات.

تنبيه مهم: صلاحية Docker قوية جدا، لذلك لا تعطيها لأي مستخدم غير موثوق.

هيكل ملفات مقترح على السيرفر

يمكنك وضع المشروع في مسار واضح:

/var/www/my-app
  ├── Dockerfile
  ├── compose.yaml
  ├── .env
  ├── package.json
  ├── src/
  └── ...

لا ترفع .env إلى Git. اجعله موجودا على السيرفر فقط أو استخدم secrets في بيئة أكثر تقدما.

لو كنت تنشر عدة مشاريع، استخدم أسماء واضحة:

/var/www/client-api
/var/www/company-next-site
/var/www/admin-dashboard

الوضوح هنا مهم، لأنك بعد أشهر ستحتاج فهم ما الذي يعمل على السيرفر بسرعة.

Dockerfile لتطبيق Node.js

هذا مثال عام لتطبيق Node.js يحتاج build قبل التشغيل:

FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:22-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev

COPY --from=builder /app/dist ./dist

EXPOSE 3000
CMD ["node", "dist/server.js"]

ما الذي يهم في هذا الملف؟

يستخدم multi-stage build حتى لا تحمل صورة production كل أدوات البناء.
يستخدم npm ci بدلا من npm install للحصول على تثبيت قابل للتكرار.
يشغل التطبيق في NODE_ENV=production.
ينسخ ملفات التشغيل فقط.

قد تحتاج تعديل dist/server.js حسب مشروعك. في NestJS مثلا قد يكون الملف dist/main.js.

Dockerfile لتطبيق Next.js

لو كان مشروعك Next.js مع output: "standalone"، استخدم فكرة قريبة من هذا المثال:

FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:22-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV PORT=3000

COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

EXPOSE 3000
CMD ["node", "server.js"]

ملاحظات مهمة:

تأكد أن next.config.js يحتوي output: "standalone".
إذا كنت تستخدم next/image في production، راجع احتياج sharp حسب إعدادات مشروعك.
لا تنسخ .env داخل الصورة. مرر المتغيرات وقت التشغيل من Docker Compose.

ملف Docker Compose للإنتاج

استخدم compose.yaml لإدارة التطبيق:

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: my-app
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "127.0.0.1:3000:3000"
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:3000/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 20s

لاحظ هذا السطر:

ports:
  - "127.0.0.1:3000:3000"

هذا يعني أن التطبيق متاح محليا على السيرفر فقط، وليس مكشوفا للعالم. Nginx هو الذي يستقبل الزيارات العامة ويمررها للتطبيق.

إذا لم يكن لديك endpoint مثل /health، أضفه في التطبيق أو عدل healthcheck حسب مشروعك.

مثال health endpoint

في تطبيق Express بسيط:

app.get("/health", (req, res) => {
  res.status(200).json({
    status: "ok",
    uptime: process.uptime()
  });
});

وجود health endpoint يساعدك في:

معرفة هل التطبيق يستجيب أم لا.
كتابة healthcheck في Docker Compose.
مراقبة التطبيق لاحقا من أدوات خارجية.

لا تضع داخله معلومات حساسة مثل مفاتيح أو تفاصيل قاعدة البيانات.

إعداد متغيرات البيئة

مثال ملف .env:

NODE_ENV=production
PORT=3000
DATABASE_URL=postgresql://user:password@db:5432/app
SESSION_SECRET=change-this-secret
PUBLIC_SITE_URL=https://example.com

قواعد مهمة:

لا ترفع .env إلى Git.
لا تكتب secrets داخل Dockerfile.
لا تستخدم نفس أسرار بيئة التطوير في production.
غير المفاتيح عند تسليم المشروع أو نقل الملكية.
استخدم Docker secrets عندما يصبح المشروع أكثر حساسية.

المشكلة الشائعة أن المطور ينجح في تشغيل التطبيق محليا، ثم يفشل على السيرفر لأن متغيرا واحدا ناقص. لذلك اجعل لديك ملف .env.example داخل Git بدون قيم حقيقية:

NODE_ENV=production
PORT=3000
DATABASE_URL=
SESSION_SECRET=
PUBLIC_SITE_URL=

إعداد Nginx reverse proxy

أنشئ ملف إعداد لموقعك:

sudo nano /etc/nginx/sites-available/example.com

مثال إعداد أساسي:

server {
    listen 80;
    server_name example.com www.example.com;

    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-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

فعّل الملف:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

إذا نجح nginx -t، فهذا يعني أن صيغة الإعداد سليمة. لا تتجاوز هذه الخطوة، لأن خطأ بسيطا في Nginx قد يوقف كل المواقع على السيرفر.

دعم WebSocket إذا كان التطبيق يحتاجه

إذا كان لديك WebSocket أو Socket.IO، أضف headers الترقية:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

لا تضف إعدادات WebSocket إذا لم تكن تحتاجها. اجعل الإعداد بسيطا بقدر الإمكان.

تفعيل SSL

بعد أن يعمل الموقع على HTTP، فعّل SSL. باستخدام Certbot مع Nginx، تكون الفكرة غالبا:

sudo certbot --nginx -d example.com -d www.example.com

ثم اختبر التجديد التلقائي:

sudo certbot renew --dry-run

قبل تشغيل Certbot، تأكد من:

الدومين يشير فعلا إلى IP السيرفر.
المنفذ 80 مفتوح.
Nginx يعمل بدون أخطاء.
لا توجد redirects متضاربة من لوحة الاستضافة أو CDN.

SSL ليس رفاهية. بدونه ستخسر ثقة المستخدم، وقد تتأثر بعض خصائص المتصفح، وستظهر تحذيرات مزعجة في الزيارات.

تشغيل التطبيق بعد تجهيز الملفات

بعد تجهيز الملفات، يمكنك تشغيل التطبيق:

docker compose up -d --build

راجع حالة الـ containers:

docker compose ps

راجع logs:

docker compose logs -f app

اختبر التطبيق محليا من السيرفر:

curl http://127.0.0.1:3000/health

ثم اختبر الدومين:

curl -I https://example.com

لا تعتبر النشر ناجحا لمجرد أن container يعمل. النشر ناجح عندما:

الدومين يفتح.
HTTPS يعمل.
الصفحة الأساسية ترجع 200.
لا توجد redirects خاطئة.
logs لا تحتوي أخطاء مستمرة.
صفحة health تستجيب.
التطبيق يستطيع الاتصال بقاعدة البيانات والخدمات الخارجية.

كيف تحدث التطبيق بدون تعطيل طويل؟

في أبسط سيناريو:

git pull
docker compose build app
docker compose up -d --no-deps app
docker compose logs -f app

هذا يعيد بناء صورة التطبيق ثم يعيد تشغيل خدمة app فقط بدون إعادة تشغيل الخدمات الأخرى مثل قاعدة البيانات.

في المشاريع الأكثر جدية، اجعل لديك script واضح:

#!/usr/bin/env bash
set -e

git pull
docker compose build app
docker compose up -d --no-deps app
docker compose ps

ثم لاحقا يمكنك تحويل ذلك إلى CI/CD باستخدام GitHub Actions، لكن لا تبدأ بالأتمتة قبل أن تفهم خطوات النشر اليدوية.

ماذا عن قاعدة البيانات؟

هناك خياران شائعان:

قاعدة بيانات داخل Docker Compose

مناسب للتجارب والمشاريع الصغيرة، بشرط وجود volume وbackup:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app_user
      POSTGRES_PASSWORD: change-this-password
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

قاعدة بيانات مُدارة خارج السيرفر

مناسب عندما تريد تقليل مسؤولية الإدارة، أو عندما تكون البيانات أهم من توفير التكلفة.

القاعدة العملية: إذا كانت قاعدة البيانات مهمة تجاريا، فالنسخ الاحتياطي والمراقبة أهم من مكان تشغيلها.

النسخ الاحتياطي ليس اختياريا

أكبر خطأ في نشر تطبيق على VPS هو الاهتمام بالتشغيل ونسيان الاسترجاع.

اسأل نفسك:

هل لدي نسخة من قاعدة البيانات؟
هل النسخ الاحتياطي خارج نفس السيرفر؟
هل جربت الاسترجاع فعلا؟
هل أعرف أين توجد ملفات uploads؟
هل لدي نسخة من .env في مكان آمن؟

Backup غير مختبر يساوي تقريبا عدم وجود backup.

لو كان التطبيق يحتوي ملفات يرفعها المستخدمون، لا تكتف بنسخة قاعدة البيانات. تحتاج نسخ مجلد uploads أو استخدام object storage مثل S3-compatible storage.

مراقبة التطبيق بعد النشر

بعد النشر، تحتاج رؤية ما يحدث.

ابدأ بالأبسط:

docker compose logs -f app
docker stats
df -h
free -m

ثم أضف لاحقا:

مراقبة uptime خارجية.
تنبيه عند توقف الموقع.
تتبع errors.
مراقبة CPU وRAM وDisk.
Logs منظمة.
OpenTelemetry إذا كان التطبيق يحتوي خدمات متعددة.

إذا وصلت لمرحلة تريد فهم البطء والأخطاء عبر services متعددة، اقرأ شرح OpenTelemetry وObservability بالعربي.

أساسيات الأمان قبل الإطلاق

قبل أن تعتبر الموقع جاهزا، راجع هذه النقاط:

أغلق أي port غير مستخدم.
لا تكشف port التطبيق للعامة.
استخدم SSH keys بدلا من password login إن أمكن.
حدّث النظام وDocker بانتظام.
لا تضع secrets في Git.
استخدم كلمات مرور قوية وقيم عشوائية للجلسات.
اضبط CORS حسب الدومينات المطلوبة فقط.
لا تعرض stack traces للمستخدم في production.
راقب محاولات الدخول والأخطاء المتكررة.
فعّل rate limiting إذا كان لديك endpoint حساس.

ولمراجعة أوسع على مستوى التطبيق نفسه، راجع Checklist أمان تطبيقات الويب.

أخطاء شائعة عند نشر Node.js أو Next.js على VPS

تشغيل التطبيق بـ npm run dev

بيئة development ليست production. لا تستخدم:

npm run dev

على سيرفر حقيقي. استخدم build وتشغيل production.

فتح port 3000 للعالم

لا تجعل المستخدم يصل مباشرة إلى:

http://example.com:3000

اجعل Nginx هو الواجهة العامة، والتطبيق داخلي.

تجاهل redirects

اختبر:

curl -IL http://example.com
curl -IL https://example.com
curl -IL http://www.example.com
curl -IL https://www.example.com

يجب أن تصل في النهاية إلى نسخة واحدة واضحة بدون loops أو سلاسل طويلة.

حفظ الملفات داخل container فقط

أي ملف تحفظه داخل container قد يضيع عند إعادة البناء. استخدم volumes أو object storage للملفات الدائمة.

عدم تحديد خطة rollback

قبل التحديث، اسأل: إذا فشل الإصدار الجديد، كيف أرجع للإصدار السابق؟

حتى لو كانت الإجابة بسيطة في البداية، يجب أن تكون موجودة.

هل أستخدم PM2 بدلا من Docker؟

PM2 مفيد لتشغيل Node.js مباشرة على السيرفر، وكثير من المشاريع استخدمته بنجاح. لكن Docker يعطيك عزلا أوضح لبيئة التشغيل، ويسهل نقل المشروع بين سيرفرات، ويقلل مشاكل اختلاف إصدارات Node.js والحزم.

استخدم PM2 إذا كان المشروع بسيطا جدا أو السيرفر مُدار بطريقة تقليدية. استخدم Docker Compose إذا كنت تريد بنية أكثر قابلية للتكرار وتضم أكثر من خدمة أو تحتاج تسليم المشروع بشكل منظم.

هل أستخدم VPS أم Vercel لتطبيق Next.js؟

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

تحكما كاملا في السيرفر.
تشغيل خدمات خلفية بجانب Next.js.
تكلفة ثابتة لمشروع معروف الحجم.
ربط مباشر مع Nginx وDocker وخدمات داخلية.
شروط استضافة أو بيانات محددة.

لا يوجد اختيار واحد صحيح دائما. الاختيار يعتمد على طبيعة المشروع، الفريق، الميزانية، والحاجة للتوسع.

متى تنتقل إلى Kubernetes؟

لا تنتقل إلى Kubernetes فقط لأنك سمعت أنه احترافي. Kubernetes يحل مشاكل حقيقية، لكنه يضيف تعقيدا حقيقيا أيضا.

فكر في Kubernetes عندما:

لديك عدة خدمات تحتاج orchestration.
تحتاج scaling أفقي متكرر.
لديك فريق يتعامل مع CI/CD وmonitoring وsecrets.
تحتاج deployments متقدمة وrollbacks منظمة.
البنية أصبحت أكبر من سيرفر واحد.

أما تطبيق واحد أو تطبيقان على VPS، فـ Docker Compose غالبا أبسط وأوضح.

مراجعة قبل إطلاق التطبيق

استخدم هذه القائمة قبل تسليم المشروع أو إطلاقه:

هذه القائمة أهم من أي أمر واحد في الدليل. معظم مشاكل production تأتي من تفاصيل صغيرة تُنسى قبل الإطلاق.

متى تحتاج مساعدة في إعداد الخادم؟

إذا كان المشروع تجاريا أو مرتبطا بعميل، لا تجعل أول تجربة production هي يوم الإطلاق. الأفضل تجهيز السيرفر، اختبار النشر، ضبط SSL، مراجعة redirects، وتجربة backup قبل تحويل الزيارات الحقيقية.

يمكنني مساعدتك في إعداد الاستضافة والخوادم لتطبيقات Node.js وNext.js وWordPress وWooCommerce، أو بناء تطبيق ويب مخصص من البداية مع خطة نشر واضحة.

مصادر رسمية مفيدة

هذه مصادر جيدة للرجوع إليها عند التطبيق:

أسئلة شائعة

هل أحتاج Docker لنشر تطبيق Node.js على VPS؟

لا، يمكنك نشر Node.js مباشرة باستخدام PM2 أو systemd. لكن Docker يجعل بيئة التشغيل أوضح وأسهل في النقل والتكرار، خاصة عندما يكون لديك أكثر من خدمة أو تريد تسليم المشروع بشكل منظم.

هل يمكن نشر Next.js على VPS بدلا من Vercel؟

نعم. Next.js يمكن تشغيله ذاتيا على Node.js أو داخل Docker، خصوصا عند استخدام output: "standalone". لكن يجب أن تضبط Nginx وSSL والمتغيرات والتحديثات بنفسك.

هل أحتاج Nginx مع Docker؟

في أغلب الحالات نعم. Nginx يعمل كـ reverse proxy أمام التطبيق، يدير HTTP وHTTPS، ويمرر الطلبات إلى container داخلي. هذا أفضل من كشف port التطبيق مباشرة للعالم.

هل VPS يكفي أم أحتاج Kubernetes؟

إذا كان لديك تطبيق واحد أو عدة خدمات صغيرة، غالبا VPS مع Docker Compose يكفي كبداية. Kubernetes يصبح منطقيا عندما تحتاج إدارة خدمات كثيرة، scaling، deployments متقدمة، وفريق قادر على تشغيل هذه البنية.

ما أهم خطأ في نشر تطبيق Node.js في production؟

أهم خطأ هو تشغيل المشروع كأنه ما زال في development: استخدام npm run dev، فتح ports للعامة، غياب SSL، عدم وجود backup، وعدم اختبار التحديث أو rollback قبل الإطلاق.

الخطوة التالية

هل تحتاج اختيار أو إعداد استضافة مناسبة؟

إذا كنت تقارن بين خطط الاستضافة أو تنقل موقعا أو تضبط DNS وSSL والبريد، يمكنني مساعدتك في اختيار وإعداد المسار الأنسب للموقع.

راجع خدمة الاستضافة والخوادم

نماذج عملية

مشاريع مرتبطة بما قرأته

هذه روابط داخلية لدراسات حالة قريبة من موضوع المقال حتى ترى كيف يظهر نفس القرار في مشروع حقيقي.

متجر إلكتروني عربي للأغذية