لماذا تستضيف Nuxt على VPS؟
لا تدعم منصات الاستضافة المشتركة Node.js بشكل أصلي، مما يجعل استضافة تطبيق Nuxt مستحيلة دون VPS أو خادم مخصص. يتيح لك الـ VPS اختيار إصدار Node.js الذي تريده، وتهيئة بروكسي عكسي (Nginx أو Caddy) على المنفذ الذي تختاره، وإدارة شهادات TLS الخاصة بك — كل ذلك دون قيود اصطناعية على موارد CPU أو الذاكرة. هذا هو الحل الأمثل للمطورين المستقلين والشركات الصغيرة والمتوسطة التي تريد التحكم الكامل في مكدسها التقني.
على عكس حلول PaaS أو serverless، لا يُفوتر الـ VPS لكل تنفيذ ولا يضع سقفاً لأوقات الاستجابة: استدعاء API يستغرق أقل بكثير من ثانية لا يكلفك شيئاً إضافياً. كما تحتفظ بالسيطرة الكاملة على ترويسات HTTP وذاكرة التخزين المؤقت وإعدادات TLS.
SSR أم SSG أم SPA: أي وضع عرض تختار لمشروعك في Nuxt؟
مرّر الجدول أفقيًا
| الوضع | العرض | هل يحتاج عملية Node؟ | الأنسب لـ |
|---|---|---|---|
| SSR (ssr: true) | عند الطلب، من جانب الخادم | نعم — PM2 دائم | تطبيق ديناميكي، SEO، محتوى مخصص |
| SSG (nuxt generate) | وقت البناء، HTML ثابت | لا — يكفي nginx | مدونة، صفحة هبوط، محتوى نادر التحديث |
| SPA (ssr: false) | في المتصفح | لا — يكفي nginx | لوحة تحكم داخلية، تطبيق محمي بتسجيل دخول |
| Hybrid (routeRules) | حسب المسار: SSR + SSG ممزوجان | نعم — خادم Nitro | تطبيق بصفحات ثابتة ومسارات API |
ما يمكنك فعله مع Nuxt على VPS
يفتح لك VPS من ServOrbit مع قالب Nuxt المُعدّ مسبقاً أربعة محاور تغلقها الاستضافة المشتركة أو منصات PaaS:
إمكانيات فعلية على VPS
- خدمة تطبيق Nuxt في وضع SSR لتحسين محركات البحث وتقليل أوقات التحميل — يبقي PM2 عملية Nitro نشطة ويعيد تشغيلها تلقائياً بعد التعطل أو إعادة تشغيل الخادم
- نشر موقع ثابت تم إنشاؤه بـ
nuxt generateوتقديمه عبر Nginx دون عملية Node.js دائمة — مثالي للمدونات وصفحات الهبوط - استضافة مشاريع Nuxt متعددة على نفس الـ VPS باستخدام بروكسي عكسي و Virtual Hosts لـ Nginx — كل تطبيق يعمل على منفذه الداخلي الخاص
- تهيئة متغيرات البيئة الحساسة (مفاتيح API، اتصالات DB) مباشرة على الخادم في
/etc/environmentأو عبر ملف.envخارج مستودع Git - تفعيل مسارات API الخاصة بـ Nitro (
server/api/) لعرض طبقة backend خفيفة من نفس عملية Node.js، دون خادم Express منفصل - أتمتة النشر باستخدام ملف ecosystem لـ PM2، أو webhook من GitHub، أو خط CI/CD يصل إلى الـ VPS عبر SSH
- تفعيل HTTPS تلقائياً مع Let's Encrypt عبر Certbot لتأمين المستخدمين دون تكلفة شهادة
تثبيت Nuxt ونشره على VPS من ServOrbit
طلب VPS Cloud من ServOrbit
توجه إلى صفحة
/vps-cloudواختر الخطة المناسبة لمشروعك. لتطبيق Nuxt في وضع SSR، خطط لـ 1 vCPU و1 جيجابايت RAM على الأقل؛ 2 جيجابايت تستوعب بكل راحة عملية Nitro والبروكسي العكسي وطفرات التجميع أثناء النشر. إذا كنت تستضيف تطبيقات Nuxt متعددة، ابدأ بـ 2 vCPU / 4 جيجابايت. أكمل الطلب وادخل إلى بوابة العميل بعد تسليم الـ VPS — عادةً في أقل من دقيقة.تثبيت Nuxt من Marketplace
سجّل الدخول إلى بوابة عميل ServOrbit، انتقل إلى قسم Marketplace من لوحة تحكم الـ VPS، ثم ابحث عن Nuxt. انقر على البطاقة وأكد التثبيت. يُهيئ السكريبت تلقائياً Node.js LTS وPM2 كمدير عمليات وNginx كبروكسي عكسي على المنفذ 80 (و443 إذا تم تحديد نطاق). تستغرق العملية أقل من دقيقتين.
نشر تطبيقك وإعداد متغيرات البيئة
اتصل عبر SSH (
ssh root@<IP-الـ VPS>)، ثم استنسخ مستودعك في الدليل المُعدّ:git clone https://github.com/your-org/your-app.git /var/www/nuxt-app cd /var/www/nuxt-app npm installأنشئ ملف
.envخارج مستودع Git مع متغيرات وقت التشغيل:NUXT_PUBLIC_API_BASE=https://api.your-domain.com NUXT_SECRET_KEY=your-private-key DATABASE_URL=postgres://user:pass@localhost/mydbيقرأ Nuxt 3 المتغيرات ذات البادئة
NUXT_عبرuseRuntimeConfig()— متغيراتNUXT_PUBLIC_*معروضة من جانب العميل، والأخرى للخادم فقط. لا تلتزم أبداً بملف.env: أضفه إلى.gitignoreمنذ البداية.بناء التطبيق وتشغيله مع PM2
جمّع التطبيق للإنتاج:
npm run buildيُنشئ Nuxt 3 مجلد
.output/الذي يحتوي خادم Nitro. شغّله مع PM2 في وضع cluster لاستخدام جميع أنوية CPU:pm2 start .output/server/index.mjs -i max --name nuxt-app pm2 save pm2 startupتحقق من الحالة:
pm2 status— يجب أن تكون الحالاتonline. لإعادة التحميل دون توقف أثناء النشر:pm2 reload nuxt-app.إعداد Nginx كبروكسي عكسي وتوجيه نطاقك
يثبّت قالب Marketplace Virtual Host جاهزاً في
/etc/nginx/sites-available/nuxt-app. عدّله لتحديد اسم نطاقك وتفعيل تخزين الأصول الثابتة مؤقتاً:server { server_name your-domain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } location /_nuxt/ { proxy_pass http://127.0.0.1:3000; expires 1y; add_header Cache-Control "public, immutable"; } }أشر سجل DNS A إلى IP الـ VPS، ثم شغّل Certbot للحصول على شهادة TLS مجانية:
certbot --nginx -d your-domain.com. أعد تحميل Nginx:nginx -s reload. تطبيق Nuxt الخاص بك متاح الآن عبر HTTPS.أتمتة عمليات النشر التالية
للتحديثات، أنشئ سكريبت نشر في
/var/www/nuxt-app/deploy.sh:#!/bin/bash set -e cd /var/www/nuxt-app git pull origin main npm install --production=false npm run build pm2 reload nuxt-app echo "Deployment complete"اجعله قابلاً للتنفيذ (
chmod +x deploy.sh) وأطلقه من خط CI/CD عبر SSH:ssh root@<IP> /var/www/nuxt-app/deploy.sh.pm2 reload(وليسrestart) يضمن انتقالاً سلساً — ينتظر PM2 حتى تكون كل نسخة جديدة جاهزة قبل قطع النسخة القديمة.
متغيرات البيئة وإعداد وقت تشغيل Nuxt 3
يميّز Nuxt 3 بين مستويين من المتغيرات عبر useRuntimeConfig():
- runtimeConfig.public.* ← متاحة من جانب العميل والخادم (مثل URL API العامة، مفاتيح التتبع)
- runtimeConfig.* (غير عامة) ← للخادم فقط (مثل المفاتيح السرية، بيانات اعتماد DB)
متغيرات البيئة تتجاوزها تلقائياً وقت التشغيل باتباع اصطلاح NUXT_<NAME>. هذا يعني أنك لا تحتاج إلى إعادة البناء لتغيير URL API أو مفتاح وصول: فقط عدّل ملف .env على الخادم وأعد تحميل PM2 (pm2 reload nuxt-app). مفيد بشكل خاص لبيئات متعددة (staging، production) تشترك في نفس artifact البناء.
للأسرار الحرجة (توكنات DB، مفاتيح التشفير)، فضّل متغيرات مستوى النظام في /etc/environment على ملف .env في دليل التطبيق.
مراقبة السجلات وتشخيص الأخطاء
يُركّز PM2 سجلات تطبيق Nuxt في الوقت الفعلي. أوامر أساسية:
pm2 logs nuxt-app # البث المباشر (stdout + stderr)
pm2 logs nuxt-app --lines 100 # آخر 100 سطر
pm2 monit # لوحة CPU / الذاكرة في الوقت الفعليتُحفظ السجلات في ~/.pm2/logs/. قم بإعداد تدوير السجلات لتجنب امتلاء القرص:
pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 7لأخطاء Nginx (502، 503 عندما يكون PM2 متوقفاً)، راجع /var/log/nginx/error.log. خطأ 502 مستمر يعني عادةً أن عملية PM2 لا تعمل (pm2 status) أو أن المنفذ 3000 غير متاح من البروكسي.
تشخيص المشكلات الشائعة
ثلاثة مواقف تتكرر كثيراً عند نشر تطبيق Nuxt على VPS:
خطأ 502 Bad Gateway. لا يستطيع Nginx الوصول إلى عملية Nitro على المنفذ 3000. الأسباب الشائعة: لم يتم تشغيل pm2 start أو توقف (pm2 status للتحقق)، أو المنفذ 3000 محجوب بواسطة جدار الحماية (ufw allow 3000 مؤقتاً للاختبار)، أو انهار التطبيق عند الإطلاق (pm2 logs nuxt-app --lines 50 لقراءة الخطأ الأخير).
متغيرات البيئة غير محلولة. يُرجع useRuntimeConfig() قيمة undefined من جانب العميل لمتغير يجب أن يكون عاماً. تأكد من أن المتغير مسبوق بـ NUXT_PUBLIC_ في ملف .env، وأنك أعدت تشغيل PM2 بعد التعديل: pm2 reload nuxt-app. تُقرأ متغيرات البيئة فقط عند بدء تشغيل عملية Nitro، وليس في الوقت الفعلي.
صفحة بيضاء في الإنتاج بعد nuxt generate. يُعرض HTML الثابت لكن البيانات الديناميكية فارغة. هذه ليست مشكلة خادم — إنها مشكلة baseURL: من جانب الخادم أثناء الـ prerender، لا يملك $fetch بمسار نسبي أي أصل. مرّر URL كامل لـ API الخاص بك في NUXT_PUBLIC_API_BASE واستخدم useAsyncData مع useFetch بتحديد هذه القاعدة صراحةً في الصفحات التي تحتاج محتوى قابلاً للزحف.
نصيحة الأداء: وضع cluster في PM2. الأمر pm2 start .output/server/index.mjs -i max --name nuxt-app يشغّل عدداً من النسخ يساوي عدد أنوية CPU المتاحة ويوزع الحمل تلقائياً بينها. على VPS بـ 2 vCPU تحصل على عاملَيْن نشطَيْن من Nitro، مما يضاعف الإنتاجية على مسارات SSR. تحقق بـ pm2 status أن جميع النسخ في حالة online.
التوثيق الرسمي
للإعدادات المتقدمة والخيارات الخاصة بالأداة والتغييرات في الإصدارات، راجع التوثيق الرسمي لـ Nuxt. يغطي هذا الدليل الإطلاق على VPS من ServOrbit؛ وثائق الناشر تبقى المرجع للإعدادات الدقيقة (routeRules، Nitro presets، الوحدات الرسمية).