استضافة OpenHands ذاتيًا على خادم VPS

ما هو OpenHands، وأول خطر يجب فهمه

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

حقيقة واحدة ينبغي أن تحدد إعدادك كله. OpenHands لا يكتفي باقتراح الكود، بل ينفّذه فعليًا، ولكي يفعل ذلك تُركِّب حاوية المتحكم الخاصة به مقبس Docker (socket) الخاص بالمضيف عند /var/run/docker.sock حتى تستطيع إطلاق حاويات بيئة معزولة (sandbox) لكل مهمة. أي شيء يستطيع مخاطبة مقبس Docker يستطيع تشغيل حاوية جديدة تُركِّب نظام ملفات المضيف بأكمله، ما يعني أن الوصول إلى المقبس يعادل صلاحيات root على الآلة فعليًا. لذا عامل خادم OpenHands على أنه خادم ينفّذ كودًا غير موثوق، لأن هذا بالضبط ما يفعله. كل خيار تحصين أدناه ينبع من هذه الحقيقة.

ما تحتاج إليه

تحتاج إلى خادم VPS يعمل بنظام Ubuntu 24.04 مع إصدار حديث من Docker Engine، وما لا يقل عن 4 GB من ذاكرة RAM، ومفتاح API لنموذج لغوي (OpenAI أو Anthropic أو Google)، أو نموذج محلي يقدَّم عبر Ollama على الخادم نفسه. يدعم OpenHands عشرات الخلفيات (backends) للنماذج، فالاختيار لك. وإذا لم يسبق لك إعداد حاويات، فإن أساسيات Docker على خادم VPS ترسي الأساس الذي يفترضه هذا الدليل.

التثبيت باستخدام Docker

يُوزَّع OpenHands في صورتين (images): صورة التطبيق التي تشغّلها، وصورة agent-server التي يسحبها لتشغيل البيئة المعزولة (sandbox) الخاصة بكل مهمة. شغّله على النحو التالي، مع استبدال الوسوم (tags) الحالية بما يرد في وثائق المشروع:

docker run -it --rm --pull=always \
  -e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server \
  -e AGENT_SERVER_IMAGE_TAG=1.26.0-python \
  -e LOG_ALL_EVENTS=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.openhands:/.openhands \
  -p 127.0.0.1:3000:3000 \
  --add-host host.docker.internal:host-gateway \
  --name openhands \
  docker.openhands.dev/openhands/openhands:1.8

تفصيلان يوفّران عليك ساعة من الحيرة. صورة التطبيق وصورة agent-server تحملان عمدًا رقمي إصدار مختلفين، فلا تحاول مطابقتهما: استخدم وسم agent-server الذي تقرنه الوثائق بإصدار تطبيقك. ولاحظ -p 127.0.0.1:3000:3000 بدلًا من -p 3000:3000. هذا التغيير الوحيد هو الفارق بين واجهة ويب لا يصل إليها إلا أنت، وأخرى يصل إليها الإنترنت كله، وهذا موضوع القسم التالي.

أبقِ واجهة الويب بعيدة عن الإنترنت العام

يقدّم OpenHands واجهته على المنفذ 3000. وتلك الواجهة تُشغّل وكيلًا ينفّذ كودًا، فنشرها على الإنترنت يمنح أي شخص يعثر عليها مسارًا عن بُعد إلى عملية تنفّذ أوامر. اربطها بواجهة loopback، كما يفعل أمر التشغيل أعلاه، وصِلها من حاسوبك المحمول عبر نفق SSH:

ssh -L 3000:127.0.0.1:3000 you@your-vps

ثم افتح http://127.0.0.1:3000 على جهازك الخاص. يمر الاتصال عبر جلسة SSH القائمة أصلًا، ولا يستمع أي شيء جديد على الإنترنت العام. ولإعداد أكثر ديمومة، ضعها خلف VPN بدلًا من ذلك. وفي الحالتين، ضع أمام الخادم جدار حماية يرفض كل شيء افتراضيًا حتى لا ينكشف شيء عن طريق الخطأ، وتذكّر أن جدار حماية يغطي IPv4 فقط يترك المنفذ نفسه مفتوحًا عبر IPv6، وهذه هي ثغرة جدار حماية IPv6 التي يقع فيها كثيرون.

اعزل مفتاح النموذج وبيانات اعتماد المستودع

يحتاج OpenHands إلى مفتاح API لنموذجه، وغالبًا إلى رمز (token) لاستنساخ مستودعاتك ودفع التغييرات إليها. كلاهما يستطيع إنفاق المال والتصرف نيابة عنك، فعاملهما معاملة كلمات المرور. احتفظ بهما في ملف بيئة (environment file) لا يقرؤه إلا الحساب الصحيح، ولا تضعهما أبدًا في أمر التشغيل حيث ينتهي بهما المطاف في تاريخ الـshell وفي قائمة العمليات، ولا في ملف داخل مستودع git.

شغّله على خادم يمكنك التخلص منه

بما أن المتحكم يجب أن يحمل مقبس Docker، فلا يمكنك عزل OpenHands عن مضيفه عزلًا تامًا. والحل الواقعي هو حسن اختيار مكان التشغيل: شغّل OpenHands على خادم VPS مخصص لا يحمل أي شيء آخر يهمّك، لا على الخادم الذي يشغّل أيضًا قاعدة بياناتك أو موقعك. خذ لقطة (snapshot) قبل أن تبدأ، وأعد البناء من تلك اللقطة بدلًا من الوثوق بخادم شغّل كودًا من تأليف الوكيل لمدة أسبوع. خادم VPS رخيص وقابل للتخلص منه ومخصص لغرض واحد هو المكان المناسب له.

حصّن الخادم من حوله

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

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

FAQ

هل من الآمن تشغيل OpenHands على خادم؟

يمكن أن يكون كذلك، مع الحرص، لكنه أخطر من تطبيق ويب عادي لأنه يكتب الكود وينفّذه، ولأن المتحكم الخاص به يحمل مقبس Docker الخاص بالمضيف، وهو ما يعادل صلاحيات root على الآلة فعليًا. شغّله على خادم VPS مخصص وقابل للتخلص منه لا يحمل أي شيء آخر ذي قيمة، وأبقِ واجهة الويب الخاصة به على loopback خلف نفق SSH أو VPN، واعزل مفاتيحه، وحصّن الخادم. لا تشغّله بجانب خدماتك المهمة.

لماذا يحتاج OpenHands إلى مقبس Docker؟

يشغّل OpenHands كل مهمة في حاوية بيئة معزولة (sandbox) جديدة، ويطلب من الخدمة الخلفية (daemon) لـDocker على المضيف إنشاء تلك الحاويات عن طريق تركيب /var/run/docker.sock داخل المتحكم الخاص به. وهذا يمنح حاوية المتحكم سيطرة على Docker على المضيف، وهو أمر قوي وخطر في آن، لذا يجب معاملة المضيف نفسه على أنه خادم ينفّذ كودًا غير موثوق.

هل يستطيع OpenHands استخدام نموذج محلي بدلًا من API مدفوعة؟

نعم. يدعم OpenHands النماذج المحلية المقدَّمة عبر Ollama أو vLLM، فتستطيع استضافته ذاتيًا بالكامل من دون أي تكلفة لكل رمز (token) ومن دون أن تغادر أي بيانات خادمك. تحتاج إلى جهاز بذاكرة كافية لنموذج برمجة قدير، وهذه مسألة الحجم نفسها التي يتناولها دليل Ollama.

هل ينبغي أن أشغّل OpenHands على خادمي الرئيسي؟

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