VPS پر OpenHands کو خود سے ہوسٹ کرنے کا طریقہ

OpenHands کیا ہے، اور وہ ایک خطرہ جسے پہلے سمجھنا ضروری ہے

OpenHands، جسے پہلے OpenDevin کہا جاتا تھا، ایک خود مختار سافٹ ویئر انجینئرنگ ایجنٹ ہے۔ آپ اسے سادہ زبان میں کام دیتے ہیں، اور یہ اس کام کی منصوبہ بندی کرتا ہے، کوڈ لکھتا ہے، کمانڈز چلاتا ہے، آؤٹ پٹ پڑھتا ہے، اور تب تک کام جاری رکھتا ہے جب تک ٹاسک مکمل نہ ہو جائے۔ آپ اسے Docker کے ساتھ اپنے سرور پر چلاتے ہیں اور اسے ایک لینگویج ماڈل سے منسلک کرتے ہیں۔ ایک VPS پر یہ ایک ایسا کوڈنگ ایجنٹ بن جاتا ہے جو آپ کی غیر موجودگی میں بھی کام کرتا ہے۔

ایک حقیقت آپ کے پورے سیٹ اپ کی بنیاد ہونی چاہیے۔ OpenHands صرف کوڈ تجویز نہیں کرتا، بلکہ اسے چلاتا بھی ہے، اور ایسا کرنے کے لیے اس کا کنٹرولر کنٹینر host Docker socket کو /var/run/docker.sock پر ماؤنٹ کرتا ہے تاکہ وہ ہر ٹاسک کے لیے سینڈ باکس کنٹینرز بنا سکے۔ جو بھی Docker socket تک رسائی حاصل کر سکتا ہے، وہ ایک نیا کنٹینر شروع کر سکتا ہے جو آپ کے پورے host فائل سسٹم کو ماؤنٹ کر لے، جس کا مطلب ہے کہ socket تک رسائی کا مطلب عملی طور پر مشین پر root کی رسائی ہے۔ لہذا OpenHands باکس کو ایک ایسے سرور کے طور پر دیکھیں جو غیر محفوظ (untrusted) کوڈ چلاتا ہے، کیونکہ یہ بالکل وہی کام کرتا ہے۔ نیچے دی گئی ہر حفاظتی تدبیر اسی حقیقت کے پیش نظر ہے۔

آپ کو کن چیزوں کی ضرورت ہے

آپ کو Ubuntu 24.04 پر چلنے والا ایک VPS درکار ہے جس میں Docker Engine کا حالیہ ورژن، کم از کم 4 GB RAM، اور کسی لینگویج ماڈل (OpenAI، Anthropic، یا Google) کی API key موجود ہو۔ متبادل کے طور پر، آپ اسی VPS پر Ollama کے ذریعے چلایا جانے والا لوکل ماڈل بھی استعمال کر سکتے ہیں۔ OpenHands درجنوں ماڈل بیک اینڈز کو سپورٹ کرتا ہے، لہذا انتخاب آپ کا ہے۔ اگر آپ نے پہلے کبھی کنٹینرز سیٹ اپ نہیں کیے ہیں، تو VPS پر Docker کی بنیادی باتیں ان تمام ضروری معلومات کا احاطہ کرتی ہیں جنہیں یہ گائیڈ فرض کرتی ہے۔

Docker کے ساتھ تنصیب

OpenHands دو images کی صورت میں فراہم کیا جاتا ہے: ایک application image جسے آپ چلاتے ہیں، اور ایک agent-server image جسے یہ ہر task کے sandbox کو چلانے کے لیے pull کرتا ہے۔ اسے درج ذیل طریقے سے چلائیں، اور پروجیکٹ کی دستاویزات سے موجودہ 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

دو تفصیلات آپ کا ایک گھنٹہ ضائع ہونے سے بچا سکتی ہیں۔ App image اور agent-server image کے version numbers جان بوجھ کر مختلف رکھے گئے ہیں، لہذا انہیں ایک جیسا کرنے کی کوشش نہ کریں: وہی agent-server tag استعمال کریں جسے دستاویزات میں آپ کے app version کے ساتھ جوڑا گیا ہے۔ اور -p 127.0.0.1:3000:3000 پر توجہ دیں، نہ کہ -p 3000:3000 پر۔ یہ ایک معمولی تبدیلی اس Web UI کے درمیان فرق ہے جس تک صرف آپ رسائی حاصل کر سکتے ہیں اور اس کے درمیان جسے پورا انٹرنیٹ دیکھ سکتا ہے، جس کے بارے میں اگلا سیکشن ہے۔

Web UI کو عوامی انٹرنیٹ سے دور رکھیں

OpenHands اپنا انٹرفیس port 3000 پر پیش کرتا ہے۔ یہ انٹرفیس ایک ایسے ایجنٹ کو کنٹرول کرتا ہے جو کوڈ چلاتا ہے، لہذا اسے انٹرنیٹ پر عام کرنے کا مطلب ہے کہ اسے تلاش کرنے والا کوئی بھی شخص ایک ایسے عمل (process) تک ریموٹ رسائی حاصل کر لے گا جو کمانڈز پر عمل درآمد کرتا ہے۔ اسے loopback پر bind کریں، جیسا کہ اوپر دی گئی run کمانڈ کرتی ہے، اور اپنے لیپ ٹاپ سے SSH tunnel کے ذریعے اس تک رسائی حاصل کریں:

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

پھر اپنی مشین پر http://127.0.0.1:3000 کھولیں۔ ٹریفک آپ کے موجودہ SSH سیشن کے ذریعے گزرتی ہے، اور عوامی انٹرنیٹ پر کوئی نئی چیز listen نہیں کر رہی ہوتی۔ ہر ایجنٹ کو port کی ضرورت نہیں ہوتی: اسی VPS پر Claude Code سیشنز ایک دوسرے کو ٹرمینل کے ذریعے پیغام بھیجتے ہیں، لہذا آپ صرف SSH کو ہی expose کرتے ہیں۔ loopback-and-tunnel کی یہی عادت ہر اس ایجنٹ ڈیش بورڈ کے لیے اپنائیں جسے آپ ہوسٹ کرتے ہیں؛ tunnel کے ذریعے open-kritt کے اسکیننگ UI تک رسائی بھی اسی طرح کام کرتی ہے، بس port 5173 پر۔ زیادہ مستقل سیٹ اپ کے لیے، اسے VPN کے پیچھے رکھیں۔ بہرصورت، باکس کے سامنے default-deny فائر وال لگائیں تاکہ غلطی سے کچھ بھی expose نہ ہو، اور یاد رکھیں کہ صرف IPv4 کو کور کرنے والی فائر وال IPv6 پر بھی وہی port کھلا چھوڑ دیتی ہے، جو کہ IPv6 فائر وال کا خلا ہے جس میں بہت سے لوگ پھنس جاتے ہیں۔

ماڈل کی (model key) اور ریپو کریڈینشلز کو الگ تھلگ کریں

OpenHands کو اپنے ماڈل کے لیے ایک API key کی ضرورت ہوتی ہے، اور اکثر آپ کے repositories کو clone اور push کرنے کے لیے ایک ٹوکن درکار ہوتا ہے۔ یہ دونوں چیزیں آپ کے پیسے خرچ کر سکتی ہیں اور آپ کی شناخت استعمال کر سکتی ہیں، لہذا ان کے ساتھ پاس ورڈ جیسا برتاؤ کریں۔ انہیں ایک ایسی environment file میں رکھیں جسے صرف متعلقہ اکاؤنٹ ہی پڑھ سکے، انہیں کبھی بھی run command میں نہ لکھیں کیونکہ وہ آپ کی shell history اور process list میں محفوظ ہو جاتے ہیں، اور انہیں کبھی بھی git repository کے اندر موجود کسی فائل میں نہ رکھیں۔ اگر آپ اصل کیز کو کسی self-hosted password manager میں رکھتے ہیں، تو اس سرور کو بھی محفوظ بنائیں، کیونکہ vault کے کمزور پوائنٹس اس کا admin token اور اس کی backup file ہوتے ہیں، نہ کہ خود encrypted آئٹمز، جیسا کہ Vaultwarden hardening pass میں وضاحت کی گئی ہے۔

اسے ایسے سرور پر چلائیں جسے ضائع کیا جا سکے

چونکہ controller کے پاس Docker socket کا ہونا ضروری ہے، اس لیے آپ OpenHands کو اس کے host سے مکمل طور پر sandbox نہیں کر سکتے۔ اس کا ایماندارانہ حل یہ ہے کہ اسے الگ تھلگ رکھا جائے: OpenHands کو ایک ایسے مخصوص VPS پر چلائیں جس پر کوئی اور اہم ڈیٹا موجود نہ ہو، نہ کہ اس سرور پر جہاں آپ کا database یا website چل رہی ہو۔ شروع کرنے سے پہلے ایک snapshot لیں، اور ایک ہفتے تک agent کے لکھے ہوئے code کو چلانے والے سرور پر بھروسہ کرنے کے بجائے اسی snapshot سے سسٹم کو دوبارہ تعمیر کریں۔ ایک سستا، عارضی اور مخصوص مقصد کے لیے استعمال ہونے والا VPS اس کے لیے بہترین جگہ ہے۔ اس معاملے میں placement ہی واحد طریقہ ہے جو OpenHands آپ کو فراہم کرتا ہے، لہذا اگر آپ یہ بھی کنٹرول کرنا چاہتے ہیں کہ agent رک کر پوچھنے سے پہلے کتنا کام کر سکتا ہے، تو Claude Code کے permission modes یہ دکھاتے ہیں کہ ایسے سرور پر جہاں کوئی نگرانی نہ ہو، وہاں یہ دوسرا کنٹرول کس طرح کام کرتا ہے۔

سرور کو محفوظ بنانا

باقی تمام اقدامات معیاری سرور ہائیجین (server hygiene) کا حصہ ہیں، اور یہاں ان کی اہمیت معمول سے زیادہ ہے کیونکہ ورک لوڈ (workload) عام حالات سے زیادہ پرخطر ہے۔ root صارف کے طور پر کام کرنے کے بجائے ایک غیر مراعات یافتہ (unprivileged) ایڈمن صارف بنائیں، اس کے لیے غیر مراعات یافتہ صارف کے طور پر سروسز چلانے کے رہنما خطوط پر عمل کریں۔ SSH کو صرف key-based authentication پر منتقل کریں۔ اس کے بعد نیچے دی گئی چیک لسٹ پر عمل کریں اور اسے ایسی جگہ محفوظ رکھیں جہاں آپ اسے دوبارہ دیکھ سکیں۔

متحرک حصوں کو سمجھنے کے لیے، صرف انہیں چلانے کے بجائے، اپنا AI ایجنٹ VPS پر بنانے کا مطالعہ کریں؛ اگر آپ کم کوڈنگ والا پلیٹ فارم چاہتے ہیں تو Dify کو خود ہوسٹ کرنا ایک آسان شروعات ہو سکتی ہے۔

FAQ

کیا OpenHands کو سرور پر چلانا محفوظ ہے؟

احتیاط کے ساتھ یہ محفوظ ہو سکتا ہے، لیکن یہ ایک عام ویب ایپ سے زیادہ پرخطر ہے کیونکہ یہ کوڈ لکھتا اور چلاتا ہے، اور اس کا کنٹرولر host Docker socket تک رسائی رکھتا ہے، جو درحقیقت مشین پر root کے برابر ہے۔ اسے ایک مخصوص اور عارضی VPS پر چلائیں جس میں کوئی دوسری قیمتی چیز نہ ہو، اس کے Web UI کو SSH tunnel یا VPN کے پیچھے loopback پر رکھیں، اس کی keys کو الگ تھلگ رکھیں، اور سرور کو سخت (harden) بنائیں۔ اسے اپنی اہم سروسز کے ساتھ نہ چلائیں۔

OpenHands کو Docker socket کی ضرورت کیوں ہے؟

OpenHands ہر ٹاسک کو ایک نئے sandbox container میں چلاتا ہے، اور یہ host Docker daemon سے درخواست کرتا ہے کہ وہ /var/run/docker.sock کو اپنے کنٹرولر میں mount کر کے ان containers کو بنائے۔ یہ کنٹرولر container کو host پر Docker کا اختیار دیتا ہے، جو کہ طاقتور اور پرخطر ہے، لہذا host کو خود ایسی مشین سمجھا جانا چاہیے جو غیر معتبر (untrusted) کوڈ چلاتی ہے۔

کیا OpenHands ادا شدہ API کے بجائے مقامی ماڈل استعمال کر سکتا ہے؟

جی ہاں۔ OpenHands Ollama یا vLLM کے ذریعے فراہم کردہ مقامی ماڈلز کو سپورٹ کرتا ہے، لہذا آپ اسے مکمل طور پر self-hosted چلا سکتے ہیں جس میں فی ٹوکن کوئی قیمت نہیں ہے اور کوئی ڈیٹا آپ کے سرور سے باہر نہیں جاتا۔ آپ کو ایک ایسی مشین کی ضرورت ہے جس میں ایک قابلِ عمل کوڈنگ ماڈل کے لیے کافی میموری ہو، جو کہ وہی سائزنگ کا سوال ہے جس کا احاطہ Ollama گائیڈ میں کیا گیا ہے۔

کیا مجھے OpenHands اپنے مرکزی سرور پر چلانا چاہیے؟

نہیں۔ چونکہ یہ ایجنٹ کا لکھا ہوا کوڈ چلاتا ہے اور Docker socket تک رسائی رکھتا ہے، اس لیے اسے ایک الگ، مخصوص مقصد کے VPS پر رکھیں جسے آپ دوبارہ تعمیر (rebuild) کرنے کے لیے تیار ہوں۔ اسے ڈیٹا بیس، ویب سائٹ، یا اپنی دیگر سروسز کے ساتھ رکھنے کا مطلب یہ ہے کہ ایجنٹ کی کوئی غلطی، یا اس میں موجود کوئی بگ، ان چیزوں تک پہنچ سکتا ہے جنہیں اسے کبھی چھونا نہیں چاہیے تھا۔