إدارة الاستضافة غالبًا بتقطع التقديم. بتكتب كود في محرر، تفتح لوحة استضافة عشان تنشئ موقع، تبدّل لطرفية أوامر عشان تعمل حزمة أو ترفع المشروع، ترجع للوحة عشان تراجع نشر، وتفتح أدوات أكتر لما DNS أو السجلات أو موارد السيرفر تحتاج اهتمام.
Hostinger Connector بيقلل تبديل السياق ده. هو بيربط خدمات Hostinger بأدوات الكود المدعومة بالذكاء الاصطناعي من خلال Model Context Protocol (MCP)، وده بيسمحلك تسأل مساعد AI يراجع أو يدير موارد الاستضافة المدعومة من غير ما تسيب المحرر.
ده شكله مريح. لكنه كمان بيفتح سؤال أهم: ينفع تثق في مساعد AI إنه ينفذ مهام استضافة حقيقية بدقة؟
عشان أعرف، جرّبت Hostinger Connector مع VS Code وGitHub Copilot على حساب Hostinger حقيقي. استخدمت تطبيق Express.js صغير اسمه PulseWatch واتبعت workflow من التثبيت لحد النشر المباشر. كمان جرّبت إعادة النشر، وسجلات الـ build، والـ logs، والاستعادة بعد ما كسرت عمدًا أمر تشغيل التطبيق.
دي طريقة تقييمي لـ Hostinger Connector عبر الجوانب الأهم لمطور بيقرر إذا كان يستخدمه: التكلفة، نطاق المميزات، سهولة الاستخدام اليومية، دقته في تنفيذ المهام الحقيقية، والدعم اللي وراه لما يحصل مشكلة. كل درجة هنا مبنية على اللي لقيته فعلاً أثناء الاختبار، مش صفحة التسويق.
| Parameter | Score | Why this score |
|---|---|---|
| Prices | 9.7/10 | Connector مفيهوش أي رسوم اشتراك منفصلة خالص ومجاني مدموج مع كل خطة. التكلفة الوحيدة هي مورد الاستضافة الأساسي اللي كنت هتحتاجه برضه. |
| Features | 9.5/10 | نطاق المميزات ممتد أبعد من النشر ليشمل المواقع، والدومينات، وDNS، وقواعد البيانات، وحملات الإيميل، وموارد VPS، والسجلات، والتشخيص، وده بيغطي أرض أكتر من أداة نشر تقليدية. |
| Ease of Use | 9.1/10 | التثبيت وOAuth كانوا سريعين ومحتاجوش أي إعداد يدوي، والنشر المتكرر كان سهل. إعداد موقع Node.js الأولي احتاج hPanel بعدما فشل الـ AI في تحديد هدف صالح، وده كان الفارق الوحيد الحقيقي في setup سلس بشكل عام. |
| Execution Accuracy | 8.5/10 | تحليل المشروع، وتعديل الكود، والتجهيز، والنشر، والاستعادة اشتغلوا كويس. الـ AI استخدم دومين متخيل وفسّر فحص accessibility بشكل زيادة قبل ما الهدف ده يكون موجود. |
| Support | 9.5/10 | Kodee قدّم إجابة دقيقة ومحددة على سؤال تقني حقيقي من أول محاولة، والمتخصص البشري اللي بعده كان أدق كمان. التصعيد احتاج طلبين مباشرَين، لكن إجابات الـ AI والبشر كانت موثوقة لما اتقدمت. |
| Overall | 9.3/10 | أداة workflow مفيدة لمستخدمي Hostinger اللي بيشتغلوا داخل محررات مدعومة بالـ AI. مابتكلفش أي حاجة إضافية، وبتغطي نطاق كبير من المميزات، وكمان الإعداد والدعم صمدوا كويس في الاختبار. دقة التنفيذ مع أهداف النشر الجديدة هي النقطة الوحيدة اللي لازم تنتبه لها. |
Hostinger Connector مش بيتباع كمنتج مستقل. Hostinger بتقول إن Connector مدمج مجانًا مع كل خطة، وده معناه إنه مفيش رسوم شهرية منفصلة لـ Connector تضيفها على فاتورة الاستضافة.
لكن “مجاني” محتاج سياق. Connector بيدير موارد Hostinger؛ هو مش بديل عنها. لسه محتاج hosting أو cloud أو VPS أو domain أو email أو خدمة تانية مؤهلة من Hostinger عشان المهام اللي عايز ينفذها.
في وقت المراجعة دي، صفحة Connector كانت مبرزة Business Web Hosting وCloud Startup.
| Plan | Promotional price | Upfront term shown | Renewal price | Web apps | Websites |
|---|---|---|---|---|---|
| Business | $3.79/month | $181.92 for 48 months | $16.99/month | 5 | 50 |
| Cloud Startup | $7.99/month | $383.52 for 48 months | $25.99/month | 10 | Unlimited |
الأسعار كانت ظاهرة قبل الضرائب المطبقة. الأسعار الترويجية ومعدلات التجديد ممكن تتغير، فراجع إجمالي checkout الحالي بدل ما تحكم على الخطة من الرقم الشهري المعلن بس.
معلومة تسعير: ما تشتريش خطة أعلى بس عشان توصل لـ Connector. اختار الخطة بناءً على عدد المواقع وweb apps اللي محتاجها، والموارد اللي بتحتاجها، ومستوى الدعم اللي عايزه. Connector مجرد طبقة إدارة مدمجة، مش المنتج الأساسي اللي بيتسعّر.
Hostinger بتعلن عن ضمان استرداد فلوس لمدة 30 يوم للمشتريات المؤهلة من الاستضافة. مفيش سياسة استرداد منفصلة لـ Connector عشان Connector مفيهوش رسوم مستقلة.
الإجراءات المتاحة بالضبط بتعتمد على خدمات Hostinger الموجودة في حسابك وعلى الأدوات اللي العميل الـ AI المتصل بيوفرها.
Hostinger كمان موثقة حدود المعدل. حسب Connector FAQ، السعة الافتراضية هي 60 طلب في الدقيقة و1,000 طلب في الساعة، ومعلومات حد المعدل بترجع في headers الاستجابة.
الحدود دي سخية للاستخدام التفاعلي، رغم إن workflows المؤتمتة أو المتكررة جدًا لازم تبتعد برضه عن أي calls مكررة غير لازمة.
قبل ما أقدر أحكم هل Hostinger Connector بينشر ويدير الاستضافة كويس، احتجت أعرف إيه المطلوب عشان أشغله من الأساس.
أداة معمولة عشان تفضل جوه المحرر بتفقد بريقها بسرعة لو الإعداد بقى معناه تعديل ملفات config، أو توليد API tokens، أو إعادة مصادقة متكررة. القسم ده عن الإعداد بس. اختبار المهام العملية هييجي بعده مباشرة.
ثبت Hostinger Connector من VS Code Marketplace. ظهر أول نتيجة لما بحثت عن “Hostinger”، والمطور كان Hostinger Official، واتثبت من أول محاولة في أقل من دقيقتين.
| Detail | Result |
|---|---|
| Marketplace search | Passed, appeared immediately |
| Publisher verification | Hostinger Official |
| Installation | Completed in under two minutes |
| Extension version at time of testing | 1.3.1 |
| Marketplace installs | 8,140 |
| User rating | 5 stars, based on two ratings |
الصف دي تستاهل ملاحظة. 5 stars شكله قوي، لكن عيّنة من مراجعتين بس ما بتقولليش حاجة تقريبًا عن تجربة المستخدم المعتادة. ما كنتش هاعتمد على الرقم ده في نص المراجعة.
مفاجأة في متطلب أساسي: Hostinger Connector بيوفر أدوات Hostinger، لكنه محتاج agent AI شغال بالفعل جوه المحرر عشان يقدر يناديها.
الإضافة نفسها مافيهاش أي حاجة تتكلم معاها لوحدها. في VS Code، الـ agent ده هو GitHub Copilot Chat، لأنه حاليًا واجهة الـ AI اللي VS Code بيوفرها لنداءات MCP tools. كان Copilot شغال عندي بالفعل، فده ما بطأنيش، لكن لازم القراء يعرفوا إن Connector قيمته على قد الـ AI agent اللي وراه.
من غير agent متثبت ومسجّل دخول، مفيش حاجة فعليًا يقدر يركب عليها.
التثبيت ما احتاجش:
تثبيت الإضافة نفسها كان من أسلس أجزاء الاختبار كله. العائق الحقيقي الوحيد هو اعتماد Hostinger ما بيبرزشوش قدامك بوضوح: الإضافة محتاجة AI agent شغال في المحرر عشان تعمل أي حاجة أصلًا.
بعد ما الإضافة بقت موجودة، السؤال اللي بعده كان هل ربطها بحساب حقيقي هيبقى سهل بنفس الدرجة.
ربط الحساب تم عبر OAuth من خلال زر “1-Click Connect”. VS Code فتح صفحة authorization لـ Hostinger في المتصفح، واكتشف جلسة Hostinger الموجودة عندي، وطلب مني أوافق على الوصول لحاجة اسمها hostinger-mcp.
بعد ما ضغطت Allow، رجعت لـ VS Code وظهر “Connected via OAuth.”
| Check | Result |
|---|---|
| One-click connection | Passed |
| Browser opened automatically | Passed |
| Existing Hostinger session detected | Passed |
| Manual API token required | No |
| Authorization screen shown | Yes |
| Permissions explained | Yes, but broadly |
| Returned to VS Code successfully | Passed |
شاشة الصلاحيات قالتلي إن Connector يقدر يدير المواقع، والاستضافة، والدومينات، والاشتراكات، وخدمات تانية من Hostinger.
دي قائمة فئات، مش تفصيل صلاحية بصلاحية. كنت كنت أفضل هنا شوية دقة أكتر، لأن “manage subscriptions” و”manage websites” بيمثلوا مستويات مخاطرة مختلفة جدًا.
اللي إداني شوية تحكم من النوع ده كان panel منفصل جوه الإضافة بيسرد كل فئات الأدوات وبيخليني أفعل أو أعطل كل واحدة بشكل منفصل:
| Tool category | Tools available | Default status |
|---|---|---|
| Websites | 80 | Enabled |
| Domains | 26 | Enabled |
| Subscriptions and Payments | 7 | Enabled |
| Email Marketing | 12 | Enabled |
| Ecommerce | 12 | Disabled |
| VPS | 62 | Disabled |
ده 199 أداة بالمجموع، و125 مفعّلين افتراضيًا. سيبت Ecommerce وVPS مقفولين لحد ما أبقى جاهز أختبرهم مباشرة، والإضافة احترمت الحدود دي طوال الاختبار.
دي من نوع تفاصيل الأمان اللي ما بتظهرش في صفحة تسويق Hostinger لكنها مهمة لأي حد بيقرر قد إيه يدي مساعد AI وصول للحساب. أعتبرها نقطة قوة حقيقية.
فصل الحساب متاح من نفس اللوحة، من غير ما تحتاج تغيّر كلمة سر Hostinger أو تدور على token مخزّن.
التفويض كان سريع وما احتاجش إني أدير token بإيدي، لكن شاشة الصلاحيات واسعة أكتر من اللازم بدل ما تكون تفصيلية. تحكم فئات الأدوات جوه الإضافة بيعمل أكتر لتقليل المخاطر الفعلية من شاشة OAuth نفسها.
Hostinger بتعلن الدعم للـ clients التالية، ومجموعة دي جاية من شاشة onboarding الخاصة بالإضافة نفسها:
| Editor or client | Listed by Hostinger |
|---|---|
| VS Code | Yes |
| Cursor | Yes |
| Windsurf | Yes |
| Devin Desktop | Yes |
| Antigravity | Yes |
| Claude Code | Yes |
| OpenAI Codex CLI | Yes |
أنا استخدمت VS Code مع GitHub Copilot كبيئة الاختبار الأساسية.
الإعداد قاللي إن Connector سهل أوصل له. لكنه ما قالليش لسه إذا كان هيؤدي الشغل فعلًا كويس بعد ما يتوصل، ودي كانت السؤال الأصعب اللي نزلت أختبره بعد كده.
تثبيت extension وربطها هو الجزء السهل. المهم فعلًا هو هل بتنجز شغل استضافة حقيقي صح، فبنيت تطبيق Express.js صغير اسمه PulseWatch وحطيت Connector في نفس المسار اللي أي مطور هيعدي بيه بعد التثبيت: يراجع الحساب، يلاقي هدف نشر، ينشر المشروع، يحدّثه، يراجع النتائج، ويتعافى من فشل عملته أنا عمدًا.
| Test | What I wanted to learn |
|---|---|
| Read account data | Can it accurately understand the hosting account? |
| Find a deployment target | Can it identify the right website without guessing? |
| Analyze the Node.js project | Does it understand the app before touching it? |
| Deploy PulseWatch | Can it move a real project from editor to live hosting? |
| Publish a content update | Is it useful for routine development work? |
| Inspect builds and logs | Does it give useful evidence after a deployment? |
| Deploy a broken version | Does it reveal a real application failure? |
| Recover the application | Can it restore a known-good release safely? |
PulseWatch كان بسيط عمدًا: Express server، وصفحة رئيسية، وpackage.json start script، وendpoint /api/health بيرجع JSON. الـ health endpoint ده طلع مهم بعدين.
منصة الاستضافة ممكن تعلن إن الـ build اكتمل حتى لو التطبيق فشل عند التشغيل. Endpoint حي اداني طريقة مستقلة أراجع بيها إذا العملية المنشورة فعلًا بترد، بدل ما أصدق badge الحالة.
بدأت بprompts للقراءة فقط قبل ما أدي المساعد أي فرصة يقرب من تغييرات حية. لو ما قدرش يصف حسابي بدقة، يبقى ما عنديش سبب أثق فيه في النشر أو DNS أو إجراءات VPS.
أداة عرض المواقع رجعت خمس مواقع:
لكن الحساب عندي كان فيه أكتر من كده. hPanel كان مبيّن مواقع موزعة على خطط Premium وBusiness وGrowth، بما فيها مواقع WordPress ومواقع PHP/HTML ومشاريع Website Builder وعدة دومينات مؤقتة.
وفي prompt تاني بيسأل عن خطط الاستضافة النشطة، المساعد قال إن عندي “one active hosting plan.” hPanel كان مبيّن 3: Premium وGrowth وBusiness.
| Check | Result |
|---|---|
| Listed known websites | Passed |
| Listed all hosting plans | Failed |
| Detected the unused Business plan | Failed |
| Made any account changes | No |
إنصافًا لـ Connector، لما راجعته وقلتله على التناقض، صحح نفسه، وفصل بوضوح بين اللي تأكد منه واللي كان افترضه، وما كررش الادعاء الغلط.
دي طريقة فشل أحسن من إنه يصر على الغلط، لكنها معناها إن أول إجابة على سؤال متعلق بالحساب بالكامل ما ينفعش تتاخد كحقيقة مسلّم بيها.
القراءة فقط اشتغلت، لكن أول إجابة على أي سؤال على مستوى الحساب كانت ناقصة. صححها لما اتعترض عليه، وده مهم، لكن ماكانش المفروض أضطر أعترض أصلًا.
الفجوة دي في رؤية الحساب كانت تمهيد لمشكلة أكبر. الاختبار الحقيقي إذا كانت مهمة فعلًا ولا لأ جه بعد كده، لما طلبت من Connector يلاقي موقع جديد هو ماكانش اتقاله اسمه قبل كده.
هنا الاختبار كشف أكتر حاجة. طلبت من المساعد يحدد موقع Node.js جديد من غير ما أذكر الدومين، ومن غير ما يلمس أي موقع موجود.
اختيار الهدف شرط أمان أساسي لأداة تقدر تتصرف على حساب حي، فكنت عايز أشوف إزاي بيتعامل مع عدم اليقين بدل إجابة نظيفة جاهزة.
وده اللي حصل، بالترتيب:
| Step | What the Connector did | Result |
|---|---|---|
| 1 | Reused a domain name from an earlier failed attempt: pulsewatch-temp-20260714.hostingersite.com | This domain had never been returned by any website-listing call |
| 2 | Ran an accessibility check on that domain | Returned is_accessible: true |
| 3 | Treated that result as confirmation the website existed | Incorrect. Accessibility is not the same as an existing, deployable website record |
| 4 | Attempted deployment using resource IDs it had not verified as hosting order IDs | Hostinger returned [Hosting:9999] Not found, twice |
المشكلة الأساسية: الـ IDs اللي استخدمها كانت resource IDs للدومين، مش hosting order IDs. هو ما تحققش من الفرق ده قبل ما ينادي أداة إنشاء موقع حية بيها.
لما طلبت منه يشرح نفسه، المساعد في النهاية قدّم وصف دقيق: كان عنده أداة شغالة لعرض المواقع طول الوقت، لكنه ما نادهاش تاني بعد ما أنشأت موقع جديد عبر hPanel، فسد الفجوة بدومين غير متحقق منه بدل ما يحدث البيانات.
ولما طلبت منه مباشرة يعيد تشغيل أداة العرض دي ويتحقق من وجود record جديد، نادى 3 أدوات أخرى غير مرتبطة بالنشر وقال “no new website appeared,” وهو استنتاج نداءات الأدوات اللي عملها ما كانتش تقدر تدعمه.
ولا حاجة من ده عمل موقع بالغلط في حسابي. المحاولات الفاشلة ما سابتش أي حاجة وراءها. لكن النمط يستاهل يتقال بصراحة. قدام بيانات ناقصة، المساعد سد الفجوة بافتراض منطقي الشكل، واعتبر إشارة ضعيفة دليل قوي، وتصرف على حساب حي قبل ما الافتراض ده يتراجع.
دي أهم نتيجة في القسم ده. Connector ممكن يخمّن هدف ويتصرف بناءً على التخمين بدل ما يقف ويسأل. هو فشل بأمان هنا، لكن عادة التعامل مع إشارة ضعيفة كأنها إثبات هي الحاجة اللي لازم تنتبه لها في حسابك أنت.
مع عدم قدرة Connector إنه يلاقي الهدف لوحده، ما كانش قدامي غير خيار واحد: أعمل الهدف بنفسي وأشوف هل ده هيغير حاجة.
بما إن Connector ما قدرش يحدد الهدف الجديد بشكل موثوق لوحده، كملت الإعداد الأولي يدويًا من خلال hPanel عشان أشوف إيه اللي Hostinger بيجهزه قبل ما يبقى النشر عبر Connector ممكن.
المسار كان: Create a new site → Node.js web app → temporary domain → Hostinger اختار تلقائيًا data center في United Kingdom بlatency متوقعة 147ms → اختيار من 3 طرق نشر.
الشاشة التالتة دي تستاهل وقفة لوحدها. Hostinger بيعرض “Build with Hostinger Connector” كطريقة نشر جنب GitHub import والرفع اليدوي للملفات. اخترته وأنا متوقع إنه هيكمل تجهيز الموقع.
بدل كده، حولني لصفحة التثبيت الخاصة بـ Connector، اللي كنت مخلصها من قبل. دي فجوة onboarding حقيقية. الخيار المقدم كمسار خاص بـ Connector ما كانش بيجهز أي حاجة فعليًا.
رجعت واخترت الرفع اليدوي للملفات. Hostinger قبل أرشيف مشروعي (11.46 KB، مع استبعاد node_modules )، وشاشة الإعدادات أظهرت اكتشاف تلقائي دقيق:
ضغطت Deploy. العملية اكتملت بنجاح، وHostinger خصص دومين مؤقت حقيقي: orange-walrus-700988.hostingersite.com. ده دومين مختلف عن اللي Connector كان اخترعه قبل كده. فتحت الصفحة الرئيسية و/api/health يدويًا وتأكدت إن الاتنين شغالين.
المسار اليدوي اشتغل من غير أي احتكاك بمجرد ما بطلت أستنى Connector يلاقيه. زر “Build with Hostinger Connector” في الشاشة دي لازم يتصلح أو يتشال. دلوقتي هو بيوعد بحاجة ما بيعملهاش.
دلوقتي فيه موقع حقيقي ومتأكد منه. السؤال اللي بعده كان هل Connector هيتصرف بشكل مختلف لما يبقى عنده حاجة ثابتة يلاقيها.
بعد ما بقي عندي موقع حقيقي ومتأكد منه، رجعت لـ Connector وطلبت منه يراجع الدومين ده بالضبط. المرة دي اشتغل بشكل نظيف.
| Check | Result |
|---|---|
| Recognized the site as a Node.js deployment target | Passed |
| Found the completed deployment record | Passed |
| Found the matching Node.js build record | Passed |
| Deployment and build shared the same UUID | Passed |
ده أكد حاجة مهمة: الإخفاقات اللي فاتت كانت في العثور على هدف جديد وإنشائه، مش في قدرة Connector إنه يشتغل مع موقع Node.js لما يكون موجود أصلًا.
بعد كده جرّبت الميزة اللي Hostinger بيسوق لها أكتر: أغيّر سطر كود محليًا وأنشره من غير ما أفتح hPanel.
طلبت من المساعد يغيّر سطر واحد في نص الصفحة الرئيسية، من “Monitor Every Service. Catch Every Issue.” إلى “Monitor Every Service. Resolve Issues Faster.”
| Step | Result |
|---|---|
| Found the existing text | Passed |
| Changed only the requested line | Passed |
| Verified the app locally before deploying | Passed |
Packaged the project, excluding node_modules and .git | Passed |
| Deployed to the existing, confirmed website | Passed |
| Checked deployment and build status afterward | Passed |
العملية كلها خدت حوالي دقيقة. المساعد وصف النشر الجديد إنه “pending” فورًا بعد ما بعته، بس ده كان لأنه اتراجع قبل ما Hostinger يخلص المعالجة.
لما عملت refresh للموقع المباشر بنفسي، العنوان الجديد كان ظاهر بالفعل.
سجلات الـ build اللي استرجعها بعد كده كانت محددة ومفيدة: 67 package اتضافوا، و68 audited، و0 vulnerabilities، من غير أخطاء.
للمواقع الموجودة أصلًا، دي تجربة قريبة جدًا من workflow اللي Hostinger بيوعد به. عدّل، راجع محليًا، ابعت، وتأكد، وكل ده من غير ما تسيب المحرر، في حوالي دقيقة. دي أقوى نتيجة في الاختبار كله.
نشر نظيف بيقوللي بس إن الطريق السهل شغال. عشان أعرف Connector بيتصرف إزاي تحت الضغط، كسرت التطبيق عمدًا.
الأداة ما بتكسبش ثقتي إلا لما تصمد قدام فشل حقيقي، مش demo نظيف بس. كسرت التطبيق عمدًا عشان أشوف هل تقارير الحالة والسجلات عند Connector تقدر فعلًا تساعدني أشخّص المشكلة.
قبل أي تغيير، المساعد كان عامل backup لـ package.json في package.json.bak، ودي عادة كويسة في حد ذاتها.
بعد كده خليته يغيّر start script من “start”: “node server.js” إلى “start”: “node missing-server.js”، وهو ملف غير موجود.
تشغيله محليًا أكد فشل حقيقي وقابل للتكرار: Error: Cannot find module ‘…/missing-server.js’.
نشرت النسخة المعطلة رغم كده، عمدًا، عشان أشوف Hostinger هيرجع إيه.
| Status shown | What it confirmed | What it did not confirm |
|---|---|---|
| Build: completed | Dependencies installed, build stage finished | The application actually started |
| Deployment: completed | Hostinger accepted and processed the release | Every route was healthy |
سجلات الـ build المتاحة عبر Connector أظهرت تثبيت ناجح للـ dependencies ومفيش حاجة غير كده. خطأ التشغيل وقت runtime بتاع missing-module ما ظهرش فيها. أي مطور يبص على badge أخضر “completed” هيبقى مفيش عنده سبب يشك إن الموقع بايظ.
التعافي مشى بسلاسة. المساعد رجّع package.json من النسخة الاحتياطية، وراجع التطبيق محليًا، وأعاد النشر، وأكد الإصلاح من خلال نداء مباشر لـ endpoint /api/health الحي بدل ما يثق في حالة النشر.
الـ endpoint ده رجّع response شغال، ودي كانت الدليل الوحيد في الاختبار كله اللي أثبت فعلًا إن التطبيق شغال.
دي النتيجة المهمة التانية. إن الحالة “completed” مش دليل إن التطبيق شغال، وسجلات Connector نفسها مش هتقولك كده. الاستعادة نفسها اشتغلت كويس بعد ما عرفت أصلًا إن فيه مشكلة أستعيدها.
بعد فشل badge الحالة ما كانش يقدر يكشفه، حبيت أعرف فين كمان ممكن ثقة Connector تسبق قدرته الحقيقية. متغيرات البيئة كانت الاختبار الجاي.
طلبت من المساعد يضيف environment variable بسيط، ويتأكد إن الإعداد موجود كقدرة مخصصة في Connector قبل ما يلمس أي حاجة، ويقف لو مش موجود.
دور في الأدوات المتاحة، وما لاقاش أي إجراء مخصص لإدارة environment variables في Node.js، ووقف قبل ما يعمل أي تغييرات في الكود أو النشر.
دي السلوك اللي كنت عايز أشوفه في باقي الاختبار كله. لما واجه حد حقيقي، وقف بدل ما يخمّن. ما أقدرش أقول إن Hostinger Connector مفيهوش دعم environment variables في أي حتة، لكن فقط إنه ماكانش فيه إجراء من النوع ده ظاهر أثناء الاختبار ده.
| Test | Result | Key finding |
|---|---|---|
| Back up working manifest | Passed | Recovery file created before modification |
| Introduce missing entry point | Passed | Controlled failure added |
| Reproduce failure locally | Passed | MODULE_NOT_FOUND confirmed |
| Deploy broken version | Passed | Hostinger accepted the archive |
| Build status detects failure | Failed | Build still showed completed |
| Build logs expose runtime error | Failed | Missing-module error was absent |
| Restore working manifest | Passed | Original start command recovered |
| Redeploy working version | Passed | Deployment completed |
| Verify live health endpoint | Passed | API returned operational status |
Hostinger Connector أدّى المهام الروتينية المحددة كويس:
وكان أضعف لما المهمة احتاجت تفسير عبر بيانات حساب ناقصة:
النمط ده مفيد وأنت بتقرر قد إيه تدي للمساعد استقلالية.
استخدم prompts أوسع للعرض منخفض الخطورة. واستخدم prompts دقيقة ومتطلبات تأكيد واضحة للإجراءات اللي بتغيّر البنية التحتية الحية.
مثلاً، بدل:
| Deploy this app to a new temporary Hostinger site. |
استخدم:
| List the websites currently returned by Hostinger. Identify a Node.js website only if it appears in that result. Show me the exact domain and evidence before deploying. Do not generate, infer, or reuse a domain that was not returned by Hostinger. |
الـ prompt التاني بيضيّق مساحة الافتراض عند المساعد.
تشغيل Hostinger Connector كان سهل، من غير أي احتكاك إعداد تقليدي، وتحكم فئات الأدوات التفصيلي اداني فعلًا كلمة في اللي الـ AI يقدر يلمسه.
لما موقع حقيقي موجود ودومينه معروف، الأداة أنجزت الشغل كويس: تعديل نص واحد من الكود إلى حي في حوالي دقيقة، ومعاه سجلات مفيدة تثبت ده.
المشكلة ظهرت بدري في العملية، مش بعدين. قدام هدف جديد ما قدرش يلاقيه، Connector اخترع دومين وتصرف عليه قبل ما يتأكد. وكمان علّم نشر معطوب على إنه “completed” من غير ما يظهر خطأ الـ runtime في سجلاته. ولا واحدة من الحالتين بتخلي الأداة غير موثوقة للمواقع الموجودة أصلًا، لكن الاتنين معناه إن النشر الجديد وفحص ما بعد النشر محتاجين نظرة تانية قبل ما تثق فيهم.
Hostinger بتركّز دعمها حوالين live chat والخدمات الذاتية بدل المكالمات، فركّزت اختباري على الحتة اللي أغلب المستخدمين هيوصلوا لها فعلًا: المساعد AI المدمج في hPanel، والتصعيد البشري اللي وراه، وقاعدة المعرفة اللي المطور ممكن يرجعلها قبل ما يفتح شات أصلًا.
| Channel | Availability | Notes |
|---|---|---|
| Live chat (Kodee, AI) | 24/7 | Accessed via “Ask AI” in hPanel |
| Live chat (human) | Escalation only | Not a direct queue, routed through Kodee |
| Email / ticket | support@hostinger.com | Stated reply window of 1 business day |
| Phone | Not offered | No public phone line for general support |
| Knowledge Base | Self-service | support.hostinger.com |
| Tutorials and Academy | Self-service | Step-by-step guides and a YouTube channel |
بما إن live chat هي القناة اللي Hostinger بتوجه المطورين لها لأي حاجة عاجلة، وهي كمان اللي غالبًا هتتستخدم فعلًا أثناء تصحيح نشر، اختبرتها مباشرة بدل ما أفتح تذكرة إيميل.
فتحت live chat من خلال “Ask AI” في hPanel وسألت Kodee سؤال له إجابة ممكن يغلط فيها: هل حالة build مكتمل على نشر Node.js بتضمن إن التطبيق شغال فعلًا، وفين هلاقي دليل غير كده.
أول رد من Kodee كان محدد وصحيح:
“Completed” عادةً معناها إن مرحلة الـ build خلصت بنجاح؛ لكنها ما بتضمنش إن التطبيق سليم بعد التشغيل. عشان تلتقط start command غلط أو crash وقت runtime، راجع runtime logs: في hPanel روح إلى Websites → Dashboard → Deployments عشان build logs، وبعدها افتح stderr.log بتاع تطبيقك في مجلد nodejs عشان أخطاء startup زي Port already in use أو Module not found.
الإجابة دي وحدها كانت كفيلة تحل نفس الغموض اللي اختبار التعافي من الفشل وقع فيه قبل كده في المراجعة دي. Kodee سمّى ملف log حقيقي، والمجلد الصحيح، وفرق صح بين نجاح الـ build وصحة الـ runtime.
لكن كنت عايز كمان أتأكد إذا كان ممكن أوصل لموظف بشري حقيقي، فقلت لـ Kodee إني عايز أؤكد ده مع support engineer مباشرة.
لكن الوصول لموظف بشري كان أصعب مما توقعت. طلبت بشكل مباشر live agent واتحولت تاني لـ Kodee مرتين، كل مرة بحجة إنه أسرع من الانتظار:
I understand why you’d want that. I can help you verify the build, start command, and runtime logs right here, which is usually the fastest way to pinpoint the issue.
Before we queue a specialist. I can resolve the issue and save you the wait.
| Attempt | My request | Kodee’s response |
|---|---|---|
| 1 | “Can you connect me with a live agent?” | Offered to solve it itself |
| 2 | “I’d still like to speak with a human agent. Please connect me.” | Offered again, asked for domain and start command |
| 3 | Clicked “Go to human” / typed “I want to continue with a human” | Escalated |
استغرق الأمر طلبين مباشرَين وصريحَين قبل ما Kodee يوقف إرجاعي لنفسه. بالنسبة لسؤال أقدر أحله بنفسي، الاحتكاك ده بسيط. لكن لحد بيواجه outage وعايز شخص، ده نقطة إزعاج حقيقية.
اللي حصل بعد كده ما كانش handoff مباشر بالمعنى المعتاد لـ “connect me with a human”. Kodee شرح الموديل الحقيقي بوضوح:
I have shared your request with a specialist from our team who will personally review our chat and send me their answer, which I will then relay back to you here.
ده review غير متزامن، مش transfer مباشر. Kodee بيفضل الواجهة؛ وموظف بشري بيراجع المحادثة في الخلفية وKodee بيرجعلك الإجابة لما توصل. الفرق ده مهم للقارئ اللي بيقرر إذا كان هيصعّد، لأن “human agent” هنا ما معناهاش إن شخص جديد دخل الشات بنفس الوقت زي أنظمة live chat المعتادة.
ضغطت على نفس الخيط التقني أكتر وأنا مستني، وسألت Kodee يؤكد مسار الـ log بالضبط وهل stderr.log بيتملأ دائمًا. أدّى إجابة قوية بنفسه، وقال صح إن الـ log ممكن يبقى فاضي لو التطبيق ما بدأش كامل أو كتب الخطأ في مكان تاني.
مراجعة المتخصص وصلت في حوالي 3 دقائق، ومُنحت داخل الشات لشخص اسمه Mayas، وكانت أدق من إجابة Kodee بدل ما تكررها بس:
domains/[your-domain]/nodejs/stderr.log هو الموقع الصحيح. ومش دايمًا بيتنشأ أو بيتملأ. هتشوف entries هناك فقط لما التطبيق يكتب إلى stderr، زي uncaught exceptions أو unhandled rejections. لو start command غلط والـ process خرج من غير صوت، stderr.log ممكن يكون فاضي أو مش موجود.
Mayas كمان أضاف خطوتين بديلتين Kodee ما ذكرهمش: فحص stdout.log لآخر output قبل الـ crash، والبحث عن غياب سطر تأكيد التشغيل كعلامة إن التطبيق ما اشتغلش من الأساس.
| Check | Result |
|---|---|
| First technical answer accurate | Yes |
| Human escalation available | Yes, but resisted twice before granted |
| Escalation model | Asynchronous review and relay, not live transfer |
| Named responder | Mayas |
| Response time for human review | About 3 minutes |
| Human answer more precise than AI answer | Yes |
قاعدة معرفة Hostinger منظمة حول فئات منتجات كبيرة: Getting Started، وhPanel، وWebsite Builder، وHostinger Horizons، وDomains، وDNS، وFiles Management، وEmail، وMySQL Databases، وWebsite، وVPS، وAgency Hosting Plans، وHostinger Reach، وSSL Certificates، وPHP، وProfile Management، وBilling، وAffiliates and Referrals، وFeatures، وcPanel، وAbout Hostinger.
مفيش ولا فئة من دول مخصصة لـ Hostinger Connector. الطريقة الوحيدة اللي لقيت بيها المقال الصحيح كانت إني أبحث مباشرة عن “Hostinger Connector”، وده رجّع 5 نتائج، معظمها مرتبط بشكل غير مباشر بس، بما فيهم دليل plugin تسويق بالعمولة ومقال عام عن استضافة Node.js.
المقال اللي بيوثّق إعداد Connector فعلًا اسمه “How to Set Up Web Hosting MCP on Local IDEs”، ومصنف تحت Features → General Information.
البحث باسم المنتج التسويقي نفسه لقاه، لكن القارئ اللي بيلف في الفئات أو بيدور على “MCP” من غير ما يعرف branding بتاع Hostinger ممكن يفوته بسهولة، وعدم تطابق اسم التسويق مع اسم التوثيق حاجة تستاهل تعرفها قبل ما تدور.
المقال نفسه قوي بعد ما تلاقيه. آخر تحديث كان قبل 6 أيام من وقت الاختبار، وبيغطي:
آخر نقطة دي كانت مطابقة لحاجة واجهتها مباشرة في الاختبار: Devin Desktop بيتكتشف تلقائيًا، بينما OpenAI Codex محتاج الطريقة اليدوية. المقال جاب التفصيلة دي صح.
أول إجابة من Kodee على سؤال تقني صعب كانت دقيقة ومحددة، وده مش شيء كل مساعد دعم بالـ AI بيعمله. ومقال قاعدة المعرفة اللي بيدعمه حديث ومفصل بعد ما تلاقيه، رغم إن الاسم التسويقي للمنتج واسم التوثيق ما بيتطابقوش، فالبحث هو طريق أوثق من التصفح بين الفئات.
النقطة الأضعف هي مسار التصعيد للبشر. Kodee رجعني لنفسه مرتين قبل ما ينفذ طلب مباشر لحد بشري، وحتى ساعتها “human agent” معناها مراجعة غير متزامنة يتم نقلها عبر نفس الشات بدل transfer مباشر. ولما إنسان راجع الموضوع فعلًا، الإجابة كانت أحسن من إجابة Kodee نفسه، أدق ومعها خطوتين تشخيص إضافيتين Kodee ما قدمهمش.
في أغلب الأسئلة Kodee لوحده هيجيب لك إجابة دقيقة بسرعة. لكن لو فعلاً عايز شخص يراجع الإجابة، استنى إنك تطلب أكتر من مرة، واستنى كمان شوية قبل ما توصلك إجابة منقولة بدل محادثة مباشرة.
أيوه، للمطورين اللي أصلًا بيستضيفوا على Hostinger وعايزين النشر الروتيني يتعمل من المحرر. الإعداد خد دقائق، وOAuth شال أي حاجة تخص API keys، ولما موقع موجود فعلًا بدومين معروف، Connector نشر تحديث حي في حوالي دقيقة ومعاه سجلات تثبّت ده. وإجابات Kodee في الدعم نفسها كانت قوية كفاية تحل مشكلة تقنية حقيقية من أول مرة.
الشرط هنا هو الثقة، مش الراحة. قدام هدف جديد ما قدرش يلاقيه، Connector اخترع دومين وتصرف عليه قبل ما يتحقق.
وكمان علّم نشرًا معطوبًا على إنه “completed” بينما التطبيق كان واقع فعلًا، من غير أي خطأ runtime في سجلاته. استخدمه عشان تسرّع الشغل على المواقع الموجودة أصلًا، وتأكد من أي حاجة يعملها على هدف جديد، وراجع الموقع الحي بنفسك بعد أي نشر يهمك.
| اسم الخطة | مساحة | وحدة المعالجة المركزية | ذاكرة عشوائية | نظام تشغيل | السعر | |
|---|---|---|---|---|---|---|
| Free Trial | غير محدود | - | ج.م. 0 | التفاصيل | ||
| KVM 1 | 50 جيجابايت | 1 مراكز | 4 جيجابايت | ج.م. 290 | التفاصيل | |
| KVM 2 | 100 جيجابايت | 2 مراكز | 8 جيجابايت | ج.م. 400 | التفاصيل | |
| KVM 4 | 200 جيجابايت | 4 مراكز | 16 جيجابايت | ج.م. 570 | التفاصيل | |
| KVM 8 | 400 جيجابايت | 8 مراكز | 32 جيجابايت | ج.م. 1140 | التفاصيل |
| Description | Expert Review |
|---|---|
| استضافة اقتصادية ذات أداء عالٍ وأدوات إدارة سه... | Read Shared Hosting Review |
| استضافة WordPress سريعة وآمنة مع تثبيت بنقرة واحدة ... | Read Wordpress Hosting Review |
| استضافة VPS قابلة للتوسع مع موارد مخصصة ووصول بص... | Read VPS Review |
| استضافة سحابية سريعة ومرنة مع وقت تشغيل ممتاز �... | Read Cloud Hosting Review |
| حلول استضافة آمنة وخاصة مع مواقع مراكز بيانات �... | Read Offshore Hosting Review |
| استضافة بريد إلكتروني آمنة وموثوقة مع ميزات من... | Read Email Hosting Review |
| استضافة بايثون موثوقة مع بيئات مرنة للمطورين. | Read Python Hosting Review |
| استضافة PHP عالية الأداء مع دعم كامل للمواقع وال... | Read PHP Hosting Review |
| استضافة Windows VPS موثوقة مع تحكم كامل وخيارات تخص�... | Read Windows VPS Review |
| استضافة سريعة ومرنة مُصممة لتطبيقات Node.js بأداء... | Read Nodejs Hosting Review |
| استضافة مُحسَّنة لمتاجر WooCommerce بسرعة عالية وتك... | Read Woocommerce Hosting Review |
| استضافة خوادم مخصصة لتجارب لعب Minecraft السلسة | Read Minecraft Server Hosting Review |
| حلول استضافة قابلة للتوسع مع ميزات متقدمة للوك... | Read Agency Hosting Review |
| استضافة سريعة وآمنة مُحسّنة لمواقع التجارة ال�... | Read Magento Hosting Review |
| استضافة عالية الأداء مبنية على لينكس لعمليات م... | Read Linux Hosting Review |
| حلول استضافة جافا قوية لتطبيقات ومشاريع الويب ... | Read Java Hosting Review |
| استضافة مُحسّنة لمواقع التجارة الإلكترونية بأ... | Read Ecommerce Hosting Review |
| استضافة Django موثوقة ذات سرعات عالية وبيئة آمنة. | Read Django Hosting Review |
| استضافة cPanel سهلة الاستخدام مع أداء قوي ودعم مو�... | Read Cpanel Hosting Review |
| استضافة قوية للشركات مع سرعات عالية, أمان, وقاب... | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| استضافة سيرفر SMTP مخصص لتوصيل إيميلات بشكل موثو... | Read SMTP Server Review |
| استضافة سريعة ومُحسّنة ومصممة خصيصًا لتطبيقات... | Read Ruby on Rails Review |
| استضافة مليانة مميزات مع تكامل OpenClaw لبناء وإدا... | Read OpenClaw Review |
| استضافة سريعة وموثوقة بسيرفرات مقرها المملكة �... | Read UK Hosting Review |
| استضافة رخيصة وموثوقة بسيرفرات موجودة في الهن�... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read MCP Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review | |
| Read Express.js Review | |
| Read React Review | |
| Read Nextjs Review |
Hostinger Connector هو تكامل مبني على MCP بيربط بيئات البرمجة بالذكاء الاصطناعي المدعومة مع خدمات Hostinger.
بيخلّي المساعد الذكي يقدر يستدعي أدوات Hostinger المدعومة لمهام تخص المواقع الإلكترونية، النشر، الدومينات، DNS، قواعد البيانات، الإيميل، وموارد VPS.
Connector مش منصة استضافة منفصلة ومش بديل عن hPanel. هو بيوفّر طريقة تانية للتعامل مع موارد Hostinger.
Hostinger حاليًا بيعرض:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger كمان بيقول إن فيه عملاء تانيين متوافقين مع MCP ممكن يكونوا مدعومين. الإعداد وطريقة عمل الأدوات ممكن يختلفوا بين العملاء.
Hostinger Connector مجاني للتثبيت ومشمول مع خطط Hostinger. مفيش اشتراك منفصل لـ Connector في الأسعار المعروضة خلال المراجعة دي. لسه محتاج تدفع مقابل خدمة Hostinger الأساسية، زي استضافة الويب أو الاستضافة السحابية أو VPS.
لا. Hostinger Connector بيستخدم OAuth authentication. أثناء إعداد VS Code، سجلت دخول من خلال flow التفويض المعتمد على المتصفح بتاع Hostinger. أنا ما أنشأتش API key، وما لحقتش token في الـ editor، ولا خزّنت credentials في ملف إعدادات.
لأ. Hostinger بتقول إن استدعاءات Connector API بتتعامل مع الحساب الحي. استخدم موقع تجريبي مخصص، أو دومين، أو VPS لما تتعلم workflow. ما تفترضش إن الـ prompt متحاكى لمجرد إنه بيتبعت من خلال دردشة AI.
أيوه. Hostinger موثق الحدود الافتراضية بتاعة:
– 60 طلب في الدقيقة
– 1,000 طلب في الساعة
Hostinger كمان بيقول إن تفاصيل rate-limit بتتبعت في headers بتاعة الاستجابة.
الحدود دي المفروض تكون كافية للاستخدام العادي التفاعلي. بلاش تعمل طلبات متكررة من غير داعي، خصوصًا لما يكون الرد اللي قبله فيه المعلومة المطلوبة بالفعل.
أيوه. أنا نشرت تطبيق Express.js على Hostinger وبعد كده استخدمت Connector علشان أنشر نسخة محدثة من VS Code. Hostinger اكتشف Express، واختار Node.js 22.x، واستخدم جذر المشروع كدليل الجذر أثناء النشر الأولي من hPanel. وبمجرد ما الموقع بقى موجود كهدف Node.js معترف بيه، النشر المتكرر من خلال Connector اشتغل بنجاح.
مش بالضرورة. في الاختبار المُتحكَّم فيه بتاعي، Hostinger أعلن إن الـ build اكتمل بعد ما غيّرت start script علشان يِشير لملف JavaScript مش موجود. سجلات الـ build اللي تم استرجاعها بيّنت إن تثبيت الاعتمادات تم بنجاح، لكن ما كشفتش فشل التشغيل وقت الـ runtime. دايمًا اتأكد من الموقع الحي أو استدعي health endpoint بعد النشر.
مش بالكامل. Connector ممكن يقلل عدد المرات اللي المطورين بيحتاجوا يسيبوا فيها الـ editor، خصوصًا في عمليات النشر الروتينية ومراجعات الحسابات. hPanel لسه مفيد لإدارة الحسابات بشكل بصري، والإعداد الأولي، والتكوين التفصيلي، والحالات اللي فيها الـ AI مش قادر يكتشف أو يعرض المورد المطلوب بشكل صحيح.
أجب على بعض الأسئلة البسيطة وابحث عن الحل المثالي لك!
بدء البحث في الاستضافة
يقدم HostAdvice.com مراجعات وتقييمات احترافية بخدمات استضافة مواقع الانترنت مستقلة تماما عن أي جهة أو كيان آخر. تقييماتنا عادلة وأمينة وتطبق نفس معايير التقييم على كل المراجعات التي تتم.
يتم استلام تعويض نقدي من الشركات التي نقوم بتقييمها. تعويض الخدمات والمنتجات ليس له تأثير على توجه أو استنتاجات تقييماتنا. ولا تؤثر هذه التعويضات على ترتيبنا لشركات استضافة المواقع المحددة.
تغطي هذه التعويضات تكاليف الإنفاق على المراجعين، شراء الحسابات، والاختبار.
