بنى Hostinger Web Apps Hosting حول وعد بسيط: ادفع كودك من GitHub أو ملف ZIP أو وكيل البرمجة بالذكاء الاصطناعي، واحصل على تطبيق حيّ وجاهز للإنتاج يعمل في حوالي دقيقة واحدة، من دون خادم تديره بنفسك. أردت أن أعرف كم من هذا الكلام يصمد فعلاً عندما تكون أنت من ينقر على زر النشر، فإليك ما وجدته.

Deploy Web Apps Faster with Hostinger

Deploy modern web apps on Hostinger with automated builds, managed infrastructure, global CDN, SSL, security tools, and a 30-day money-back guarantee.

قم بزيارة Hostinger

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

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

لتقييم Hostinger’s Web Apps Hosting، طبّقت منهجية التقييم الخاصة بـ HostAdvice rating methodology، وهي المنهجية القياسية نفسها المستخدمة عبر جميع المراجعات على الموقع، بحيث تبقى الدرجات مبنية على اختبار حقيقي لا على لغة تسويقية. فيما يلي كيف حصل على التقييم عبر كل معيار.

Host Your Web Apps Without the DevOps Hassle

Deploy modern web applications on fully managed hosting with automated deployments, managed SSL, global CDN, and built-in security.

قم بزيارة Hostinger

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

يبيع Hostinger Web Apps Hosting على شكل فئتين، Business وCloud Startup، وكلتاهما مصممتان خصيصًا لنشر تطبيقات Node.js وتطبيقات JavaScript الحديثة بدلًا من إنشاء مواقع تقليدية.

Cloud Startup، وهي الفئة التي اختبرتها، تضاعف حد التطبيقات وعدد أنوية CPU مقارنةً بـ Business، وكلتا الخُطتين تتضمنان نطاقًا مجانيًا، وبريدًا إلكترونيًا تجاريًا مجانيًا، وSSL مُدارًا للسنة الأولى مباشرةً ضمن عملية الدفع.

بعض الأمور التي يجب معرفتها قبل الطلب:

• ضمان استرداد الأموال: يقع Web Apps Hosting تحت شروط الاسترداد القياسية لدى Hostinger، وهي نافذة واضحة مدتها 30 يومًا من تاريخ الشراء. وهذا أبسط بكثير مما ينطبق على خطط VPS لدى Hostinger، التي تتضمن فترة تهدئة إضافية مدتها 180 يومًا بين طلبات الاسترداد. لا تنطبق هنا أي فترة تهدئة من هذا النوع.
• تجربة مجانية: لم أجد تجربة مجانية مخصصة. لذلك تُعدّ ضمانة استرداد الأموال لمدة 30 يومًا نافذة التقييم الخاصة بك.
• طرق الدفع: أظهر الدفع البطاقة كطريقة افتراضية، مع ظهور شعارات Visa وMastercard وAmex وDiscover، إضافةً إلى خيار إضافة طريقة دفع أخرى أثناء الدفع.
• ما يتضمنه العرض: يشمل السعر نطاقًا مجانيًا لمدة سنة، وصناديق بريد مجانية لمدة سنة، وSSL مُدارًا من دون تكلفة إضافية فوق سعر الخطة، لذا فإن السعر الظاهر قريب جدًا من الكلفة الحقيقية لإطلاق نشر يعمل ومؤمَّن بالكامل.
• الترقية الإضافية الوحيدة: يظهر Hostinger Reach، وهو إضافة للتسويق عبر البريد الإلكتروني، في السلة داخل مربع مميز مستقل بسعر شهري منفصل. يسهل تجاهله، ولا يكون مدمجًا أو محددًا مسبقًا افتراضيًا.

إذا ألغيت خطة Web Apps Hosting خلال 30 يومًا، تؤكد سياسة استرداد Hostinger أنها تقع ضمن الشروط القياسية بدلًا من قائمة الاستثناءات، لذا يفترض أن يضمن الإلغاء البسيط خلال تلك الفترة استردادًا من دون الشروط الإضافية المرافقة لعمليات شراء VPS أو النطاقات.

الميزات

• التعرّف التلقائي على الإطار البرمجي وإصدار Node
• أدوات إنشاء قاعدة بيانات Managed MySQL
• CDN عالمي مفعّل افتراضيًا
• يتضمن WAF وحماية من DDoS
• نسخ احتياطية يومية وعند الطلب
• فحص للبرمجيات الخبيثة وفحص للثغرات
• تكامل مع GitHub مع النشر التلقائي
• نطاق مجاني، وبريد إلكتروني، وSSL
• وصول SSH للمستخدمين المتقدمين

From Code to Live App with Hostinger

Connect your GitHub repository or upload your project and get it online with managed infrastructure, automatic deployments, and daily backups.

قم بزيارة Hostinger

الأداء

نظرًا لأن Web Apps Hosting مُدار بالكامل، فلن تحصل أبدًا على وصول shell إلى خادم، لذلك لا توجد CPU أو RAM أو مساحة قرص يمكن قياسها مباشرةً بالطريقة التي تفعلها في مراجعة VPS.

ما يمكنك قياسه هو مدى سرعة تحميل التطبيق المنشور واستجابته، من مواقع حقيقية حول العالم. وقد اختبرت ذلك من أربع زوايا مختلفة: GTmetrix من قارتين، وفحص اتساق عالمي يضم أكثر من 50 نقطة، وأداة السرعة المدمجة لدى Hostinger لكل من سطح المكتب والهاتف المحمول.

التطبيق قيد الاختبار هو نشر Next.js الذي تمت تغطيته في قسم سهولة الاستخدام أدناه، والموجود على ivory-llama-856835.hostingersite.com، ويعمل على خطة Cloud Startup (4 CPU cores, 4096 MB RAM, 100 GB NVMe storage)، مع CDN مفعّل افتراضيًا.

1. GTmetrix، تم اختباره من قارتين

أجريت اختبار GTmetrix مرتين من أجزاء مختلفة من العالم لأرى ما إذا كانت النتيجة متسقة أو أنها تبدو جيدة فقط من زاوية واحدة محظوظة.

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

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

بمجرد أن يكون CDN مفعّلًا، كما كان هنا افتراضيًا، فإن الزائر لا يصل بالضرورة إلى الخادم الأصلي مباشرةً.

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

2. الاتساق العالمي (Check-Host)

أجريت فحص HTTP على الرابط الحي من كل نقطة فحص يوفّرها Check-Host، وهي 54 موقعًا عبر ست قارات. الصورة الكاملة:

أعادت كل عملية فحص ناجحة 200 OK نظيفة، بلا أخطاء، ولا إخفاقات جزئية، ولا عمليات إعادة توجيه غير متوقعة.

أظهرت أزمنة الاستجابة قصة واضحة عن كيفية عمل التخزين المؤقت عبر CDN في المسافات الواقعية:

أعادت نقاط الفحص الأوروبية باستمرار أسرع الأوقات، وكان بعضها أقل من 50 مللي ثانية، بينما أعادت نقاط الفحص الأبعد ماديًا عن أي عقدة edge node، مثل Tokyo وSingapore وHo Chi Minh City، ردود 200 صحيحة أيضًا، لكنها أبطأ، في نطاق 0.3 إلى 0.8 ثانية.

هذا هو الشكل المتوقع لنشر يعتمد على CDN: سريع قرب الحواف، ويظل وظيفيًا بالكامل حتى عندما يبتعد عنها.

أما مهلات الاتصال الأربع، في Kazakhstan وRomania ونقطتان من نقاط روسيا الأربع، فلا أعتبرها مشكلة في بنية Hostinger التحتية.

فقد نجحت نقاط أخرى في البلدان نفسها (عاد Saint Petersburg نظيفًا عند 0.063s بينما انتهت مهلة نقطتين في Moscow)، ما يشير إلى ترشيح شبكي إقليمي من جهة نقطة الفحص نفسها بدلًا من وجود خلل في التطبيق المنشور.

3. أداة السرعة الخاصة بـ Hostinger، سطح المكتب والهاتف المحمول

يشغّل Hostinger اختباره الخاص Page Speed داخل لوحة التطبيق، لذلك قارنت أرقامه بنتائج GTmetrix المستقلة بدلًا من أخذ أي منهما بالقيمة الظاهرية وحدها.

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

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

هناك عدم اتساق واحد في الأداة نفسها. فعلى الرغم من أن الدرجة 100 كاملة على الجهازين، فإن لوحة Diagnostics أسفلها ما تزال تضع بعض البنود بدرجة 0 حرفيًا، network dependency tree، document request latency، وavoiding multiple redirects، إلى جانب بندين بدرجة 50، unused JavaScript وlegacy JavaScript.

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

وبشكل منفصل، فإن “الروابط المفيدة” التي يعرضها Hostinger بجانب هذه التشخيصات مكتوبة كلها لووردبريس، “Speed up WordPress in 9 easy steps”، “How to optimize images for your WordPress site”، رغم أن هذا تطبيق Node.js ولا علاقة لووردبريس به إطلاقًا في أي جزء من البنية. وهذا بقايا من قالب تشخيص مشترك، لا محتوى صُمم لهذا المنتج.

الخلاصة العامة حول الأداء

Managed Web App Hosting by Hostinger

Focus on building your app while Hostinger takes care of deployment, infrastructure, security, SSL, backups, and global delivery.

قم بزيارة Hostinger

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

اختبرت Web Apps Hosting لدى Hostinger من صفحة الهبوط وحتى الدفع، ثم من حساب جديد تمامًا إلى نشر Node.js حيّ يعمل بالكامل.

شمل ذلك اختيار خطة، والدفع، واختيار طريقة البناء، وربط GitHub، ومشاهدة اكتمال البناء في الوقت الحقيقي. وإليك كيف كانت تلك العملية فعليًا.

1. التسجيل

بدأت من صفحة الهبوط الخاصة بـ Web Apps Hosting، والتي تتصدرها دعوة واحدة لاتخاذ إجراء: Start deploying.

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

كانت الخُطتان جنبًا إلى جنب:

اخترت Cloud Startup بسبب مضاعفة حد التطبيقات والسعة المتاحة من CPU مقارنةً بالفئة الأساسية. وهناك عدم اتساق صغير يجب التنبيه إليه هنا: صفحة الأسعار تسميها “Cloud Startup”، لكن عندما تصل إلى السلة تُعرض الخطة نفسها باسم “Startup plan”. ليس هذا مشكلة وظيفية، بل مجرد اختلاف في التسمية بين شاشتين في مسار الدفع نفسه.

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

تجاوزتها بالنقر على Continue من دون أي عرقلة.

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

بعد ذلك، تضيف عنوان الفوترة، وتختار وسيلة الدفع، البطاقة أو PayPal أو إحدى الخيارات الأخرى، ثم ترسل الطلب. وصلتني رسالة تأكيد الشراء خلال لحظات من النقر على Submit payment، ثم هبطت مباشرة في hPanel حيث تم توفير الخطة بالفعل.

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

2. لوحة التحكم

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

الصفحة التي تصل إليها أولًا هي Home، وهي مبنية حول شريط إدخال للذكاء الاصطناعي في الأعلى: “Hi, [your name]! How can I help you today?” مع حقل نص أسفله وستة أزرار اختصار: Get domain وCreate website وGet email وMigrate site وGet VPS وTry email marketing.

إذا مررت لأسفل ستجد:

• مربعات ترويج للميزات خاصة بـ AI Builder وأداة المتجر الإلكتروني، مع ادعاءات بالحصول على بريد إلكتروني تجاري مجاني، وAI agents، وتطبيق أتمتة، والحصول على نطاق مجاني
• قائمة مهام تدفعك نحو خطوات الإعداد، وإنهاء إعداد Reach، والحصول على بريدك الإلكتروني المجاني، والحصول على نطاقك المجاني
• Your business، وهي قائمة تشغيل لكل موقع وتطبيق ونسخة VPS مرتبطة بحسابك، ولكل منها زر Manage site خاص بها
• VPS، وهو جدول منفصل في الأسفل يسرد أي مثيلات VPS بحسب عنوان IP والحالة وتاريخ الانتهاء

هناك أيضًا لوحة Agent ثابتة في الزاوية العلوية اليمنى من كل صفحة في hPanel، وليس فقط في Home. إنها نفس مساعد Kodee المستخدم للدعم، لكن تم وضعه هنا كأداة إجراءات عامة مع مطالبات جاهزة مثل “Deploy my Node.js app” أو “Harden VPS updates” يمكنك تشغيلها من دون كتابة سؤال كامل بنفسك.

Home مفيد فعلًا بمجرد أن يصبح التطبيق موجودًا لديك بالفعل، فكل ما في Your business ينقلك مباشرةً إليه. لكنه ليس المكان الذي تذهب إليه لإنشاء Web App جديد أو للوصول إلى زر Setup. من أجل ذلك، تحتاج إلى مسار مختلف عبر الشريط الجانبي كله:

1. انقر Websites في الشريط الجانبي الأيسر
2. تتوسع قائمة فرعية تحته: WordPress وAI Builder وWeb Apps وPHP/HTML وMigrations
3. انقر Web Apps

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

هنا تحصل كل خطة تملكها على بطاقة خاصة بها. في حسابي، كان ذلك يعني ثلاث بطاقات مصطفّة عموديًا:

كانت بطاقة Business تتضمن أيضًا بالفعل تطبيقًا حيًا مدرجًا أسفلها من اختبار سابق، orange-walrus-700988.hostingersite.com، مع زري Tools وDashboard الخاصين به.

هذه ملاحظة مفيدة بحد ذاتها. فعندما يوجد Web App بالفعل، تضيف بطاقته سطرًا كهذا يعرض الموقع الحي مباشرةً، وهذا بالضبط ما ستبدو عليه بطاقة Cloud Startup الخاصة بك بمجرد إنهاء الإعداد.

وبما أن Cloud Startup كانت الخطة التي اشتريتها للتو ولم أقم بإعدادها بعد، فقد عرضت بطاقتها زر Setup فقط. هذا هو الزر الذي يبدأ فعليًا معالج إنشاء Web App، ولا يظهر إلا هنا، تحت Websites → Web Apps، وليس من شاشة Home التي تصل إليها افتراضيًا.

ما رأيته: hPanel واضح بمجرد أن تجد الشاشة الصحيحة، لكن Web Apps Hosting لا يملك بابًا أماميًا واضحًا. الوصول إلى Home يمنحك شريط أوامر واختصارات، لا مسارًا مباشرًا لإنشاء تطبيق، ويجب أن تعرف أن عليك النقر على Websites ثم Web Apps قبل أن يظهر زر Setup أصلًا. هذه بضع نقرات إضافية لمنتج يُسوَّق على أنه “يصبح حيًا خلال دقيقة”. لكن بمجرد وصولك إلى هناك، تكون بطاقات الخطط نظيفة وصريحة بشأن الحالة، والخطة التي لديها تطبيق يعمل بالفعل تعرضه مباشرةً على البطاقة.

3. نشر التطبيق

فتح النقر على Setup في بطاقة الخطة مسارًا تمهيديًا قصيرًا: Where would you like to start? مع ثلاثة خيارات، Create a new site أو Migrate an existing site أو I hired someone to build my site. اخترت Create a new site.

قاد ذلك إلى How do you want to build your website?، مقسمة إلى خيارين للمبتدئين في الأعلى، Hostinger AI Builder وWordPress + AI، وخيارين تحت عنوان منفصل “for advanced users” في الأسفل: Node.js web app وPHP/HTML website. اختيار Node.js web app هو ما يضعك فعليًا على منتج Web Apps Hosting نفسه.

هذه ملاحظة بنيوية حقيقية لأي شخص يقارن المنتجات: Web Apps Hosting لا يملك مسار تسجيل مخصصًا له.

إنه مجرد فرع واحد داخل نفس معالج إنشاء الموقع المستخدم لـ AI Builder وWordPress.

نقرت على الدائرة بجانب Node.js web app، ثم نقرت على Next.

ومن هناك:

• شاشة النطاق: اخترت Use temporary domain بدلًا من ربط نطاق حقيقي، لأن هذا كان نشرًا تجريبيًا.

• شاشة موقع الخادم: حدد Hostinger مسبقًا France، وهي المنطقة الأقرب إلى بلد الفوترة الخاص بي، وأظهرها عند 167ms من زمن الاستجابة. وعند التمرير إلى خيار United States ظهر 364ms، أي أكثر من الضعف.

اخترت United States, Massachusetts على أي حال، وهذه هي الدرسة نفسها التي تعلّمك إياها شاشة اختيار الموقع في كل منتجات Hostinger: اختر بناءً على مكان وجود زوارك الفعليين، لا بناءً على الرقم الأقل في القائمة.

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

• شاشة طريقة النشر: خياران رئيسيان، Import Git repository (موسوم بأنه Recommended) أو Upload your files، إضافةً إلى تنبيه أسفل ذلك للنشر مباشرةً من Claude Code أو Cursor أو VS Code عبر Hostinger Connector. اخترت Import Git repository ونقرت على Connect with GitHub.

فتح ذلك نافذة تسجيل دخول حقيقية إلى GitHub إذا لم تكن مسجلًا الدخول بالفعل، ثم شاشة أذونات بعنوان Install & Authorize Hostinger، تطلب منك الاختيار بين:

• التثبيت على all repositories التي تملكها، بما في ذلك المستقبلية منها، مع وصول للقراءة فقط إلى المستودعات العامة
• أو التثبيت على only select repositories تختارها واحدًا واحدًا، مع عرض الأذونات الدقيقة التي تُمنح: وصول للقراءة إلى actions وmetadata وrepository hooks، ووصول للقراءة والكتابة إلى administration وcode وpull requests. بمجرد النقر على Install & Authorize، يعيد GitHub توجيهك تلقائيًا إلى hPanel.

تصل إلى Select Git repository to import، وهي قائمة قابلة للتمرير تضم كل مستودع مرتبط بحساب GitHub الخاص بك، ولكل منها زر Deploy بجانبه. عثرت على المستودع التجريبي الذي دفعته مسبقًا، hostadvice-webapps-test، ونقرت على Deploy بجانبه.

من لحظة النقر على ذلك الزر، استغرق الأمر قرابة 30 ثانية من دون مؤشر تقدم على الشاشة قبل أن تُحمَّل الصفحة التالية، وهو وقت كافٍ لتتساءل إن كانت النقرة قد سُجلت أصلًا.

الصفحة التي تُحمَّل أخيرًا تحمل عنوان Review build settings، وتخبرك بدقة أين سيعيش تطبيقك قبل أن تلتزم بأي شيء: “Deploys to ivory-llama-856835.hostingersite.com.” وتحت ذلك، ومن دون أن تلمس أي حقل، كانت قد تعرّفت تلقائيًا بالفعل على:

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

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

مراقبة البناء

تتحول الشاشة إلى عرض Deploying… مع شريط تقدم معنَّون، “Deployment from GitHub”، يتقدم بمراحل فعلية، شاهدته يتحرك إلى 28% ثم 51% في طريقه إلى الاكتمال. أسفل شريط التقدم توجد لوحة قابلة للطي بعنوان Build logs، وعند توسيعها تظهر مخرجات طرفية حية كما تحدث، لا مؤشرًا وهميًا:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

اكتمل النشر

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

من هذه الصفحة يمكنك النقر مباشرةً إلى Go to dashboard، وهو المكان الذي تدير منه التطبيق لاحقًا.

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

4. تأكيد النشر الحي

قبل استكشاف أي من أدوات الإدارة، أردت التأكد من أن التطبيق قد نُشر بالفعل ويعمل، لا أن حالته فقط ظهرت “Completed” على الشاشة.

من صفحة Deployment completed، نقرت مباشرةً على الرابط الحي ivory-llama-856835.hostingersite.com بدلًا من الوثوق بالمعاينة المصغرة في اللوحة وحدها.

تم تحميل الصفحة الحية وأظهرت بالضبط ما كان التطبيق مبرمجًا لعرضه:

• Server build time، وهو طابع زمني حي يؤكد أن الصفحة بُنيت للتو، لا أنها عُرضت من ذاكرة تخزين مؤقت قديمة
• فحص متغير البيئة، ويظهر المتغير المخصص الذي ضبطته أثناء شاشة النشر، مؤكَّدًا بشكل صحيح على الموقع الحي نفسه، وليس فقط في معاينة اللوحة

ثم نقرت على زر Ping the API route الخاص بالتطبيق، والذي يستدعي نقطة نهاية خلفية حية بدلًا من مجرد عرض محتوى ثابت. وأعاد رد JSON نظيفًا:

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

هذا الرد أهم مما قد يبدو. فتحميل صفحة بشكل صحيح يثبت فقط أن الملفات الثابتة تم رفعها.

أما استدعاء API يعمل فيثبت أن خادم Node.js الفعلي يعمل تحت الغطاء ويستجيب لطلبات حقيقية، وهو الجزء من استضافة “Node.js web app” الذي يسهل تزويره بملف ثابت ويصعب تزويره بطابع زمني حي للخادم يُنشأ في اللحظة نفسها التي تنقر فيها زرًا.

ما رأيته: هذا هو الفحص الذي أوصي به قبل أن تثق بأي عملية نشر على هذه المنصة، أو على أي منصة مشابهة. الحالة الخضراء “Completed” ومعاينة الصورة المصغرة يخبرانك أن البناء انتهى. أما النقر إلى الرابط الحي وتشغيل شيء ديناميكي، نداء API أو قراءة قاعدة بيانات أو أي شيء لا يمكن أن يخدعه ملف ثابت مخبأ، فيخبرك أن الخادم حي فعلًا ويقوم بما بنيته من أجله.

5. إدارة Web App

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

نظرة عامة على اللوحة. بمجرد وصولك إلى هنا، تخبرك أربع شارات حالة بحالة الأمور بسرعة:

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

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

عمليات النشر ومتغيرات البيئة والسجلات. ثلاث صفحات منفصلة تغطي هذا الجزء:

• Deployments احتفظ بسجل كامل لعملية الدفع، والمؤلف، والفرع، والبصمة، وحالة الاكتمال، أي تاريخ فعلي وليس مجرد أحدث عملية
• Environment variables أظهر بشكل صحيح المتغير الوحيد الذي ضبطته أثناء النشر، ما يؤكد أنه تم تخزينه وتطبيقه، لا مجرد عرضه مرة واحدة أثناء الإعداد ثم نسيانه
• Runtime logs بث مخرجات الخادم الحية أثناء حدوثها، وسطور بدء تشغيل Next.js، وأوقات الجاهزية، وعدًّا جاريًا للمشكلات والأخطاء، وقد ظل كلاهما صفرًا طوال الوقت الذي كنت أراقبه

الأمان. أعاد Malware Scanner نتيجة نظيفة: “Your website is safe”، مع تنبيه واضح بدلًا من أن يكون مدفونًا في التفاصيل الصغيرة: فهو يفحص ملفات الموقع فقط، لا محتوى قاعدة البيانات، كما توجد خدمة مدفوعة للتنظيف إذا أردت فحصًا أعمق يشمل قاعدة البيانات. كما جاءت فحوص Vulnerabilities نظيفة أيضًا.

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

يفتح قسم Databases على نموذج يدوي بعنوان Create a New MySQL Database And Database User، أي أنك تقوم بتسمية قاعدة البيانات وإنشائها بنفسك قبل أن يتمكن تطبيقك من استخدامها. وقد أكدت ذلك مباشرةً مع Kodee، وهو ما سيأتي في قسم الدعم أدناه، وكانت الإجابة صريحة: كلمة managed تعني أن Hostinger يدير بنية قاعدة البيانات التحتية في الخلفية، لا أن قاعدة بيانات تُنشأ لك تلقائيًا لحظة تشغيل تطبيقك.

الوصول المتقدم. يوجد وصول SSH تحت Advanced، مع عنوان IP والمنفذ واسم المستخدم، لكنه يظهر Inactive افتراضيًا ويحتاج إلى نقرة Enable يدوية قبل أن تتمكن من استخدامه. ويعرض File Manager خيارًا بين استعراض ملفات هذا التطبيق فقط أو كل الملفات عبر خطة الاستضافة كاملة.

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

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

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

Build, Deploy, and Scale with Hostinger

Host modern web apps with GitHub integration, managed MySQL, global CDN, unlimited bandwidth, and built-in security tools.

قم بزيارة Hostinger

مستوى الدعم

اختبرت دعم Hostinger لـ Web Apps Hosting عبر Kodee، المساعد الذكي المدمج في hPanel، ثم مررت على قاعدة المعرفة لأرى كم تغطي من دون الحاجة إلى سؤال أحد. يظهر Kodee في مكانين يستحقان التمييز بينهما: كـ Ask AI على الموقع التسويقي العام، وكـ Agent متاح من أي صفحة داخل hPanel نفسه، بما في ذلك لوحة Web App نفسها مباشرةً.

1. الدعم بالذكاء الاصطناعي (Kodee)

طرحت سؤالين مبنيين على فجوات حقيقية وجدتها أثناء الاختبار، لا على استعلامات عامة يمكن لـ Kodee الإجابة عنها بلصق من الوثائق.

السؤال 1 اختبر سلوك فشل النشر وتوقيت متغيرات البيئة، وهما من القضايا الإنتاجية الحقيقية لأي شخص ينشر على هذه المنصة:

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

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

أما بخصوص متغيرات البيئة، فقد أكد أنه يمكنك ضبطها قبل أول نشر ضمن إعدادات النشر، وبالنسبة إلى تطبيق يعمل بالفعل، شرح الخطوات الثلاث بدقة: افتح Settings وRedeploy، ثم أضف أو عدّل المتغيرات تحت Environment variables، ثم احفظ وأعد النشر.

السؤال 2 ضغط على الفجوتين اللتين وجدتهما بنفسي أثناء استكشاف اللوحة، عبارة “managed MySQL” مقابل نموذج الإنشاء اليدوي، وكون SSH غير مفعّل افتراضيًا:

هذه الخطة تعلن عن managed MySQL، لكن اللوحة تعرض نموذجًا يدويًا لـ ‘Create a New MySQL Database’ بدلًا من قاعدة بيانات تُوفَّر تلقائيًا. هل يتم إنشاء قاعدة بيانات لكل Web App افتراضيًا، أم فقط إذا أنشأتها أنا بنفسي؟ كذلك، يُدرج SSH على أنه متاح لكنه يظهر غير مفعّل افتراضيًا. إذا لم أفعّله أبدًا، فهل يغيّر ذلك أي شيء في كيفية عمل تطبيقي، أم أن SSH مجرد خيار إضافي للمستخدمين المتقدمين؟

أكدت إجابة Kodee تمامًا ما وجدته في الواجهة، لا نسخة ألطف منه. لا يتم إنشاء قاعدة بيانات تلقائيًا لكل Web App، و”managed” تعني أن Hostinger يدير خدمة قاعدة البيانات والبنية التحتية، بينما إنشاء قاعدة بيانات فعلية وضبطها متروك لك، من خلال شاشة Create a New MySQL Database نفسها التي رأيتها سابقًا، ثم إضافة تفاصيل الاتصال إلى متغيرات بيئة تطبيقك بنفسك.

أما SSH، فقد أكد أن تركه غير مفعّل لا يغيّر شيئًا في طريقة عمل التطبيق أو نشره أو اتصاله بقاعدة البيانات. إنه موجود فقط كأداة اختيارية لأوامر CLI أو عمليات الترحيل أو تصحيح الملفات مباشرةً، وليس شيئًا تعتمد عليه المنصة في الخلفية من دون أن تدري.

ما رأيته: كانت الإجابتان متوافقتين مع ما تأكدت منه بنفسي في اللوحة بدلًا من أن تتعارضا معه أو تخففا منه، وهذا هو مظهر أداة دعم تتحقق فعلًا من حالة المنتج الحقيقية بدلًا من ترديد نص محفوظ. لم يكن من الممكن الإجابة عن أي من السؤالين بمجرد لصق نص من FAQ عام، وقد تعامل Kodee مع كليهما بإجابات محددة ومنظمة ومن جزأين خلال نحو دقيقة لكل سؤال.

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

تفتح قاعدة المعرفة لدى Hostinger على شبكة من الفئات المصنفة، 20 فئة في المجموع، تعرض كل منها عدد المقالات. ومن أكبرها: AI Builder مع 330 مقالًا، وVPS مع 276، وEmail مع 127، وWebsite مع 103.

لا تحصل Web Apps Hosting على فئة مخصصة لها. بل يتوزع محتواها بين Getting Started وhPanel وWebsite، وهذه نتيجة حقيقية لأي شخص يتوقع مركزًا واحدًا مخصصًا لها مثل VPS أو Email.

أعاد البحث عن “Web Apps” مباشرةً 71 نتيجة عبر 8 صفحات. وكانت النتائج الأولى مزيجًا من المحتوى المرتبط مباشرةً ومحتوى بعيد الصلة فقط:

• How to deploy apps built with Codex on Hostinger، ذو صلة مباشرة
• Hostinger AI Builder: How to create a web app in agentic mode، قريب لكنه منتج مختلف
• How to add a Node.js Web App in Hostinger، ذو صلة مباشرة
• How to install Flutter Web on a VPS at Hostinger، منتج مختلف تمامًا
• عدة مقالات حول طرق الدفع في Website Builder مثل PayPal وWeChat Pay وBLIK، لا علاقة لها إلا بوجود كلمتي “web” و”app” في النص

فتحت أحد النتائج الأولى، How to deploy apps built with Codex on Hostinger، لأتحقق من عمقها. واتضح أنها دليل شامل ومنظم جيدًا، يتضمن قائمة بالإطارات المدعومة في البداية، ولقطات خطوة بخطوة لمساري الاستيراد عبر GitHub والرفع عبر ZIP، وقسمًا حول تهيئة إعدادات البناء مع أوامر مثال، وشرحًا لبنية الملفات بعد النشر، واستعراضًا لمعالج الاتصال بقاعدة البيانات، وقسمًا لمراقبة الثغرات، ومربع FAQ ختامي.

ورغم أنه معنون حول Codex تحديدًا، فإن المنصة الأساسية نفسها هي التي تقف خلف منتج Node.js Web App العام، لذا فإن معظم ما فيه ينطبق مباشرةً.

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

الخلاصة العامة حول دعم العملاء

Simple Hosting for Modern Web Apps

Deploy React, Next.js, Vue, Node.js, and other modern applications without managing servers or complex infrastructure.

قم بزيارة Hostinger

هل نوصي بخدمة Hostinger Web Apps Hosting؟

نعم. مسار النشر هو أقوى جزء في هذا المنتج: تعرّف تلقائي صحيح على المكدس والفرع وإصدار Node، وسجل بناء مباشر بدلًا من مؤشر انتظار، وتطبيق حي اجتاز كل اختبارات الأداء التي أجريتها عليه، بدرجات GTmetrix مثالية من قارتين مختلفتين، وفحص اتساق عالمي نظيف من 54 نقطة، ودرجات 100/100 متطابقة من أدوات Hostinger نفسها على سطح المكتب والهاتف المحمول. وقد دعم Kodee ذلك بإجابات دقيقة ومحددة على أسئلة تقنية حقيقية بدلًا من الردود النصية العامة.

أما الحواف غير المصقولة فهي صغيرة لكنها تستحق المعرفة قبل الشراء. فعبارة “Managed MySQL” تقرأ على صفحة الخطة وكأنها شيء جاهز لحظة تشغيل تطبيقك، بينما الواقع هو نموذج إنشاء يدوي. كما أن لوحة التحكم لا تمنح Web Apps Hosting مدخلًا مخصصًا من شاشة Home الرئيسية، بل عليك أن تعرف أن تدخل إلى Websites أولًا.

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

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