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

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، نفس الأسلوب الموحّد المستخدم في كل مراجعة بالموقع، عشان تظل الدرجات مبنية على اختبار حقيقي مو على لغة تسويقية. وهنا كيف طلع التقييم في كل معيار.

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
• أدوات إنشاء قاعدة بيانات 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، مع صفر Layout Shift وصفر Blocking Time في كل موقع، يعني ما فيه أي شيء في الصفحة ينافس المتصفح على الانتباه أو يتحرك أثناء التحميل.

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

بمجرد ما يكون الـ CDN شغال، مثل ما كان هنا افتراضيًا، ما يكون الزائر بالضرورة متصل مباشرة بالسيرفر الأصلي.

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

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

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

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

أزمنة الاستجابة كانت توضح بوضوح كيف يشتغل الـ CDN caching في المسافات الواقعية:

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

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

أربعة حالات timeout، Kazakhstan وRomania واثنتين من أربع نقاط Russian، ما أشوفها مشكلة في بنية 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 تعرضها بجانب هالتشخيصات كلها مكتوبة لـ WordPress، “Speed up WordPress in 9 easy steps” و”How to optimize images for your WordPress site”، رغم إن هذا تطبيق Node.js وما له علاقة بـ WordPress في أي جزء من الستاك. هذا بقايا من قالب تشخيص مشترك، مو محتوى مبني لهذا المنتج.

النتيجة النهائية عن الأداء

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

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

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

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

1. التسجيل

بدأت من صفحة هبوط Web Apps Hosting، اللي تفتح بنقطة دعوة واحدة: Start deploying.

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

كانت فيه خطتان جنب بعض:

اخترت Cloud Startup عشان عدد التطبيقات المسموح به وheadroom في CPU مضاعف مقارنة بخطة البداية. فيه عدم اتساق بسيط لازم أنبّه له هنا: صفحة الأسعار تسميها “Cloud Startup”، لكن لما تدخل السلة، نفس الخطة تنكتب “Startup plan”. مو مشكلة وظيفية، لكن اختلاف تسمية بين شاشتين داخل نفس مسار الدفع.

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

تجاوزتها وضغطت Continue بدون أي تعقيد.

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

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

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

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

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

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

إذا نزلت تحت، بتلقى:

• Tiles ترويجية للميزات لـ AI Builder، وأداة المتجر الإلكتروني، يذكرون فيها إيميل أعمال مجاني، ووكلاء AI، وتطبيق أتمتة، ويذكرون فيها دومين مجاني
• قائمة مهام تحفزك تكمل خطوات الإعداد، إنهاء إعداد 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، شاشة مرتبة حول خطط الاستضافة الحقيقية مو شريط إدخال AI.

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

بطاقة 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 أصلًا. يعني كم نقرة إضافية لمنتج يُباع على إنه “live in a minute”. لكن بعد ما توصل له، بطاقات الخطط مرتبة وصريحة في عرض الحالة، والخطة اللي فيها تطبيق شغال فعلًا تعرضه على البطاقة مباشرة.

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 اختارت فرنسا مسبقًا، وهي أقرب منطقة لبلد الفوترة عندي، وعرضت 167ms كزمن وصول. لما سحبت إلى خيار الولايات المتحدة، ظهر 364ms، أكثر من الضعف.

اخترت الولايات المتحدة، 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 وحطيت زوج key-value واحد عشان أتأكد إنه بيوصل للتطبيق الشغال لاحقًا، ثم ضغطت 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 العامة اللي تكلمت عنها فوق.

نظرة عامة على اللوحة. أول ما توصل هنا، أربع شارات حالة تعطيك وضع الأشياء بسرعة:

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

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

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

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

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

قواعد البيانات. وهنا بالضبط يصير فيه فجوة حقيقية لازم تفهمها قبل الشراء. الخطة تعلن عن 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 اختبر سلوك فشل النشر وتوقيت متغيرات البيئة، وهذي كلها أمور إنتاجية حقيقية لأي شخص ينشر على هالمنصة:

If my app’s build fails partway through a GitHub deployment, does the app revert to the last successful version automatically, or does it go down until I fix and redeploy? And can I set custom environment variables before the first deploy, or only after?

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

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

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

This plan advertises managed MySQL, but the dashboard shows a manual ‘Create a New MySQL Database’ form rather than a database provisioned automatically. Is a database created for every Web App by default, or only if I create one myself? Also, SSH access is listed as available but shows as Inactive by default. If I never enable it, does that change anything about how my app actually runs, or is SSH purely an optional extra for advanced users?

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

وبالنسبة لـ SSH، أكد إن تركه Inactive ما يغير شيء في كيفية عمل التطبيق أو نشره أو اتصاله بقاعدة البيانات. وجوده اختياري فقط لأوامر CLI أو migrations أو تصحيح الملفات مباشرة، مو شيء يعتمد عليه النظام بشكل خفي في الخلفية.

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

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، عشان أشيك عمقه. طلع دليل شامل ومنظم، فيه frameworks المدعومة في البداية، وخطوات مصوّرة لمسار GitHub-import وZIP-upload، وقسم عن ضبط إعدادات البناء مع أوامر مثال، وشرح لبنية الملفات بعد النشر، وشرح لمعلم تكامل قاعدة البيانات، وقسم لمراقبة الثغرات، وأخيرًا 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,473 user reviews

ر.س.‏5.96 /mo

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

قم بزيارة Hostinger

Rating based on expert review

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