Hostinger built Web Apps Hosting على فكرة بسيطة: ابعت كودك من GitHub، أو ملف ZIP، أو وكيل البرمجة بالـ AI بتاعك، وخد تطبيق شغال وحيّ في الإنتاج في حوالي دقيقة، من غير أي سيرفر تديره. كنت عايز أعرف قد إيه الكلام ده فعلاً بيصمد لما تبقى إنت اللي بتدوس 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

Pros and Cons

Rating Breakdown

عشان أقيم Hostinger’s Web Apps Hosting، طبقت rating methodology الخاصة بـ 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

Plans and Pricing

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

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

حاجات مهمة تعرفها قبل ما تطلب:

• Money-back guarantee: Web Apps Hosting داخلة تحت شروط استرداد Hostinger القياسية، وهي نافذة 30 يوم مباشرة من تاريخ الشراء. وده أبسط بكتير من اللي بينطبق على خطط VPS عند Hostinger، اللي عليها كمان فترة تبريد 180 يوم بين طلبات الاسترداد. مفيش أي cooldown زي ده هنا.
• Free trial: ما لقيتش تجربة مجانية مخصصة. ضمان الـ 30 يوم هو فترة التقييم بدلًا منها.
• Payment methods: الـ checkout عرض الدفع بالبطاقة كخيار افتراضي، مع شعارات Visa وMastercard وAmex وDiscover، بالإضافة لخيار إضافة طريقة دفع تانية أثناء الشراء.
• What’s bundled in: دومين مجاني لمدة سنة، وصناديق بريد مجانية لمدة سنة، وSSL مُدار، كل ده متضمن من غير تكلفة إضافية فوق سعر الخطة، فالسعر الظاهر قريب جدًا من التكلفة الحقيقية لتشغيل Deploy كامل وآمن.
• The one upsell: Hostinger Reach، إضافة تسويق بالإيميل، بتظهر في السلة كصندوق مميز بسعر شهري منفصل. سهل جدًا تتخطاه ومش متفعل أو متضاف افتراضيًا.

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

Features

• التعرّف التلقائي على الـ framework وإصدار Node
• أدوات إنشاء قاعدة بيانات MySQL مُدارة
• Global CDN شغال افتراضيًا
• WAF وDDoS protection متضمنين
• نسخ احتياطية يومية وعند الطلب
• فحص malware وفحص الثغرات
• تكامل GitHub مع auto-deploy
• دومين مجاني، وإيميل، وSSL
• SSH access للمستخدمين المتقدمين

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

Performance

بما إن Web Apps Hosting مُدار بالكامل، إنت عمرَك ما بتاخد shell access لسيرفر، فمفيش CPU أو RAM أو disk تقدر تعمل لهم benchmark بالطريقة اللي بنعملها في مراجعة VPS.

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

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

1. GTmetrix, Tested From Two Continents

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

المرتين جابوا 100% كاملين في Performance وStructure، مع zero layout shift وzero blocking time في المكانين، وده معناه إن مفيش حاجة في الصفحة كانت بتتعارك مع المتصفح على الانتباه أو بتتحرك أثناء التحميل.

التفصيلة اللي فعلًا مثيرة للاهتمام إن Frankfurt فعليًا سبق Chicago في كل مقاييس التوقيت، رغم إني تعمدت أختار موقع سيرفر أمريكي للتطبيق ده. النتيجة دي ما تتفهمش إلا في ضوء الـ CDN.

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

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

2. Global Consistency (Check-Host)

عملت HTTP check على الرابط الحي من كل checkpoint بيقدمه Check-Host، 54 موقع عبر ست قارات. الصورة الكاملة:

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

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

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

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

أربع timeouts، كازاخستان، ورومانيا، واثنين من نقاط روسيا الأربعة، مش حاجة أقرأها كأنها مشكلة في بنية Hostinger التحتية.

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

3. Hostinger’s Own Speed Tool, Desktop and Mobile

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

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

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

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

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

وبشكل منفصل، “helpful links” اللي Hostinger بيعرضها جنب الـ diagnostics دي كلها مكتوبة لـ WordPress، “Speed up WordPress in 9 easy steps,” “How to optimize images for your WordPress site”، رغم إن ده تطبيق Node.js ومفيش WordPress فيه خالص. دي بقايا من قالب تشخيص مشترك، مش محتوى معمول للمنتج ده.

Overall Verdict on Performance

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

Ease of Use

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

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

1. Registration

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

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

كانوا ظاهرين خطتين جنب بعض:

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

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

عدّيته وضغطت Continue من غير أي تعقيد.

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

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

What I thought: الـ checkout قصير والـ upsell سهل ترفضه من غير ما تدور على زر skip مخفي. عدم تطابق اسم الخطة بين صفحة الأسعار والسلة حاجة صغيرة، بس من النوع اللي يخلي أي مشتري لأول مرة يوقف لحظة ويتأكد إنه اختار المستوى الصح.

2. Dashboard

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

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

لو نزلت تحت هتلاقي:

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

كمان فيه لوحة Agent ثابتة في الركن اليمين فوق من كل صفحة في hPanel، مش بس Home. ده نفس مساعد Kodee المستخدم للدعم، لكن هنا متعرض كأداة عامة للتصرفات، مع prompts جاهزة زي “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، شاشة منظمة حوالين خطط الاستضافة الفعلية بدل prompt bar.

هنا، كل خطة عندك ليها card لوحدها. في حسابي، ده كان معناه تلات cards فوق بعض بشكل عمودي:

Card الـ Business كمان كان بالفعل فيها app شغال من اختبار سابق، orange-walrus-700988.hostingersite.com، ومعاه أزرار Tools وDashboard.

وده لوحده حاجة مفيدة تلاحظها. أول ما Web App يبقى موجود، الكارت بتاعه بيكبر وفيه سطر زي ده بيعرض الموقع الحي مباشرةً، وده بالظبط الشكل اللي كارت Cloud Startup بتاعك هيبقى عليه لما تخلص setup.

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

What I thought: hPanel واضح لما تعرف الشاشة الصح، بس Web Apps Hosting ملوش باب دخول واضح من الأول. إنك تقع على Home بيطلعلك prompt bar واختصارات، مش مسار لإنشاء app، فلازم تكون عارف تدوس Websites، وبعدها Web Apps، قبل ما Setup يظهر. دي كام نقرة زيادة لمنتج متباع على إنه “live in a minute.” لكن بعد ما توصل لهنا، الكروت نفسها نظيفة وصريحة في حالة كل حاجة، وأي plan عليها app شغال بتعرضه على الكارت مباشرةً.

3. Deploying the App

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

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

ضغطت على الدائرة جنب Node.js web app، وبعدها ضغطت Next.

من هناك:

• Domain screen: اخترت Use temporary domain بدل ما أربط دومين حقيقي، لأن ده كان deploy تجريبي.

• Server location screen: Hostinger اختار فرنسا افتراضيًا، أقرب منطقة لبلد الفاتورة بتاعتي، ووراني 167ms latency. لما نزلت لخيارات الولايات المتحدة لقيت 364ms، أكتر من الضعف.

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

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

• Deploy method screen: خيارين رئيسيين، Import Git repository (معلّم Recommended) أو Upload your files، ومعاهم callout تحت للنشر مباشرةً من 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، وهي قائمة قابلة للتمرير فيها كل repository مرتبط بحساب GitHub بتاعك، وكل واحد معاه زر Deploy جنبه. لقيت repo التجريبي اللي كنت رافعه قبل كده، hostadvice-webapps-test، وضغطت Deploy جنبه.

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

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

كل سطر من الخمسة دول كان جنبه زر Change أو Add، فمفيش حاجة هنا مقفولة لو التعرف التلقائي جاب حاجة غلط.

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

Watching the build

الشاشة بتتحول لـ view بعنوان Deploying… ومعاه progress bar متسمية “Deployment from GitHub”، وبتتحرك على مراحل واضحة، شوفتها وهي بتوصل 28%، وبعدها 51%، في طريقها للاكتمال. تحت شريط التقدم فيه panel قابل للطي بعنوان Build logs، ولو فتحته بتشوف terminal output مباشر حقيقي وهو بيتولد، مش spinner وهمي:

> 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

لما الـ build يخلص، بتوصل لشاشة Deployment completed! وفيها preview thumbnail حي لتطبيقك الحقيقي شغّال هناك، جنب ملخص فيه اسم المستودع والرابط الحي المخصص.

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

What I thought: التعرّف التلقائي هو النجم هنا. الـ framework، والـ branch، وإصدار Node كلهم طلعوا صح من غير أي خانة يدوية، والـ build log الحي بيخلي الانتظار واضح بدل ما يكون غامض. نقطة الضعف الوحيدة هي التوقف اللي حوالي 30 ثانية قبل ما توصل أصلًا لشاشة الإعدادات، فترة كفاية تخليك تتساءل لو في حاجة علّقت قبل ما العملية تبدأ بشكل مرئي.

4. Confirming the Live Deployment

قبل ما أستكشف أي أدوات إدارة، كنت عايز أتأكد إن التطبيق اتنشر فعلًا وبيشتغل، مش بس متعلّق عليه Completed على الشاشة.

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

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

• Server build time، timestamp حي بيأكد إن الصفحة اتبنت للتو، مش متسربة من cache قديم
• Environment variable check، وبيوضح الـ variable المخصص اللي حطيته أثناء شاشة الـ deploy، ومتأكد منه صح على الموقع الحي نفسه، مش بس في preview بتاع الداشبورد

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

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

الرد ده أهم مما شكله باين. مجرد إن الصفحة تفتح صح بيثبت بس إن الملفات الثابتة اترفعت.

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

What I thought: وده الفحص اللي أنصحك تعمله قبل ما تثق في أي deploy على المنصة دي، أو على أي منصة شبهها. حالة “Completed” الخضرا وصورة المعاينة بتقولك إن الـ build خلص. إنك تفتح الـ live URL وتطلق حاجة ديناميكية، API call، قراءة قاعدة بيانات، أي حاجة ما تنفعش تتزيف بصفحة static متخزنة، ده اللي بيقولك إن السيرفر فعلاً عايش وبيعمل اللي إنت بنيته عشانه.

5. Web App Management

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

Dashboard overview. أول ما بتوصل هنا، أربع badges للحالة بيورّوا وضع كل حاجة بسرعة:

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

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

Deployments, environment variables, and logs. تلات صفحات منفصلة بتغطي الجزء ده:

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

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

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

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

Advanced access. SSH access موجود تحت Advanced، ومعاه IP والـ port وusername، لكنه Inactive افتراضيًا ولازم تضغط Enable يدويًا قبل ما تقدر تستخدمه. File Manager بيدي اختيار بين تصفح ملفات التطبيق ده بس أو كل الملفات عبر خطة الاستضافة كلها.

What I thought: داشبورد الاستخدام اليومي منظّم وشامل. الأمن وسجل النشر سهلين في الوصول ومفيدين فعلًا، وفحص malware النظيف مع runtime logs من غير أخطاء ادّاني ثقة حقيقية إن التطبيق صحي، مش بس online.

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

Overall Verdict on Ease of Use

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

Level of Support

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

1. AI Support (Kodee)

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

Question 1 اختبر سلوك فشل الـ deploy وتوقيت environment variables، ودهما من المخاوف الإنتاجية الحقيقية لأي حد بينشر على المنصة دي:

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 رد بشكل مباشر وصحيح في النقطتين. لو الـ build فشل، ده ما بيمسحش التطبيق الشغّال حاليًا، ولو فيه deployment سابق ناجح، التطبيق بيكمّل يعرض آخر نسخة شغالة. ولو كان أول deployment ومفيش نسخة ترجع لها، التطبيق بيقف لحد ما يتصلح الـ build ويتعمله deploy تاني، وده رد واضح وصريح بدل تطمين مبهم.

وبالنسبة لـ environment variables، أكد إنك تقدر تضبطها قبل أول deploy من إعدادات النشر، وللتطبيق اللي شغال بالفعل، شرحلِك الخطوات التلاتة بالظبط: افتح Settings وRedeploy، أضف أو عدّل variables تحت Environment variables، احفظ واعمل redeploy.

Question 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 اللي كنت شفتها، وبعدها لازم تضيف بيانات الاتصال للتطبيق في environment variables بنفسك.

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

What I thought: الردين طابقوا اللي كنت تأكدت منه بنفسي في الداشبورد بدل ما يعارضوه أو يخففوه، وده علامة إن أداة الدعم فعلًا بتراجع حالة المنتج الحقيقية بدل ما تقرأ سكريبت. ولا سؤال من الاتنين كان ينفع يتجاوب عليه بنسخ FAQ عامة، وKodee تعامل مع الاتنين بإجابات محددة ومنظمة ومن قسمين، وكل واحد أخد حوالي دقيقة.

2. Knowledge Base

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

Web Apps Hosting ما عندهاش category مخصصة لوحدها. المحتوى بتاعها متوزع بين 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، وقسم عن ضبط build settings مع أوامر مثال، وتفصيل لبنية الملفات بعد النشر، وشرح wizard لتوصيل قاعدة البيانات، وقسم لمراقبة الثغرات، وFAQ في الختام.

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

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

Overall Verdict on Customer Support

Simple Hosting for Modern Web Apps

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

قم بزيارة Hostinger

Do We Recommend Hostinger Web Apps Hosting?

أيوه. عملية الـ deploy هي أقوى جزء في المنتج ده: تعرّف تلقائي صحيح على الـ stack، والـ branch، وإصدار Node، وسجل build حي حقيقي بدل spinner، وتطبيق شغال فعليًا نجح في كل اختبارات الأداء اللي رميتها عليه، GTmetrix كامل من قارتين مختلفتين، وفحص consistency نظيف من 54 نقطة، ودرجات 100/100 متطابقة من أدوات Hostinger نفسها على الديسكتوب والموبايل. Kodee كمان دعم ده بإجابات دقيقة ومحددة على أسئلة تقنية حقيقية بدل ردود سكريبت عامة.

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

لمطور عايز deploy سريع مستقل عن الـ framework على بنية تحتية بتعمل benchmark بالشكل ده، دي توصية سهلة. أما اللي متوقع كل ميزة مُعلنة تبقى شغالة لحظة إتمام الشراء، يبقى لازم يحسب كام دقيقة زيادة عشان يجهز قاعدة البيانات بنفسه.

Hostinger

5.0

2,473 user reviews

ج.م.‏ 90 /mo

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

قم بزيارة Hostinger

Rating based on expert review

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