تحليل خبير مع مراجعات المستخدمين الموثقة من Hostinger
أنا وفّرت VPS لارفيل من Hostinger، وسويت عليه باكجمارك كامل للسيرفر، ورفعت تذاكر دعم Kodee AI بسؤالين تقنيين حقيقيين. زر واحد في لوحة التحكم ما سوّى اللي كان مكتوب عليه.
أنا وفّرت VPS لارفيل من Hostinger، وسويت عليه باكجمارك كامل للسيرفر، ورفعت تذاكر دعم Kodee AI بسؤالين تقنيين حقيقيين. زر واحد في لوحة التحكم ما سوّى اللي كان مكتوب عليه.
Hostginger يبيع Laravel VPS حقه كسيرفر مُثبّت عليه مسبقًا ومدار بالذكاء الاصطناعي ومصمم عشان يخلّي مشروع Laravel يشتغل بسرعة. أغلب هذا الوعد طلع صحيح تحت الاختبار الفعلي، نتائج قوية في البنشمارك، وكيل دعم ذكاء اصطناعي كفء، ونسخ احتياطية تأكدت إنها شغالة حسب الجدول.
زر واحد في لوحة التحكم ودّاني لمكان ما كنت أتوقع أوصل له أبدًا، ومن المهم تعرف عنه قبل لا تضغطه بنفسك. هنا التفصيل الكامل.
استضافة Hostinger Laravel VPS
اكتشف كيف توفر استضافة Hostinger Laravel VPS بيئة مرنة لنشر تطبيقات Laravel مع موارد خادم مخصصة، وتحكم كامل، وأداء قابل للتوسع، وتكوينات قابلة للتخصيص لمشاريع الويب الحديثة.
Tip أدر تطبيق Laravel حقك عبر Cloudpanel بدل زر Manage App، وتحقق من تبويب Security إذا تبي تفعّل ماسح البرمجيات الخبيثة فعليًا.
تفصيل التقييم
عشان أقيم استضافة Hostinger’s Laravel VPS، طبقت منهجية التقييم الخاصة بـ HostAdvice، نفس الأسلوب الموحد المستخدم في كل مراجعة بالموقع، عشان تظل الدرجات متسقة ومبنية على اختبار حقيقي بدل وعود تسويقية. هذا كيف طلعت الدرجة عبر كل معيار.
تبيع Hostinger استضافة Laravel كواحدة من أربع فئات KVM VPS، من KVM 1 إلى KVM 8، وكل فئة تزيد عدد الأنوية، والرام، ومساحة NVMe، والنطاق الترددي معًا كلما صعدت.
Laravel نفسه ما هو شراء منفصل، هو تطبيق بنقرة واحدة فوق أي فئة تختارها وقت الدفع، ومعه Cloudpanel مرفق كلوحة التحكم الفعلية لإدارة التثبيت بعد ما يصير شغال.
شروط الفوترة: الخطط تُدفع مقدمًا لمدة 1 أو 12 أو 24 شهر، ومع الفترات الأطول فيه خصومات حقيقية على السعر الشهري. شوف أداة الأسعار تحت للتفصيل الكامل حسب الفئة والمدة.
ضمان استرجاع الفلوس: خطط VPS معها ضمان 30 يوم، لكن الشروط الدقيقة تضيف قيد حقيقي. تقدر تطلب استرداد VPS مرة واحدة فقط كل 180 يوم، فلو طلبت استرداد ثاني على شراء VPS مختلف خلال هالفترة، ما بيمشي. والترقيات على الخطة الحالية مستثناة بالكامل.
تجربة مجانية: ما لقيت تجربة مجانية مخصصة لاستضافة Laravel VPS، فقط ضمان استرجاع الفلوس لمدة 30 يوم. خطط وقت التقييم على هذا الأساس.
طرق الدفع: بطاقة (Visa و Mastercard و Amex و Discover)، PayPal، Google Pay، AliPay بإصداري الصين وهونغ كونغ بشكل منفصل، وCoingate للعملات الرقمية. الدفع بالعملات الرقمية خارج سياسة الاسترداد تمامًا، فخل هذا ببالك إذا كان الضمان يهمك.
المرفقات: كل فئة تشمل دومين .cloud مجاني للسنة الأولى، ووصول root كامل، وتكامل Git، وCloudpanel بدون تكلفة إضافية، فالسعر الظاهر أقرب للتكلفة الفعلية من مضيفات ثانية تفرض رسوم منفصلة على لوحة التحكم.
إرشادات Hostinger نفسها تقول إن KVM 1 يكفي لموقع Laravel بسيط، بينما KVM 8 موصى به للمشاريع الثقيلة اللي تستهلك موارد كثيرة.
ومن الاختبار، بعد، ارتباك زر Manage App الخاص بإدارة التطبيق، وكون ماسح البرمجيات الخبيثة متوقف افتراضيًا، هذي الأمور تطبّق على كل الفئات بنفس الشكل، فالتوسعة للأعلى ما بتصلح هالمشكلتين. اختر خطتك بناءً على احتياج المعالج وحركة المرور، وتعامل مع هالنقطتين بالطريقة نفسها مهما كانت الفئة اللي تختارها.
الميزات
معالجات AMD EPYC في كل الفئات
تخزين NVMe SSD في كل الخطط
تكامل Git لتسهيل نشر الكود
وصول root كامل عبر SSH
لوحة تحكم Cloudpanel مرفقة افتراضيًا
وكيل ذكاء اصطناعي لمهام إدارة VPS
نسخ احتياطية أسبوعية تلقائية على كل خطة
سرعة شبكة 1 Gbps لكل خطة
دومين .cloud مجاني لمدة سنة
استضافة Hostinger Laravel VPS
اكتشف كيف توفر استضافة Hostinger Laravel VPS بيئة مرنة لنشر تطبيقات Laravel مع موارد خادم مخصصة، وتحكم كامل، وأداء قابل للتوسع، وتكوينات قابلة للتخصيص لمشاريع الويب الحديثة.
تطبيق Laravel يعيش أو يموت على الخادم اللي تحته مثل ما يعيش على الكود نفسه. تحميل الصفحات يعتمد على سرعة المعالج لتنفيذ PHP، واستعلامات قاعدة البيانات تعتمد على سرعة القرص، والجلسات والتخزين المؤقت يعتمدون على الذاكرة، وإذا كان التطبيق يشغّل مهام مجدولة أو عنده زوار فعليين، فإنتاجية الشبكة وقدرتها على التحمل تحت الضغط مهمة بعد.
Laravel نفسه ما يغيّر شي من هذا، هو ما زال PHP شغال على Linux، فهنا الاختبار الحقيقي هو الـ VPS.
سويت باقة اختبار كاملة على الخادم، تشمل المعالج والذاكرة والقرص والشبكة واختبار ضغط مستمر، عشان أشوف وش يقدّم هذا التقييم فعليًا وش يعني هذا لتطبيق حقيقي.
النسخة اللي اختبرتها كانت خطة KVM 2، وهي الخطة اللي اخترتها وقت الدفع:
CPU: 2 vCPUs، مأخوذة من مضيف يعمل بمعالج AMD EPYC 9354P
RAM: 7.8GB usable من أصل 8GB مخصصة، بالإضافة إلى 2GB swap
Disk: 96GB usable من أصل 100GB NVMe مخصصة
OS: Ubuntu 24.04.4 LTS، kernel 6.8.0-137-generic
قبل لا ندخل في الأرقام، من المهم تعرف إن تشكيلة Laravel VPS عند Hostinger تمشي على نفس أربع مستويات VPS مثل باقي نطاق VPS حقها، من KVM 1 إلى KVM 8، وKVM 2 هو ثاني أقل مستوى، أعلى شوي من أرخص خيار وبعيد عن مستويات KVM 4 و KVM 8 المصممة للأحمال الأكبر وتعدد التطبيقات.
اللي جاي يعكس مشروع Laravel صغير إلى متوسط، تطبيق واحد يخدم حركة مرور حقيقية لكنها محدودة، مو منصة كبيرة تشغّل عدة خدمات على نفس الصندوق.
1. أداء المعالج
أحادي النواة: 1,624.55 events per second، متوسط زمن استجابة 0.61ms، والنسبة المئوية 95 عند 0.64ms
متعدد الأنوية، نواتين: 2,864.02 events per second، متوسط زمن استجابة 0.70ms، والنسبة المئوية 95 عند 1.10ms
الانحراف المعياري لعدالة الخيوط: 182.50 على متوسط 14,321.5 events لكل خيط
هذا الرقم أحادي النواة وش يعني فعليًا في التطبيق. طلب Laravel المعتاد، مثل عرض Blade، وتشغيل كم استعلام Eloquent، وفحص الجلسة، يقضي أغلب وقته على نواة وحدة تنفذ شغل PHP بدل ما يتوزع على أكثر من نواة بنفس الوقت.
بزمن استجابة متوسط 0.61ms لكل حدث حسابي في هالاختبار، فالمعالج مو هو الجزء من المنظومة اللي بيخلّي الصفحة تحسها بطيئة.
الفرق بين المتوسط والنسبة المئوية 95 صغير بعد، 0.61ms مقابل 0.64ms، وهذا يعني الأداء كان ثابتًا بدل ما يكون فيه طلبات متقطعة تطول كثير عن الباقي، وهو نمط يطلع للمستخدمين كتحميل صفحات بطيء بشكل عشوائي.
نتيجة تعدد الخيوط هي الأهم لفهم التزامن. الانتقال من خيط واحد إلى خيطين ضاعف الإنتاجية تقريبًا، بكفاءة توسّع تقارب 88 بالمائة، وهذا يعني إن هالـ VPS ما يخسر كثير من قدرته بسبب الحمل الزائد أو بسبب مستأجرين ثانيين يتنافسون على نفس الأنوية الفعلية.
عمليًا، PHP-FPM وهو شغال بعمليتين worker على هالخطة يقدر يتعامل مع تقريبًا ضعف حجم الطلبات مقارنة بحالة خيط واحد قبل لا يصير المعالج هو عنق الزجاجة، بدل شيء أقل من الضعف، وهذا اللي تشوفه إذا كانت vCPUين متصارعة على الأنوية.
رقم عدالة الخيوط، حوالي 1.3 بالمائة تباين بين الخيطين، يؤكد إن النواتين سوّت تقريبًا نفس كمية الشغل بدل ما وحدة تشيل الحمل والثانية تكون فاضية. بالنسبة لموقع حقيقي، هذا يعني توزيع الطلبات بالتساوي على عمال PHP-FPM بدل ما تتكدس خلف العامل اللي يكون مشغول.
2. سرعة الذاكرة
Sequential Write: 5,865.22 MiB/sec
Sequential Read: 7,155.43 MiB/sec
سرعة الذاكرة مهمة لـ Laravel بشكل سهل يننسى. كل عملية بحث في OPcache، وكل قراءة جلسة، وكل array أو collection يبنيها تطبيقك أثناء معالجة الطلب، كلها تعيش في RAM، وإذا كان فيه طبقة كاش مثل Redis شغالة على نفس الصندوق، فهي تنافس على نفس عرض نطاق الذاكرة.
عند حوالي 5.9 GiB بالثانية للكتابة و7.2 GiB بالثانية للقراءة، يقدر هالـ VPS ينقل البيانات من وإلى الذاكرة بسرعة تكفي بحيث عمليات الذاكرة غالبًا ما تكون هي اللي تبطّئ الطلب، وعنق الزجاجة لتطبيق Laravel المعتاد غالبًا بيكون القرص أو الشبكة قبل RAM.
اللي يهم بالذاكرة أكثر بشكل مباشر هو السعة أكثر من السرعة. مع 7.8GB usable و2GB swap وراه، تقدر هالخطة تشغّل PHP-FPM وMySQL أو PostgreSQL ونسخة صغيرة من Redis مع بعض على نفس السيرفر لتطبيق واحد، لكنها ما تترك مساحة كبيرة إذا كنت تشغّل عدة مواقع على نفس VPS أو قاعدة بيانات عندها working set كبير.
الـ swap هو شبكة أمان لارتفاع مؤقت في الذاكرة، مو بديل عن RAM إذا كان التطبيق أصغر من المطلوب على هالخطة.
3. أداء القرص
Sequential Write: 740 MiB/s (776 MB/s)، و740 IOPS
Sequential Read: 749 MiB/s (785 MB/s)، و748 IOPS
Random 4K mixed read/write: تقريبًا 9,400 IOPS بكل اتجاه، وحوالي 36.7 MiB/s throughput لكل اتجاه
السرعة التسلسلية هي الرقم المهم للعمليات الكبيرة مرة وحدة، مثل استرجاع نسخة احتياطية لقاعدة بيانات، أو فك ضغط أرشيف مرفوع، أو كتابة ملف سجل كبير.
عند حوالي 740 إلى 750 MiB/s في الاتجاهين، ومع تقارب القراءة والكتابة ضمن اثنين بالمائة، ما فيه ضعف واضح في جهة دون الثانية مثل بعض التخزين السحابي اللي تكون فيه القراءة سريعة لكن الكتابة أبطأ بكثير.
أداء 4K العشوائي هو الرقم اللي يتنبأ فعليًا بشكل تجربة Laravel اليومية، لأن قاعدة البيانات ما تقرأ وتكتب على شكل كتل تسلسلية كبيرة، بل تقرأ وتكتب كتل صغيرة ومتناثرة عبر القرص وهي تدور على الصفوف وتحدّث الفهارس وتكتب سجل المعاملات.
أكثر من 9,000 IOPS شوي في كل اتجاه يعني تقريبًا 9,000 عملية قاعدة بيانات صغيرة في الثانية قبل ما يصير I/O القرص هو العامل المحدد.
تحميل صفحة Laravel المعتاد ممكن يطلق من كم استعلام إلى عشرات الاستعلامات حسب بناء التطبيق، وهذا يعني إن هذا القرص عنده مساحة لعدد معتبر من المستخدمين المتزامنين اللي يضغطون على قاعدة البيانات قبل ما تبدأ الاستعلامات تصطف منتظرة الوصول للقرص.
ويحتاج الأمر حمل كتابة واضح وثقيل، مثل تسجيل عالي الحجم، أو جدول طوابير مزدحم، أو كتابات كاش متكررة على القرص، عشان توصل لهذا السقف في هذا القرص.
4. سرعة الشبكة
Run 1: Download 990.06 Mbps، Upload 910.87 Mbps، idle latency 0.31ms، 0% packet loss
Run 2: Download 985.24 Mbps، Upload 947.82 Mbps، idle latency 0.27ms، 0% packet loss
الاختبارين وصلوا لسيرفر في Phoenix, Arizona، وهو نفس موقع الولايات المتحدة اللي اخترته وقت الدفع، قريب من سرعة جيجابت كاملة تقريبًا في الاتجاهين مع صفر فقدان حزم في المحاولتين.
بالنسبة لتطبيق Laravel، هذا الرقم يهم أكثر في شيئين، سرعة الخادم في تقديم الأصول وردود API للزوار، وإذا كان التطبيق يتصل بواجهات API خارجية أو يسحب بيانات من خدمات ثانية، فسرعة هالاتصالات الخارجة.
إنتاجية قريبة من الجيجابت تعني إن النطاق الترددي ما بيكون القيد لتطبيق ويب عادي، وتحتاج حجم كبير جدًا من نقل الملفات الكبيرة، أو الفيديو، أو التنزيلات الضخمة، أو التصديرات الجماعية، قبل لا يصير هذا هو العامل المحدد بدل المعالج أو القرص.
النتائج المتقاربة جدًا عبر اختبارين منفصلين، وبينهم دقايق قليلة، تستبعد بعد إنها نتيجة حظ مرة وحدة، هذا هو سلوك الاتصال بشكل ثابت بدل رقم ارتفع صدفة.
5. اختبار الضغط
شغّلت ضغوط على المعالج والذاكرة والقرص لمدة 180 ثانية لكل واحد عشان أشوف كيف يتحمل الخادم الحمل المستمر بدل الاندفاع القصير:
CPU stress، 2 workers: 540,042 bogo ops، 0 failures
Disk stress، 2 workers: 2,655,058 bogo ops، 0 failures
أرقام bogo ops الفردية أقل أهمية هنا من الشيء اللي ما صار.
صفر عمال فاشلين وصفر قياسات غير موثوقة عبر كل الاختبارات الثلاثة، والاختبارات انشغلت ورا بعض لمدة ثلاث دقائق كاملة لكل واحد، يعني الخادم قدر يبقي المعالج والذاكرة والقرص تحت ضغط متزامن بدون ما يطيح، أو يدخل في حالة غير مستقرة بسبب الخنق، أو يرجّع نتائج اعتبرها الاختبار نفسه مشبوهة. وهذا أقرب شيء لهالنوع من الاختبارات لمحاكاة طفرة حركة مرور فعلية، عدة موارد على آخرها
t مرة وحدة، وهذا هو الناتج الأهم لأي شخص قلق إن موقعه ينهار وقت الزحمة بدل ما يشتغل كويس فقط في اختبارات منفصلة واحد واحد.
الحكم النهائي على الأداء
خطة KVM 2 تؤدي بشكل جيد بالنسبة لها، كـ VPS صغير إلى متوسط وليس خطة رائدة. عمليًا، هذا الخادم عنده سرعة معالج أحادية كافية وعدد IOPS عشوائي للقرص كافٍ عشان يحافظ على سرعة صفحة Laravel المعتادة، ونقل الشبكة كافي بحيث ما يكون النطاق الترددي هو القيد لتطبيق ويب عادي، وكمان صمد بدون أي فشل تحت ثلاثة اختبارات ضغط متزامنة.
ولا لازم ينفهم من هذا إنه حكم على استضافة Laravel من Hostinger كلها، لأن هذا مستوى واحد من أربعة.
مشروع شخصي أصغر أو تطبيق منخفض الحركة ممكن يشتغل براحة على خطة KVM 1 الأرخص، بينما تطبيق Laravel يخدم حركة مرور إنتاجية حقيقية، ويشغّل مهام مجدولة، وعمال طوابير، وقاعدة بيانات كلها بنفس الوقت، من الأفضل له يروح إلى KVM 4 أو KVM 8 بدل ما يعتبر أرقام KVM 2 هي السقف. اختر بناءً على وش يحتاجه التطبيق فعليًا، مو بس على سعر البداية في صفحة الخطة.
استضافة Hostinger Laravel VPS
اكتشف كيف توفر استضافة Hostinger Laravel VPS بيئة مرنة لنشر تطبيقات Laravel مع موارد خادم مخصصة، وتحكم كامل، وأداء قابل للتوسع، وتكوينات قابلة للتخصيص لمشاريع الويب الحديثة.
اختبرت Laravel VPS حق Hostinger من وقت الدفع إلى فتح أدوات الإدارة الفعلية اللي تجي معه.
هذا شمل اختيار خطة وموقع الخادم، وإنشاء حساب، والدفع، وبعدها محاولة فهم كيف تدير نشر Laravel بعد ما يصير الخادم شغال. اللي جاي هو كيف كان هالشي فعليًا، بما في ذلك لحظة الواجهة اللي ودّتني لمكان ما كنت أتوقعه.
1. التسجيل
بدأت من صفحة Laravel VPS الرئيسية، اللي تبرز ثلاث مزاعم لازم تنحفظ:
نسخ احتياطية أسبوعية تلقائية مجانية
VPS مدار بالذكاء الاصطناعي
ماسح برمجيات خبيثة تلقائي
اخترت خطة KVM 2، وهي خيار متوسط معقول لتطبيق Laravel واحد بدل بناء يستهلك موارد كثيرة، ودخلت السلة.
من هناك، صفحة السلة حطت كل شيء على شاشة وحدة:
فترة الفوترة: 1 أو 12 أو 24 شهر، مع عرض التوفير لكل خيار
موقع الخادم: مناطق مجمعة حسب القارة، ومع كل وحدة تقدير للزمن
سوق التطبيقات: أكثر من ألف خيار بنقرة واحدة لأنظمة التشغيل واللوحات والتطبيقات
اخترت 24 شهر عشان السعر الأقل، وبعدها قضيت وقت أكثر من المعتاد على موقع الخادم.
المملكة المتحدة رجعت بأفضل زمن استجابة في القائمة، لكني نزلت على باقي المناطق عشان أقارن بعد. أمريكا الشمالية أعطت نتيجة جيدة للولايات المتحدة، وأسرع خيار في آسيا، ماليزيا، كان أبطأ بكثير من الاثنين.
وبما إن الموقع اللي في بالي بيخدم جمهور أغلبه أمريكي، اخترت الولايات المتحدة بدل خيار المملكة المتحدة اللي كان أسرع تقنيًا.
وهذي نقطة مهم تنذكر لأي قارئ يقارن المناطق في هالصفحة. أفضل زمن استجابة لك وأنت جالس عند لابتوبك مو هو الرقم اللي يهم. المهم هو زمن الاستجابة عند الناس اللي فعلًا بيدخلون على الموقع، فـ اختر بناءً على جمهورك، مو على نتائج اختبارك أنت.
بعدها نزلت على سوق التطبيقات، وكان Laravel محدد مسبقًا، بنفس نمط الإعداد بنقرة واحدة اللي تستخدمه Hostinger عبر كل كتالوج التطبيقات. ما احتجت أغيّر شيء هناك، فانتقلت مباشرة للدفع.
كنت مسجل دخول بحساب Hostinger موجود، فالتسجيل نفسه أخذ ضغطة وحدة.
بعدها، صفحة عنوان الفاتورة والدفع عرضت:
بطاقة، تشمل Visa و Mastercard و Amex و Discover
PayPal
Google Pay
AliPay، بإصداري الصين وهونغ كونغ
Coingate، للدفع بالعملات الرقمية
كل هذا في صفحة وحدة، بدون تحويل منفصل. أرسلت الدفع، وجاني إيميل تأكيد مباشرة، ورجعت إلى hPanel والـ server الجديد ظاهر كأنه شغال.
الشيء البارز هنا هو كم الخيارات اللي تعطيك Hostinger في الدفع بدون ما تجبرك على أي واحد منها.
مقارنة المواقع بالذات تستاهل تأخذها بجد، بدل ما تضغط وتكمل، لأن توصية الصفحة الافتراضية ما راح دائمًا تطابق من بيستخدم الخادم فعلًا.
2. لوحة التحكم/منطقة العميل
بعد ما تم الدفع، فتحت hPanel على الصفحة الرئيسية، وهي نفس لوحة الحساب المركزية اللي تدير الدومينات والإيميل وباني المواقع وVPS من مكان واحد.
رحبت فيني باسمي مع شريط Prompt للذكاء الاصطناعي، وصف من أزرار الاختصار، وقائمة مهام، وقائمة مستمرة بكل موقع وخادم على الحساب في الأسفل.
بعدها نزلت إلى جدول VPS، وهناك كان الخادم الجديد ظاهر بالفعل على إنه Running، مع اسم المضيف، عنوان IP، الخطة، وتاريخ الانتهاء كلها واضحة بدون ما أفتح أي شيء.
ضغطت Manage عشان أنتقل للوحة الخاصة بالخادم.
الوصول إلى الصفحة الرئيسية للحساب مباشرة بعد الدفع، مع الخادم مهيأ مسبقًا وموجود في القائمة، هو الجزء من هالرحلة اللي يشتغل فعلاً بشكل ممتاز باستمرار.
ما فيه شاشة انتظار منفصلة، ولا تحتاج تدور داخل القوائم عشان تلقى اللي اشتريته للتو.
3. إدارة Laravel والخادم
الضغط على Manage فتح صفحة VPS Overview، وهنا تبدأ الفروقات الحقيقية تظهر.
في أعلى الصفحة كان فيه بطاقة تطبيق باسم Laravel مع زر Manage App، وهذا أكد إن Laravel انثبت تلقائيًا أثناء التهيئة.
مباشرة تحتها كانت فيه بطاقة ثانية ما توقعتها:
Cloudpanel، مبني على Ubuntu 24.04
اسم المستخدم الإداري ظاهر كنص صريح
رابط إعادة تعيين كلمة المرور
زر Manage panel خاص فيه، منفصل عن بطاقة Laravel اللي فوق
البطاقة الثانية أهم مما تبين. Cloudpanel هو لوحة تحكم كاملة مرفقة مع Laravel، مو مجرد معالج إعداد مؤقت، وطلع إنه هو الواجهة الفعلية لإدارة الملفات والمواقع والخادم يوميًا.
وأنا أتمدد تحت البطاقتين، كان Ubuntu 24.04 الأساسي ظاهر تحت، ومبين إنه Running، مع أزرار إعادة التشغيل والـ terminal وبيانات root SSH معروضة بنفس طريقة أي VPS ثاني في هالحساب.
ولأن هذا الخادم توه متهيأ، الرسوم البيانية للموارد ما كانت معبأة بعد، وhPanel عرض رسالة تطلب مني أرجع بعد حوالي 30 دقيقة عشان بيانات الاستخدام، وهذا أسلوب صريح للتعامل مع خادم ما عنده تاريخ حركة مرور فعلًا بدل ما يعرض مخططات فاضية كأنها تعني شيء.
وفي الأسفل لقيت:
إدارة مفاتيح SSH
قواعد الجدار الناري
لقطات النسخ الاحتياطي
ماسح البرمجيات الخبيثة: Not installed
هذا السطر الأخير هو أول فجوة حقيقية. ماسح البرمجيات الخبيثة ظاهر على إنه Not installed، وهو جالس مباشرة تحت صفحة الخطة اللي تذكر ماسح برمجيات خبيثة تلقائي كواحدة من ثلاث ميزات رئيسية لهالمنتج. مهما كانت وعود التسويق، هو مو مفعّل افتراضيًا على الخادم اللي تستلمه فعليًا.
وبما إني كنت فضولي إذا كانت الميزة الثانية الرئيسية صاحية بشكل أفضل، فتحت Backups & Monitoring بعدين. سجل Latest Actions أظهر:
إجراء recreate مسجل بنفس اليوم
مدخلات weekly backup_create، وكلها marked Success، وتمتد لأكثر من شهر
هذا الادعاء طلع صحيح حسب سجلات الحساب نفسها، وهو تباين واضح مقابل ماسح البرمجيات الخبيثة اللي كان غير مفعّل على بعد قسم واحد.
من المهم تعرف إن Hostinger تسلّم بعض الميزات المعلنة افتراضيًا، وتخلّي بعض غيرها عليك تشغّلها بنفسك، والطريقة الوحيدة تعرف أيها أيها هي إنك تدور بنفسك، لأن صفحة الخطة تتعامل معها كأنها كلها مرفقة بنفس الدرجة.
بعدها رجعت إلى بطاقة Laravel وضغطت Manage App، متوقع إنها تفتح لي نوع من شاشة الإعداد أو إدارة الملفات الخاصة بـ Laravel مثل ما يسوي زر Cloudpanel فوق.
بدل هذا، فتحت صفحة بعنوان “Let’s get started”، فيها روابط إلى توثيق Laravel نفسه وفيديوهات Laracasts التعليمية، ومعها زر واحد تحت باسم Deploy now.
ضغطته على أي حال عشان أشوف وين بيروح، ووداني إلى laravel.com/cloud، صفحة التسجيل لـ Laravel Cloud.
هنا التمييز اللي لازم يكون واضح ودقيق.
Laravel Cloud مو منتج من Hostinger ولا له أي علاقة بالـ VPS اللي دفعت عليه للتو. هو منصة استضافة مُدارة بالكامل منفصلة، مطوّرة ومباعة مباشرة من فريق Laravel، وتنافس في نفس المجال مع خدمة مثل Vercel أو Heroku، مع حسابه الخاص وأسعاره الخاصة ورصيد الاستخدام المجاني حقه.
التسجيل هناك يعني إنك بتدفع لـ Laravel، فوق اللي دفعته أصلًا لـ Hostinger، عشان تستضيف تطبيقك في مكان مختلف تمامًا.
أما ليش Manage App يودّي هناك، فتأكدت من مقالة قاعدة المعرفة الرسمية اللي Kodee نفسها أشارت لها لما سألت: “How to use the Laravel VPS template at Hostinger.” هالمقالة تشرح الدخول إلى CloudPanel عبر عنوان IP حق الـ VPS على المنفذ 8443، وتعديل ملف .env، وتشغيل Composer وArtisan عبر SSH.
ما تذكر زر Manage App أبدًا، وما تذكر Laravel Cloud نهائيًا. فهنا مو حالة إن الشرح موجود بمكان ثاني وما انتبهت له.
دليل Hostinger الرسمي لهالقالب ما يعترف أصلًا إن هالزر موجود، وKodee، لما سألتها مباشرة، أكدت إن Manage App ما يدير الـ VPS وحذرت إن التسجيل في Laravel Cloud من هناك بيعني فاتورة ثانية منفصلة.
أي شخص يضغط Manage App وهو متوقع يدير التطبيق، ينتهي فيه المطاف على صفحة تسجيل لمنتج مدفوع مختلف تمامًا، بدون أي توثيق يوضح هذا مسبقًا.
الزر اللي فعليًا يوديك هناك موجود بطاقة واحدة تحت. Manage panel، في بطاقة Cloudpanel.
الضغط عليه يفتح شاشة دخول تطلب اسم مستخدم وكلمة مرور، وهنا لازم نكون دقيقين، لأن اللوحة ما تعطي أي تلميحات بعد ما توصل هالشاشة.
اسم المستخدم هو admin، وكلمة المرور هي كلمة مرور الخادم اللي Hostinger أرسلتها بالإيميل وقت أول تهيئة للـ VPS، مو كلمة مرور حساب Hostinger حقك.
إذا هالإيميل ضاع، رابط Reset الموجود جنب حقل كلمة المرور في بطاقة Cloudpanel ينشئ كلمة جديدة بدون ما تحتاج تدور في بريدك.
بعد تسجيل الدخول، يفتح Cloudpanel على قائمة Sites، مع اسم مضيف الـ VPS مهيأ مسبقًا كموقع حي، وPHP محدد كنوع التطبيق، ورابط Manage بجانبه.
فتح إعدادات هالموقع أظهر صف كامل من التبويبات، Settings، Vhost، Databases، Varnish Cache، SSL/TLS، Security، SSH/FTP، File Manager، Cron Jobs، وLogs.
هذا لوحة تحكم فعلية وشاملة، ومن المهم أذكر إن فيه تبويب Cron Jobs موجود هناك مباشرة. Kodee شرحت لي كيف أضيف سطر جدولة المهام يدويًا عبر SSH، وهذا يشتغل تمام، لكن Cloudpanel فيه طريقة بنقرة وواجهة تسوي نفس الشيء بدون لمس الطرفية أصلًا، ولا Kodee ولا مقالة قاعدة المعرفة ذكرت هالخيار.
وبكذا، الجهة الثانية هي اللي تعطينا التحكم الحقيقي، وإذا نزلت على صفحة إدارة الخادم فالقائمة الجانبية هي مكان الأدوات الحقيقية.
وهنا وش فيها:
Overview: صفحة الملخص نفسها، مع بطاقات Laravel وCloudpanel، واستخدام الموارد، وروابط سريعة لكل اللي تحت
Settings: إعدادات مستوى الخادم، وتشمل مثل إعادة تعيين كلمة مرور root وتغيير اسم المضيف
OS & Panel: التحكم بنظام التشغيل وبأي لوحة تحكم مثبّتة على الخادم
Backups & Monitoring: تتوسع إلى Snapshots & Backups، وServer Usage، وLatest Actions، وهنا لقيت سجل النسخ الاحتياطية الأسبوعية اللي أكد إن الادعاء صحيح
Security: يغطي ماسح البرمجيات الخبيثة وإعدادات الجدار الناري، وهو القسم اللي لقيت فيه الماسح متوقف
API: يفتح توثيق API حق Hostinger في تبويب جديد، لأي شخص يبغى أتمتة إدارة الخادم خارج اللوحة
DNS Manager: إدارة النطاق وسجلات DNS المرتبطة بالخادم
Tutorials: رابط خارجي لمحتوى المساعدة الخاص بـ Hostinger
هذا نطاق كافي عشان نعتبره تغطية كاملة لإدارة VPS. إعدادات الخادم، والتحكم بنظام التشغيل، والأمان، والنسخ الاحتياطية، وDNS، والوصول إلى API كلها ممثلة كفئات مستقلة بدل ما تكون مدفونة داخل قائمة إعدادات عامة، وما واجهت شيء كنت أحتاجه وما لقيته في هالقائمة.
اللي ما يسويه هو إنه يدمج أي أدوات خاصة بـ Laravel، نشر الكود، إدارة ملفات البيئة، تشغيل أوامر Artisan، كل هذا يصير عبر Cloudpanel أو الطرفية، مو عبر هذا الشريط الجانبي.
وهذا يوديني إلى زر terminal الموجود على بطاقة Ubuntu. هدفه الوصول المباشر لسطر الأوامر إلى الخادم نفسه، ويفتح جلسة SSH مباشرة داخل المتصفح بدون الحاجة إلى عميل SSH منفصل أو نسخ مفتاح خاص لجهازك.
الضغط عليه وداني مباشرة إلى root shell، مسجل دخول جاهز، ومعه لافتة ترحيب Cloudpanel على الشاشة تعرض عنوان الويب حقه وأداة CLI اسمها clpctl لإدارة اللوحة من سطر الأوامر.
لأي شخص مرتاح يشتغل من الطرفية، هذا أسرع طريق فعليًا لضبط تثبيت Laravel، ونشر الكود، وتعديل متغيرات البيئة، وتشغيل migrations، لأن ولا شيء من هالأشياء له زر مخصص داخل hPanel نفسه.
الحكم النهائي على سهولة الاستخدام
الدفع والمسار من إتمام الشراء إلى تشغيل الخادم شغالين بشكل ممتاز هنا، وإعطاء وزن حقيقي لاختيار موقع الخادم، بدل مجرد الافتراض على أي منطقة تختبر أسرع، لمسة صغيرة لكنها مفيدة لأي شخص يفكر في وين فعليًا بيسكن جمهور موقعه.
شريط إدارة الخادم نفسه يغطي كل شيء يحتاجه مدير VPS، الإعدادات، والتحكم في OS واللوحة، والنسخ الاحتياطية، والأمان، وDNS، والوصول إلى API، وكل وحدة مصنفة بوضوح، وما واجهت سدّة وأنا أدور على أي تحكم من مستوى VPS. لكن اللي يطيح هنا هو طبقة إدارة التطبيق.
ماسح البرمجيات الخبيثة المعلن في صفحة الخطة ما كان مثبت على الخادم اللي استلمته، والزر الوحيد المسمى لإدارة تطبيق Laravel يوديك إلى صفحة تسجيل لمنتج مدفوع منافس بدل أي شيء يشبه إدارة التطبيق.
Cloudpanel والطرفية يشتغلون مثل ما لازم بالضبط بعد ما توصل لهم، والنسخ الاحتياطية الأسبوعية تشتغل حسب الجدول مثل ما وُعد. المشكلة إن واجهة Hostinger نفسها توجهك للباب الغلط أول، وما فيه شيء داخل اللوحة يشرح إن Manage App مو إدارة التطبيق اللي كنت تدورها.
استضافة Hostinger Laravel VPS
اكتشف كيف توفر استضافة Hostinger Laravel VPS بيئة مرنة لنشر تطبيقات Laravel مع موارد خادم مخصصة، وتحكم كامل، وأداء قابل للتوسع، وتكوينات قابلة للتخصيص لمشاريع الويب الحديثة.
Kodee، مساعد Hostinger الذكي، موجود خلف زر Ask AI في hPanel ويتولى الدعم هنا، مثل باقي منتجات Hostinger.
اختبرته بسؤالين تقنيين مختلفين عن هالـ VPS، واحد عن مشكلة بالواجهة كنت صادفتها بالفعل، والثاني أعمق عن كيف يشتغل Laravel بالإنتاج على هالخادم.
بعدها، رحت على قاعدة المعرفة حق Hostinger عشان أشوف كم تغطي من هالمجال بدون الحاجة تسأل أحد.
1. دعم الذكاء الاصطناعي (Kodee)
أول سؤال جاء مباشرة من اختباري لزر Manage App الخاص ببطاقة Laravel، اللي كان فتح Laravel Cloud، منصة مدفوعة منفصلة، بدل أي شيء مرتبط بالـ VPS نفسه.
سألت Kodee مباشرة إذا كان هذا الزر المفروض يفتح Laravel Cloud أو يدير التثبيت الموجود أصلًا عبر Cloudpanel، ووش اللي بيصير فعلًا إذا سجلت في Laravel Cloud من هناك.
وردت Kodee خلال أقل من دقيقة:
أكدت إن Manage App ما يدير تثبيت الـ VPS الحالي
حددت بشكل صحيح إنه رابط إلى Laravel Cloud، منصة نشر منفصلة
أشارت إلى Cloudpanel، الممكن الوصول له عبر IP حق الـ VPS على المنفذ 8443، كواجهة الإدارة الحقيقية
حذرت إن التسجيل في Laravel Cloud بيخلق بيئة منفصلة مفوترة بشكل مستقل، وما بينشر شيء على الـ VPS اللي دفعت عليه أصلًا
هذا جواب نظيف وصحيح على سؤال له تكلفة فعلية إذا أخطأت فيه، وجاء مع استشهاد بتوثيق Hostinger نفسه بدل تخمين.
بعدها سألت سؤال أثقل تقنيًا. تطبيقات Laravel في الإنتاج تعتمد على مدخل cron لجدولة المهام وعلى عملية Supervisor عشان تبقي queue workers شغالة، وكنت أبغى أعرف إذا قالب الـ VPS يثبت أي شيء من هذا تلقائيًا، وهل Supervisor نفسه بيستمر بعد إعادة التشغيل إذا ضبطته بنفسي.
قالت Kodee إنها بتفحص الخادم مباشرة قبل ما ترد، وسوت هذا فعلًا:
أبلغت إنه ما فيه cron entry لـ schedule:run
أبلغت إنه ما فيه خدمة Supervisor مهيأة
أبلغت إنه ما فيه queue worker معد
قدمت سطر cron الدقيق المطلوب للـ scheduler
قدمت كتلة إعداد Supervisor كاملة لـ queue worker، مع flags الصحيحة
أكدت إن Supervisor يستمر بعد إعادة التشغيل بمجرد تفعيله عبر systemctl enable –now supervisor
وأضفت التذكير بتشغيل php artisan queue:restart بعد نشر كود جديد، وهي نقطة سهلة تننسى وتسبب مشاكل فعلية بالإنتاج إذا تُركت
وش رأيي في الدعم الذكي: Kodee استحقت إجاباتها هنا بدل ما تخمن. تأكيد عدم وجود cron للجدولة ولا Supervisor قبل اقتراح أي شيء هو الفرق بين إجابة قائمة تحقق وإجابة مبنية على وش كان هذا الخادم بالذات يسويه فعليًا، والتذكير بإعادة تشغيل queue worker بعد النشر من هالتفاصيل اللي ما تطلع إلا لما أحد، أو شيء، يفهم فعلًا كيف تتصرف Laravel queues بالإنتاج.
سؤالين، وجوابين دقيقين وكاملين، وكلها خلال دقيقتين تقريبًا.
2. قاعدة المعرفة
قاعدة معرفة Hostinger منظمة بنفس الطريقة عبر كل المنتجات، مربعات تصنيف كبيرة مع عدد المقالات، وشريط بحث، وفلتر أقسام في الأعلى.
بدل ما أتصفح، رحت مباشرة للبحث وكتبت “laravel”، وطلعت 15 نتيجة عبر صفحتين، أكثر بوضوح من اللي يطلعه one-click app أضيق.
وهنا فيه ملاحظة مهمة. كثرة النتائج ما تعني كثرة النتائج المناسبة، لأن عدة تطابقات كانت على الهامش فقط، مثل مقال عن قيود بريد PHP ومقال ثاني عن مشاكل نقل المواقع، وظهرت فقط لأنهم ذكروا Laravel بشكل عابر.
أكثر نتيجة مناسبة، “How to use the Laravel VPS template at Hostinger,” تغطي الدخول إلى Cloudpanel، وفهم هيكل مجلدات Laravel، وتعديل ملف .env، وتشغيل Composer، وتشغيل migrations.
وهي شرح جيد فعلًا لكيف تخلي مشروع Laravel يشتغل على هذا القالب. لكن اللي ما تغطيه هو scheduler أو queue workers أبدًا، وهي نفس الفجوة اللي Kodee اضطرّت يسدها لما سألت.
وبالتعمق أكثر في نتائج البحث، طلع شيء يستحق التنبيه. مقال أقدم، “How to deploy Laravel 8 at Hostinger”، فيه مثال cron شغال للـ scheduler، لكنه مكتوب لإعداد قديم مختلف تمامًا، ينشر Laravel يدويًا على استضافة مشتركة أو سحابية بدل قالب الـ VPS الحالي، وبنية public_html ما لها أي علاقة بطريقة ترتيب Cloudpanel على VPS.
أي شخص على قالب الـ VPS هذا ويبحث في قاعدة المعرفة عن إرشادات الجدولة ممكن يطيح على مقال يشرح منتج مختلف قبل ما يلقى أي شيء ينطبق فعلًا على خادمه.
وش رأيي في قاعدة المعرفة: عدد المقالات يبدو قوي على الورق، 15 نتيجة لكلمة بحث وحدة، لكن الحجم الخام يخفي قد إيش المحتوى المفيد متفرق فعلًا. مقال قالب الـ VPS الأساسي مكتوب بشكل جيد ويخليك تشغّل أول مشروع، لكنه يتوقف بالضبط عند النقطة اللي يصير فيها النشر الإنتاجي جدي، والمعلومة الوحيدة اللي تغطي scheduler موجودة في مقال يخص إعداد استضافة قديم وغير مرتبط.
القارئ اللي يعتمد على قاعدة المعرفة لحالها ممكن بسهولة يتبع هالدليل القديم ويضبط VPS حقه غلط لأنه نسخ أوامر مبنية لبنية ملفات مختلفة تمامًا.
الحكم النهائي على الدعم
Kodee هي اللي تشيل الحمل هنا، وتسويه بشكل ممتاز. المحادثتين كان فيهما فحص مباشر للحالة الفعلية للخادم قبل الرد، والثانية عطت إصلاحًا كاملًا وصحيحًا وجاهزًا للنشر لشيء قالب الـ VPS نفسه يتركه غير مهيأ افتراضيًا.
قاعدة المعرفة تصلح لتشغيل أول مشروع Laravel، لكن تغطيتها تضعف بسرعة بعد هالنقطة، واللي موجود فعلًا للإعدادات الأعمق، مثل scheduler، موجود في مقال كُتب لمنتج استضافة مختلف تمامًا.
لأي شيء أبعد من الأساسيات، Kodee هي الطريق الأوثق، وواصلت تثبت هذا لأنها كانت تشوف الشيء بنفسها قبل تجاوب بدل ما تفترضه.
استضافة Hostinger Laravel VPS
اكتشف كيف توفر استضافة Hostinger Laravel VPS بيئة مرنة لنشر تطبيقات Laravel مع موارد خادم مخصصة، وتحكم كامل، وأداء قابل للتوسع، وتكوينات قابلة للتخصيص لمشاريع الويب الحديثة.
نعم. الأساسيات هنا قوية. Laravel وCloudpanel يجيان مثبتين مسبقًا ويشتغلان، العتاد الأساسي طلع ممتاز في بنشماركات المعالج والذاكرة والقرص، وKodee قدّمت جوابين تقنيين دقيقين ومبنيين على حالة الخادم لما اختبرتها بشكل حقيقي. والنسخ الاحتياطية الأسبوعية تطابقت مع سجلات الحساب، بالضبط مثل ما هو معلن.
الزوايا الغير مثالية ضيقة لكنها مهمة قبل الشراء. ماسح البرمجيات الخبيثة المذكور كميزة رئيسية ما كان مفعّل افتراضيًا، وزر Manage App في بطاقة Laravel يوجّهك إلى Laravel Cloud، منتج مدفوع منفصل، بدل أي شيء يقدر يدير التطبيق، بدون أي تحذير توثيقي مسبق.
ولا واحدة من هذي صعبة الحل بعد ما تعرف إن Cloudpanel هو واجهة الإدارة الحقيقية، لكن ولا وحدة منها كان يفترض تحتاج تخمين من الأساس.
للمطور اللي يبي Laravel شغال بسرعة على بنية قوية، واللي مرتاح يقضي خمس دقايق يلقى Cloudpanel بدل الزر المضلل اللي جنبه، هذا توصية سهلة. أما إذا كنت تبي كل ميزة معلنة تكون شغالة لحظة إقلاع الخادم بدون أي تحقق إضافي، فخصص كم دقيقة زيادة للإعداد قبل لا تعتبره جاهزًا.
The section about renewal pricing is probably the most important takeaway. Introductory prices always look attractive, but it's the renewal cost that determines the real long-term value. I also found another review on Bestecision that breaks down the pricing, performance, and renewal considerations in detail.
نعم. يأتي Laravel و Cloudpanel مثبتين مسبقًا من لحظة تجهيز الـ VPS، وتؤدي الأجهزة الأساسية أداءً ممتازًا على مستوى المعالج والذاكرة والتخزين، كما أن مساعد Kodee AI من Hostinger يعطي إجابات دقيقة ومحددة على أسئلة إعداد Laravel الحقيقية. الملاحظة الوحيدة هي وجود فاحص برمجيات خبيثة يأتي معطّل افتراضيًا رغم أنه معلن عنه ضمن المميزات.
هل يجي Hostinger Laravel VPS جاهز ومثبت عليه Laravel؟
نعم. لارفيل متوفر كتطبيق تثبيت بنقرة واحدة أثناء إتمام طلب استضافة VPS، ويتم تثبيته تلقائيًا على أوبونتو إلى جانب Cloudpanel، لوحة التحكم المستخدمة لإدارة التطبيق، وقاعدة بياناته، وإعدادات الدومين الخاصة به بعد ذلك.
هل يوفّر Hostinger تجربة مجانية لاستضافة Laravel VPS؟
ما فيه تجربة مجانية مخصصة لخطط Laravel VPS. بدل كذا، Hostinger توفر لكل باقة VPS ضمان استرجاع فلوس لمدة 30 يوم، لكن طلب استرجاع ثاني لـ VPS خلال 180 يوم من الأول ما راح يتم الموافقة عليه.
أقدر أسترجع فلوسي على استضافة VPS من Hostinger؟
نعم، خلال 30 يوم من الشراء، بشرط إنك ما كنت قد طلبت استرداد لخطة VPS ثانية خلال آخر 180 يوم. الترقيات على خطة VPS حالية والمدفوعات اللي تتم بالعملة الرقمية مستثناة من الاسترداد بشكل كامل.
كيف أدير تطبيق Laravel الخاص بي على VPS من Hostinger؟
من خلال Cloudpanel، المتاح من زر Manage panel في بطاقة Cloudpanel داخل hPanel، أو مباشرةً عبر عنوان IP حق الـ VPS على المنفذ 8443. زر Manage App في بطاقة Laravel نفسها ما يدير التطبيق، هو يودّي إلى Laravel Cloud، وهي خدمة استضافة ثانية منفصلة وما لها علاقة بالـ VPS.
يقدم HostAdvice.com مراجعات وتقييمات احترافية بخدمات استضافة مواقع الانترنت مستقلة تماما عن أي جهة أو كيان آخر. تقييماتنا عادلة وأمينة وتطبق نفس معايير التقييم على كل المراجعات التي تتم.
يتم استلام تعويض نقدي من الشركات التي نقوم بتقييمها. تعويض الخدمات والمنتجات ليس له تأثير على توجه أو استنتاجات تقييماتنا. ولا تؤثر هذه التعويضات على ترتيبنا لشركات استضافة المواقع المحددة. تغطي هذه التعويضات تكاليف الإنفاق على المراجعين، شراء الحسابات، والاختبار.
