تبيع Hostginger خادم Laravel VPS الخاص بها كخادم مُثبّت مسبقًا ومدارًا بالذكاء الاصطناعي صُمم لإخراج مشروع Laravel إلى الإنترنت بسرعة. وقد تحقق معظم هذا الوعد خلال الاختبار الفعلي، مع معايير أداء قوية، ووكيل دعم ذكي كفء، ونسخ احتياطية مؤكَّد أنها تعمل وفق الجدول.

لكن زرًا واحدًا في لوحة التحكم قادني إلى مكان لم أكن أتوقع أن أصل إليه، ومن المهم أن تعرفه قبل أن تنقر عليه بنفسك. إليك التحليل الكامل.

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

قم بزيارة Hostinger

الإيجابيات والسلبيات

تفصيل التقييم

لتقييم استضافة Hostinger Laravel VPS، طبّقت منهجية التقييم الخاصة بـ HostAdvice، وهي المنهجية المعيارية نفسها المستخدمة في كل مراجعة على الموقع، بحيث تبقى الدرجات متسقة ومبنية على اختبار فعلي بدلًا من ادعاءات تسويقية. إليك كيف جاء الأداء عبر كل معيار.

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

قم بزيارة Hostinger

الخطط والأسعار

تبيع Hostinger استضافة Laravel كأحد أربعة مستويات VPS من KVM، من KVM 1 إلى KVM 8، وكل مستوى يرفع عدد أنوية المعالج، والذاكرة RAM، ومساحة NVMe، وعرض النطاق معًا كلما صعدت إلى مستوى أعلى.

Laravel نفسه ليس عملية شراء منفصلة، بل هو تطبيق بنقرة واحدة يُضاف إلى أي مستوى تختاره أثناء الدفع، مع Cloudpanel مضمّنًا بوصفه لوحة التحكم الفعلية لإدارة التثبيت بعد أن يصبح مباشرًا.

إليك بعض الأمور التي تستحق المعرفة قبل الطلب:

• شروط الفوترة: تُدفع الخطط مقدمًا عبر مدد 1 أو 12 أو 24 شهرًا، مع خصومات حقيقية على السعر الشهري في المدد الأطول. راجع أداة التسعير أدناه للاطلاع على التفصيل الكامل حسب المستوى والمدة.
• ضمان استرداد الأموال: تحمل خطط VPS ضمانًا لمدة 30 يومًا، لكن النص الصغير يضيف قيدًا حقيقيًا. يمكنك المطالبة باسترداد VPS مرة واحدة فقط كل 180 يومًا، لذا فإن مطالبة ثانية لاسترداد على شراء VPS آخر خلال تلك النافذة لن تمر. كما أن الترقيات إلى خطة 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 Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

قم بزيارة Hostinger

الأداء

تعيش تطبيقات Laravel أو تموت على الخادم الذي تحتها بقدر ما تعيش على الشيفرة نفسها. تعتمد أوقات تحميل الصفحات على سرعة المعالج لتنفيذ PHP، وتعتمد استعلامات قاعدة البيانات على إدخال/إخراج القرص، وتعتمد الجلسات والتخزين المؤقت على الذاكرة، وإذا كان التطبيق يشغّل مهامًا مجدولة أو يضم زوارًا فعليين، فإن معدل نقل الشبكة والقدرة على تحمّل الحمل المستمر مهمان أيضًا.

Laravel نفسه لا يغيّر أيًا من ذلك، فهو لا يزال PHP يعمل على Linux، لذا فإن الاختبار الحقيقي هنا هو الـ VPS.

أجريتُ حزمة كاملة من المعايير على الخادم، تغطي المعالج والذاكرة والقرص والشبكة واختبار ضغط مستمر، لمعرفة ما الذي تقدمه هذه الخطة فعليًا وما الذي يعنيه ذلك لتطبيق حقيقي.

كانت النسخة التي اختبرتها هي خطة KVM 2، وهي الخطة التي اخترتها أثناء الدفع:

• CPU: 2 vCPUs، مقتطعة من مضيف يعمل بمعالج AMD EPYC 9354P
• RAM: 7.8GB قابلة للاستخدام من أصل 8GB مخصصة، إضافة إلى 2GB من swap
• Disk: 96GB قابلة للاستخدام من أصل 100GB مخصّصة من NVMe
• OS: Ubuntu 24.04.4 LTS، kernel 6.8.0-137-generic

قبل الدخول في الأرقام، من الجيد معرفة أن تشكيلة Laravel VPS من Hostinger تعمل على المستويات الأربعة نفسها الخاصة ببقية نطاق VPS لديها، من KVM 1 إلى KVM 8، وKVM 2 يقع ثانيًا من الأسفل، أي درجة فوق الخيار الأرخص وبعيدًا جدًا عن مستويات KVM 4 وKVM 8 المصممة لأحمال العمل الأثقل ومتعددة التطبيقات.

ما يلي يعكس مشروع Laravel صغيرًا إلى متوسط الحجم، تطبيقًا واحدًا يخدم مقدارًا حقيقيًا ولكن متواضعًا من الحركة، وليس منصة كبيرة تشغّل عدة خدمات على صندوق واحد.

1. أداء المعالج

• أحادي الخيط: 1,624.55 حدثًا في الثانية، متوسط زمن استجابة 0.61ms، النسبة المئوية 95 عند 0.64ms

• متعدد الخيوط، خيطان: 2,864.02 حدثًا في الثانية، متوسط زمن استجابة 0.70ms، النسبة المئوية 95 عند 1.10ms

• الانحراف المعياري لعدالة الخيوط: 182.50 بمتوسط 14,321.5 حدثًا لكل خيط

إليك ما يعنيه هذا الرقم أحادي الخيط عمليًا. الطلب النموذجي في Laravel، مثل عرض قالب Blade، أو تشغيل عدد قليل من استعلامات Eloquent، أو التحقق من جلسة، يمضي معظم وقته على نواة معالج واحدة تنفذ عمل PHP بدلًا من التوزع على عدة أنوية دفعة واحدة.

عند 0.61ms كمتوسط زمن استجابة لكل حدث حسابي في هذا الاختبار، فالمعالج ليس الجزء من المنظومة الذي سيجعل الصفحة تبدو بطيئة.

والفجوة بين متوسط زمن الاستجابة والنسبة المئوية 95 صغيرة أيضًا، 0.61ms مقابل 0.64ms، ما يعني أن الأداء ظل متسقًا بدلًا من أن يستغرق الطلب أحيانًا وقتًا أطول بكثير من البقية، وهو نمط سيظهر لدى الزوار على شكل بطء عشوائي في تحميل الصفحات.

نتيجة الخيوط المتعددة هي الرقم الأكثر فائدة لفهم التزامن. الانتقال من خيط واحد إلى خيطين ضاعف الإنتاجية تقريبًا، بكفاءة توسّع تقارب 88 بالمئة، ما يعني أن هذا الـ VPS لا يفقد الكثير من القدرة بسبب الحمل الزائد أو بسبب تنافس مستأجرين آخرين على النوى الفيزيائية نفسها

عمليًا، يمكن لعمليات PHP-FPM التي تعمل بعمليتين عاملتين على هذه الخطة أن تتعامل مع حجم طلبات يقارب ضعف سيناريو الخيط الواحد قبل أن يصبح المعالج هو عنق الزجاجة، بدلًا من أقل من الضعف، وهو ما ستراه إذا كانت الـ vCPUs تتصارع فيما بينها على الدورات.

وتؤكد قيمة عدالة الخيوط، وهي نحو 1.3% من التباين بين الخيطين، أن كلا النواتين قامتا بحصة متقاربة من العمل بدلًا من أن تحمل إحداهما العبء بينما الأخرى خاملة. بالنسبة إلى موقع حقيقي، هذا يعني أن الطلبات توزَّع بالتساوي بين عمال PHP-FPM بدلًا من أن تتكدس خلف العامل المشغول.

2. سرعة الذاكرة

• الكتابة المتسلسلة: 5,865.22 MiB/sec

• القراءة المتسلسلة: 7,155.43 MiB/sec

سرعة الذاكرة مهمة بالنسبة إلى Laravel بطريقة يسهل إغفالها. فكل عملية بحث في OPcache، وكل قراءة جلسة، وكل مصفوفة أو Collection يبنيها تطبيقك أثناء معالجة طلب، تعيش في RAM، وإذا كانت طبقة تخزين مؤقت مثل Redis تعمل أيضًا على الصندوق نفسه، فهي تتنافس على نفس عرض النطاق للذاكرة.

عند نحو 5.9 GiB في الثانية للكتابة و7.2 GiB في الثانية للقراءة، يمكن لهذا الـ VPS نقل البيانات داخل الذاكرة وخارجها بسرعة كافية بحيث لا يُرجَّح أن تكون عمليات الذاكرة هي ما يبطئ الطلب، فالعنق في تطبيق Laravel نموذجي يكون عادةً القرص أو الشبكة قبل RAM.

أما حيث تهم الذاكرة بشكل مباشر أكثر فهو السعة لا السرعة. مع 7.8GB قابلة للاستخدام و2GB من swap خلفها، يمكن لهذه الخطة تشغيل PHP-FPM وMySQL أو PostgreSQL ونسخة صغيرة من Redis جنبًا إلى جنب لتطبيق واحد، لكنها لا تترك مجالًا كبيرًا إذا كنت تشغّل عدة مواقع على الـ VPS نفسه أو قاعدة بيانات ذات مجموعة عمل كبيرة.

الـ swap شبكة أمان لارتفاع مفاجئ في الذاكرة، وليست بديلًا عن RAM إذا كان التطبيق أصغر من اللازم فعليًا بالنسبة لهذه الخطة.

3. إدخال/إخراج القرص

• الكتابة المتسلسلة: 740 MiB/s (776 MB/s)، و740 IOPS

• القراءة المتسلسلة: 749 MiB/s (785 MB/s)، و748 IOPS

• قراءة/كتابة مختلطة عشوائية 4K: نحو 9,400 IOPS في كل اتجاه، وحوالي 36.7 MiB/s من النقل في كل اتجاه

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

عند نحو 740 إلى 750 MiB/s في كلا الاتجاهين، ومع تقارب القراءة والكتابة ضمن نسبة 2 بالمئة، لا يعاني هذا القرص من الضعف غير المتوازن في أحد الاتجاهين الذي يظهر أحيانًا في التخزين السحابي، حيث تكون القراءات سريعة لكن الكتابات أبطأ بكثير.

أما أداء 4K العشوائي فهو الرقم الذي يتنبأ فعليًا بكيفية شعور المستخدم مع تطبيق Laravel يوميًا، لأن قاعدة البيانات لا تقرأ وتكتب في كتل متسلسلة كبيرة، بل تقرأ وتكتب كتلًا صغيرة متناثرة عبر القرص أثناء البحث عن الصفوف وتحديث الفهارس والكتابة إلى سجل المعاملات.

أكثر بقليل من 9,000 IOPS في كل اتجاه يترجم إلى ما يقرب من 9,000 عملية قاعدة بيانات صغيرة في الثانية قبل أن يصبح إدخال/إخراج القرص هو العامل المحدد.

قد يؤدي تحميل صفحة Laravel نموذجية إلى عدد من الاستعلامات يتراوح بين بضعة وعشرات قليلة بحسب كيفية بناء التطبيق، ما يعني أن هذا القرص لديه مساحة لعدد معتبر من المستخدمين المتزامنين الذين يضربون قاعدة البيانات في الوقت نفسه قبل أن تبدأ الاستعلامات بالاصطفاف انتظارًا للوصول إلى القرص.

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

4. سرعة الشبكة

• الجولة 1: تنزيل 990.06 Mbps، ورفع 910.87 Mbps، وزمن خمول 0.31ms، و0% فقدان للحزم

• الجولة 2: تنزيل 985.24 Mbps، ورفع 947.82 Mbps، وزمن خمول 0.27ms، و0% فقدان للحزم

سجلت كلتا الجولتين على خادم في Phoenix، Arizona، مطابقًا لموقع United States الذي اخترته أثناء الدفع، مقتربًا من غيغابت كامل في كلا الاتجاهين مع صفر فقدان للحزم في كل محاولة.

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

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

كما أن النتائج المتطابقة تقريبًا عبر جولتين منفصلتين، بفاصل دقائق، تستبعد كونها نتيجة محظوظة عابرة، فهذا ما يفعله الاتصال باستمرار بدلًا من رقم صعد مرة واحدة فقط.

5. اختبار الضغط

شغّلت ضاغطات للمعالج والذاكرة والقرص لمدة 180 ثانية لكل منها لأرى كيف يصمد الخادم تحت حمل مستمر بدلًا من دفعة قصيرة:

• ضغط المعالج، عاملان: 540,042 bogo ops، و0 حالات فشل

• ضغط الذاكرة، عاملان: 24,335,966 bogo ops، و0 حالات فشل

• ضغط القرص، عاملان: 2,655,058 bogo ops، و0 حالات فشل

أرقام bogo ops الفردية أقل أهمية هنا من ما لم يحدث.

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

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

الحكم العام على الأداء

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

قم بزيارة Hostinger

سهولة الاستخدام

اختبرتُ Hostinger Laravel VPS من الدفع حتى فتح أدوات الإدارة الفعلية التي تأتي معه.

شمل ذلك اختيار خطة وموقع الخادم، وإنشاء حساب، والدفع، ثم محاولة فهم كيفية إدارة نشر Laravel فعليًا بعد أن يصبح الخادم مباشرًا. ما يلي هو كيف كانت تلك العملية فعليًا، بما في ذلك لحظة أوصلتني فيها الواجهة إلى مكان لم أكن أتوقعه.

1. التسجيل

بدأت من صفحة Laravel VPS المقصودة، التي تبرز ثلاث ادعاءات تستحق التذكّر منذ البداية:

• نسخ احتياطية أسبوعية تلقائية مجانية
• VPS مُدار بالذكاء الاصطناعي
• ماسح برمجيات خبيثة تلقائي

اخترت خطة KVM 2، وهي نقطة وسط معقولة لتطبيق Laravel واحد بدلًا من بناء يستهلك موارد كثيرة، ثم انتقلت إلى سلة الشراء.

من هناك، عرضت صفحة السلة كل شيء في شاشة واحدة:

• فترة الفوترة: 1 أو 12 أو 24 شهرًا، مع إظهار التوفير لكل خيار
• موقع الخادم: مناطق مجمعة حسب القارة، مع تقدير زمن الوصول بجانب كل واحدة
• سوق التطبيقات: أكثر من ألف خيار بنقرة واحدة لأنظمة التشغيل واللوحات والتطبيقات

اخترت 24 شهرًا للحصول على سعر أقل، ثم قضيت وقتًا أكثر من المعتاد في موقع الخادم.

أعطت United Kingdom أفضل زمن وصول في القائمة، لكنني مررت على بقية المناطق للمقارنة على أي حال. أظهر North America نتيجة جيدة لـ United States، بينما جاءت أسرع نقطة في Asia، وهي Malaysia، متأخرة بشكل واضح عن الاثنين.

وبما أن الموقع الذي كنت أفكر فيه سيجذب جمهورًا أميركيًا في الغالب، اخترت United States بدلًا من خيار United Kingdom الأسرع تقنيًا.

وهذا يستحق الإشارة لأي قارئ يقارن المناطق في هذه الصفحة. أفضل زمن وصول بالنسبة لك وأنت جالس أمام حاسوبك ليس الرقم المهم، بل زمن الوصول إلى الأشخاص الذين سيزورون الموقع فعلًا، لذا اختر بناءً على جمهورك، لا بناءً على نتائج الاختبار الخاصة بك.

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

كنت مسجّلًا بالفعل في حساب Hostinger موجود، لذا استغرق التسجيل نفسه نقرة واحدة.

بعد ذلك، قدّمت صفحة عنوان الفوترة والدفع:

• البطاقة، وتشمل Visa وMastercard وAmex وDiscover
• PayPal
• Google Pay
• AliPay، بنسختي الصين وهونغ كونغ
• Coingate، للدفع بالعملات الرقمية

كل ذلك في صفحة واحدة، دون تحويل منفصل. أرسلت الدفع، ووصلني بريد تأكيد فورًا، وعُدت إلى hPanel حيث ظهر الخادم الجديد بالفعل على أنه يعمل.

ما يبرز هنا هو مقدار الخيارات الذي تمنحه Hostinger عند الدفع من دون أن تجعل أيًا منها إلزاميًا.

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

2. لوحة التحكم/منطقة العميل

بعد إتمام الدفع، فتح hPanel على الشاشة الرئيسية، وهي لوحة الحساب المركزية نفسها التي تدير النطاقات والبريد الإلكتروني ومنشئ المواقع وVPS من مكان واحد.

رحّب بي بالاسم مع شريط مطالبة بالذكاء الاصطناعي، وصف من أزرار الاختصار، وقائمة مهام، وقائمة متواصلة بكل المواقع والخوادم على الحساب في الأسفل.

بعد ذلك، مررت إلى جدول 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، وكل منها معنونة 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 على قائمة Sites، مع اسم مضيف الـ VPS مهيأ بالفعل كموقع مباشر، وPHP مضبوطًا كنوع التطبيق، ورابط Manage بجانبه.

وعند فتح إعدادات هذا الموقع ظهر صف كامل من التبويبات، Settings، وVhost، وDatabases، وVarnish Cache، وSSL/TLS، وSecurity، وSSH/FTP، وFile Manager، وCron Jobs، وLogs.

هذه لوحة تحكم حقيقية وشاملة، ومن المهم الإشارة إلى أن تبويب Cron Jobs موجود هناك مباشرة ضمن نفس الواجهة. لقد أرشدني Kodee إلى إضافة إدخال cron الخاص بالـ scheduler يدويًا عبر SSH، وهذا يعمل جيدًا، لكن Cloudpanel لديه طريقة بنقرة وبدون لمس الطرفية للقيام بالأمر نفسه، ولا Kodee ولا مقال قاعدة المعرفة ذكرا ذلك كخيار.

ومع إنهاء هذه الجهة، فإن القائمة الجانبية على صفحة إدارة الخادم هي المكان الذي توجد فيه الضوابط الحقيقية.

إليك ما توفره:

• Overview: صفحة الملخص نفسها، مع بطاقات تطبيق Laravel وCloudpanel، واستخدام الموارد، وروابط سريعة إلى كل ما هو أدناه
• Settings: إعدادات على مستوى الخادم، تغطي أشياء مثل إعادة تعيين كلمة مرور root وتغيير اسم المضيف
• OS & Panel: التحكم في نظام التشغيل وأي لوحة تحكم مثبتة على الخادم
• Backups & Monitoring: تتوسع إلى Snapshots & Backups وServer Usage وLatest Actions، وهو المكان الذي وجدت فيه سجل النسخ الاحتياطي الأسبوعي الذي أكد أن هذا الادعاء صحيح
• Security: يغطي ماسح البرمجيات الخبيثة وإعدادات جدار الحماية، وهو القسم الذي وجدت فيه الماسح متوقفًا
• API: يفتح توثيق Hostinger لـ API في تبويب جديد، لأي شخص يضبط إدارة الخادم آليًا خارج اللوحة
• DNS Manager: إدارة النطاق وDNS المرتبطين بالخادم
• Tutorials: رابط خارجي إلى محتوى المساعدة في Hostinger

ذلك انتشار واسع بما يكفي لوصفه بأنه تغطية كاملة لإدارة VPS. إعدادات الخادم، والتحكم في نظام التشغيل، والأمان، والنسخ الاحتياطية، وDNS، والوصول إلى API كلها ممثلة كفئات منفصلة بدلًا من أن تكون مدفونة داخل قائمة إعدادات شاملة، ولم أصطدم بأي شيء كنت أحتاجه ولم أجده في هذه القائمة.

ما لا يفعله هو دمج أي أدوات خاصة بـ Laravel، فالنشر، وإدارة ملفات البيئة، وتشغيل أوامر Artisan، كل ذلك يتم إما عبر Cloudpanel أو الطرفية، وليس عبر هذا الشريط الجانبي.

وهذا يقودني إلى زر terminal الموجود على بطاقة Ubuntu. الغرض منه هو الوصول المباشر إلى سطر الأوامر على الخادم، وفتح جلسة SSH حية داخل المتصفح دون الحاجة إلى عميل SSH منفصل أو نسخ مفتاح خاص إلى جهازك.

عند النقر عليه، انتقلت مباشرة إلى shell بصلاحيات root، ومصادَق عليه مسبقًا، مع ظهور رسالة الترحيب من Cloudpanel على الشاشة، تتضمن عنوانه الشبكي الخاص وأداة CLI تسمى clpctl لإدارة اللوحة من سطر الأوامر.

بالنسبة إلى أي شخص مرتاح للعمل من الطرفية، فهذا أسرع طريق للبدء فعليًا في تهيئة تثبيت Laravel ونشر الشيفرة وتعديل متغيرات البيئة وتشغيل migrations، لأن أيًا من ذلك لا يملك زرًا مخصصًا في hPanel نفسه.

الحكم العام على سهولة الاستخدام

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

قم بزيارة Hostinger

مستوى الدعم

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 لإبقاء عمال الطوابير يعملون، وأردت أن أعرف هل يضبط قالب الـ VPS أيًا منهما تلقائيًا، وهل سيبقى Supervisor بعد إعادة التشغيل إذا ضبطته بنفسي.

قال Kodee إنه سيتحقق من الخادم مباشرة قبل الإجابة، وبالفعل فعل:

• أبلغ بعدم وجود إدخال cron من نوع schedule:run
• أبلغ بعدم تكوين خدمة Supervisor
• أبلغ بعدم وجود عامل طابور مُعد
• قدّم سطر cron الدقيق اللازم للمجدول
• قدّم كتلة إعداد Supervisor كاملة لعامل طابور، مع الأعلام الصحيحة
• أكد أن Supervisor يستمر عبر إعادة التشغيل بعد تفعيله باستخدام systemctl enable –now supervisor
• وأضاف تذكيرًا بتشغيل php artisan queue:restart بعد نشر شيفرة جديدة، وهي تفصيلة يسهل تفويتها وتسبب أخطاء إنتاجية حقيقية عند إغفالها

ما فكرتُ به حول دعم الذكاء الاصطناعي: استحق Kodee إجاباته هنا بدلًا من التخمين. التأكد من عدم وجود cron للمجدول ولا عملية Supervisor قبل التوصية بأي شيء هو الفرق بين ردٍّ قائم على قائمة تحقق وردٍّ مبني على ما كان هذا الخادم المحدد يفعله فعلًا، والتذكير بإعادة تشغيل عامل الطابور بعد النشر هو من تلك التفاصيل التي لا تظهر إلا عندما يفهم أحدهم، أو شيء ما، كيف تعمل طوابير Laravel في الإنتاج.

سؤالان، وإجابتان صحيحتان وكاملتان، وكلاهما وصل خلال بضع دقائق.

2. قاعدة المعرفة

تنظم قاعدة معرفة Hostinger بالطريقة نفسها عبر كل المنتجات، مربعات فئات كبيرة مع عدد المقالات، وشريط بحث، ومرشح للفئات في الأعلى.

بدلًا من التصفح، ذهبت مباشرة إلى البحث وكتبت “laravel”، فظهرت 15 نتيجة عبر صفحتين، وهو عدد أكثر من الواضح لتطبيق بنقرة واحدة أضيق نطاقًا.

لكن ذلك يستحق تحفظًا. فالمزيد من النتائج لا يعني نتائج أكثر صلة، إذ إن عدة نتائج كانت ذات صلة هامشية فقط، فمقال عن قيود بريد PHP وآخر عن مشكلات ترحيل المواقع ظهرا فقط لأنهما يذكران Laravel عرضًا.

أكثر النتائج صلة، “How to use the Laravel VPS template at Hostinger,” يشرح الوصول إلى Cloudpanel، وفهم بنية مجلدات Laravel، وتعديل ملف .env، وتشغيل Composer، وإجراء الترحيلات.

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

وبالاستمرار في استكشاف نتائج البحث، ظهر أمر يستحق التنبيه. مقال أقدم بعنوان “How to deploy Laravel 8 at Hostinger” يتضمن بالفعل مثال cron يعمل للمجدول، لكنه مكتوب لإعداد أقدم ومختلف تمامًا، ينشر Laravel يدويًا على استضافة مشتركة أو سحابية بدلًا من قالب VPS الحالي، مع بنية ملفات public_html لا علاقة لها بكيفية تنظيم Cloudpanel للـ VPS.

أي شخص على قالب VPS هذا يبحث في قاعدة المعرفة عن إرشادات المجدول سيصادف مقالًا يصف منتجًا مختلفًا قبل أن يجد أي شيء ينطبق فعلًا على خادمه.

ما فكرتُ به حول قاعدة المعرفة: يبدو عدد المقالات قويًا على الورق، 15 نتيجة لعبارة بحث واحدة، لكن الحجم الخام يخفي مدى تشتت المحتوى المفيد فعليًا. مقال قالب VPS الأساسي مكتوب جيدًا ويقود إلى تشغيل المشروع الأول، لكنه يتوقف بالضبط عند النقطة التي يصبح فيها النشر الإنتاجي جديًا، والمعلومة الوحيدة التي تغطي المجدول موجودة في مقال مخصص لإعداد استضافة أقدم وغير ذي صلة.

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

الحكم العام على الدعم

Hostinger Laravel VPS Hosting

Discover how Hostinger Laravel VPS Hosting provides a flexible environment for deploying Laravel applications with dedicated server resources, full control, scalable performance, and customizable configurations for modern web projects.

قم بزيارة Hostinger

هل نوصي باستضافة Hostinger Laravel؟

نعم. الأساسيات هنا قوية. يصل Laravel وCloudpanel مثبتين مسبقًا ويعملان، والأجهزة الأساسية تسجل أداءً جيدًا عبر المعالج والذاكرة والقرص، وقدم Kodee إجابتين تقنيتين صحيحتين ومطلعَتين على حالة الخادم عندما اختبرتهما اختبارًا حقيقيًا. كما تطابقت النسخ الاحتياطية الأسبوعية مع سجلات الحساب نفسها، تمامًا كما أُعلن عنها.

العيوب بسيطة لكنها تستحق المعرفة قبل الشراء. أداة فحص البرمجيات الخبيثة المذكورة كميزة رئيسية لم تكن مفعلة افتراضيًا، وزر Manage App على بطاقة Laravel يوجّهك نحو Laravel Cloud، وهو منتج مدفوع منفصل، بدلًا من أي شيء يشبه إدارة التطبيق، من دون أي تحذير في أي توثيق مسبقًا.

لا يصعب تجاوز أي منهما بمجرد أن تعرف أن Cloudpanel هو سطح الإدارة الحقيقي، لكن لا ينبغي أن يتطلب أي منهما التخمين أيضًا.

بالنسبة لمطور يريد تشغيل Laravel بسرعة على بنية قوية، ويشعر بالراحة في قضاء خمس دقائق للعثور على Cloudpanel بدلًا من الزر غير المسمى بشكل صحيح بجانبه، فهذا ترشيح سهل. أما لمن يريد تشغيل كل ميزة معلنة بمجرد إقلاع الخادم دون الحاجة إلى أي تحقق إضافي، فاحسب بضع دقائق إضافية للإعداد قبل أن تعتبره مكتملًا.

Hostinger

5.0

2,471 user reviews

US$ 1,59 /mo

السعر المبدأي

قم بزيارة Hostinger

Rating based on expert review

• سهولة الاستخدام
  4.9
• الدعم الفني
  4.9
• المميزات
  4.8
• الموثوقية
  4.7
• الأسعار
  4.5