VPS पर OpenHands कैसे सेटअप करें: पूरी गाइड

OpenHands क्या है, और सबसे पहले समझने योग्य एक जोखिम

OpenHands, जिसे पहले OpenDevin के नाम से जाना जाता था, एक स्वायत्त (autonomous) सॉफ्टवेयर-इंजीनियरिंग एजेंट है। आप इसे सामान्य भाषा में कार्य देते हैं, और यह काम की योजना बनाता है, कोड लिखता है, कमांड चलाता है, आउटपुट पढ़ता है, और कार्य पूरा होने तक पुनरावृत्ति (iterate) करता है। आप इसे Docker के साथ अपने सर्वर पर चलाते हैं और इसे एक भाषा मॉडल (language model) से जोड़ते हैं। एक VPS पर यह एक कोडिंग एजेंट बन जाता है जो आपके न होने पर भी काम करता है।

एक तथ्य को आपके पूरे सेटअप का आधार होना चाहिए। OpenHands केवल कोड का सुझाव नहीं देता, बल्कि उसे चलाता भी है, और ऐसा करने के लिए इसका कंट्रोलर कंटेनर होस्ट Docker सॉकेट को /var/run/docker.sock पर माउंट करता है ताकि यह प्रत्येक कार्य के लिए सैंडबॉक्स कंटेनर बना सके। जो कुछ भी Docker सॉकेट से बात कर सकता है, वह एक नया कंटेनर शुरू कर सकता है जो आपके पूरे होस्ट फाइलसिस्टम को माउंट कर ले, जिसका अर्थ है कि सॉकेट एक्सेस प्रभावी रूप से मशीन पर root एक्सेस के समान है। इसलिए OpenHands बॉक्स को एक ऐसे सर्वर के रूप में देखें जो अविश्वसनीय (untrusted) कोड चलाता है, क्योंकि यह वास्तव में यही करता है। नीचे दिए गए सुरक्षा के हर विकल्प का आधार यही तथ्य है।

आपको क्या चाहिए

आपको Ubuntu 24.04 पर चलने वाला एक VPS चाहिए जिसमें Docker Engine का हालिया संस्करण, कम से कम 4 GB RAM, और एक language model (OpenAI, Anthropic, या Google) के लिए API key हो, या फिर उसी VPS पर Ollama द्वारा संचालित एक local model हो। OpenHands दर्जनों model backends का समर्थन करता है, इसलिए चुनाव आपका है। यदि आपने पहले कभी containers सेटअप नहीं किए हैं, तो VPS पर Docker की बुनियादी बातें उन विषयों को कवर करती हैं जिन्हें यह गाइड आधार मानती है।

Docker के साथ इंस्टॉलेशन

OpenHands दो images के रूप में उपलब्ध है: एक application image जिसे आप run करते हैं, और एक agent-server image जिसे यह प्रत्येक task के sandbox को चलाने के लिए pull करता है। इसे नीचे दिए गए तरीके से run करें, और project के docs से वर्तमान 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 का उपयोग करें जिसे docs आपके app version के साथ सुझाते हैं। और -p 3000:3000 के बजाय -p 127.0.0.1:3000:3000 पर ध्यान दें। यह एक छोटा सा बदलाव ही Web UI को केवल आपके द्वारा एक्सेस किए जाने योग्य या पूरे इंटरनेट के लिए उपलब्ध बनाने के बीच का अंतर है, जिसके बारे में अगला भाग है।

Web UI को public internet से दूर रखें

OpenHands अपना interface port 3000 पर serve करता है। यह interface एक ऐसे agent को संचालित करता है जो code execute करता है, इसलिए इसे internet पर publish करने का अर्थ है किसी भी व्यक्ति को एक ऐसे process तक remote access देना जो commands चला सकता है। इसे loopback पर bind करें, जैसा कि ऊपर दिए गए run command में किया गया है, और अपने laptop से SSH tunnel के माध्यम से इसे access करें:

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

इसके बाद अपनी machine पर http://127.0.0.1:3000 खोलें। यह traffic आपके मौजूदा SSH session के जरिए जाता है, और public internet पर कोई भी नई service listen नहीं करती है। हर agent को port की आवश्यकता नहीं होती: उसी VPS पर Claude Code sessions terminal के माध्यम से एक-दूसरे से संवाद करते हैं, इसलिए आप केवल SSH को ही expose करते हैं। यही loopback-and-tunnel की आदत हर उस agent dashboard के लिए अपनानी चाहिए जिसे आप host करते हैं; tunnel के माध्यम से open-kritt के scanning UI तक पहुँचना भी इसी तरह काम करता है, बस port 5173 पर। अधिक स्थायी setup के लिए, इसे VPN के पीछे रखें। किसी भी स्थिति में, server के सामने default-deny firewall लगाएँ ताकि गलती से कुछ भी expose न हो, और याद रखें कि केवल IPv4 को cover करने वाला firewall IPv6 पर भी वही port खुला छोड़ देता है, जो कि IPv6 firewall gap है और इसमें बहुत से लोग फंस जाते हैं।

Model key और किसी भी repo credentials को अलग रखें

OpenHands को अपने model के लिए एक API key की आवश्यकता होती है, और अक्सर आपके repositories को clone करने और push करने के लिए एक token की भी। दोनों ही पैसे खर्च कर सकते हैं और आपकी ओर से कार्य कर सकते हैं, इसलिए उन्हें passwords की तरह ही सुरक्षित रखें। उन्हें एक environment file में रखें जिसे केवल सही account ही पढ़ सके। उन्हें कभी भी run command में न रखें, क्योंकि वे आपके shell history और process list में दर्ज हो जाते हैं। उन्हें कभी भी git repository के अंदर किसी file में न रखें। यदि आप originals को self-hosted password manager में रखते हैं, तो उस सर्वर को भी सुरक्षित (harden) करें। vault के कमजोर बिंदु उसके encrypted items नहीं, बल्कि उसका admin token और backup file होते हैं, जैसा कि Vaultwarden hardening pass में बताया गया है।

इसे ऐसे सर्वर पर चलाएं जिसे आप हटा सकें

चूंकि controller के पास Docker socket का एक्सेस होना चाहिए, इसलिए आप OpenHands को पूरी तरह से उसके host से अलग (sandbox) नहीं कर सकते। इसका सबसे ईमानदार समाधान placement के जरिए isolation है: OpenHands को एक ऐसे समर्पित VPS पर चलाएं जिसमें आपकी कोई अन्य महत्वपूर्ण जानकारी न हो, न कि उस सर्वर पर जो आपका database या website चलाता है। शुरू करने से पहले एक snapshot लें, और उस सर्वर पर भरोसा करने के बजाय जिसे एक हफ्ते तक agent-authored code चलाने दिया गया हो, snapshot से उसे फिर से बनाएं। एक सस्ता, disposable और single-purpose VPS इसके लिए सबसे उपयुक्त है। OpenHands में सुरक्षा के लिए placement ही एकमात्र विकल्प है, इसलिए यदि आप यह भी नियंत्रित करना चाहते हैं कि रुककर पूछने से पहले agent कितना काम कर सकता है, तो Claude Code के permission modes यह दिखाते हैं कि ऐसे सर्वर पर, जिसे कोई देख नहीं रहा है, दूसरा सुरक्षा स्तर कैसा दिखता है।

सर्वर को सुरक्षित बनाना

बाकी सब मानक सर्वर स्वच्छता (server hygiene) है, और यहाँ यह सामान्य से अधिक महत्वपूर्ण है क्योंकि वर्कलोड सामान्य से अधिक जोखिम भरा है। root के रूप में काम करने के बजाय एक unprivileged admin user बनाएँ, इसके लिए unprivileged user के रूप में services चलाना का पालन करें। SSH को केवल key-based authentication पर ले जाएँ। फिर नीचे दी गई चेकलिस्ट चलाएँ और इसे ऐसी जगह रखें जहाँ आप इसे दोबारा देख सकें।

चलने वाले घटकों (moving parts) को केवल चलाने के बजाय समझने के लिए, अपने VPS पर अपना AI agent बनाना देखें; कम-कोड वाले प्लेटफॉर्म के लिए, Dify को self-host करना एक आसान शुरुआत है।

FAQ

क्या OpenHands को सर्वर पर चलाना सुरक्षित है?

सावधानी बरतने पर यह सुरक्षित हो सकता है, लेकिन यह एक सामान्य वेब ऐप की तुलना में अधिक जोखिम भरा है क्योंकि यह कोड लिखता और चलाता है। इसका कंट्रोलर होस्ट Docker socket को होल्ड करता है, जो प्रभावी रूप से मशीन पर root एक्सेस के समान है। इसे एक समर्पित, डिस्पोजेबल VPS पर चलाएं जिसमें कोई अन्य महत्वपूर्ण डेटा न हो। इसके Web UI को SSH tunnel या VPN के पीछे loopback पर रखें, इसकी keys को अलग-थलग रखें और सर्वर को सुरक्षित (harden) करें। इसे अपनी महत्वपूर्ण सेवाओं के साथ न चलाएं।

OpenHands को Docker socket की आवश्यकता क्यों है?

OpenHands प्रत्येक कार्य को एक नए सैंडबॉक्स कंटेनर में चलाता है। यह होस्ट Docker daemon से उन कंटेनरों को बनाने के लिए कहता है, जिसके लिए यह /var/run/docker.sock को अपने कंट्रोलर में माउंट करता है। यह कंट्रोलर कंटेनर को होस्ट पर Docker का नियंत्रण दे देता है, जो शक्तिशाली और जोखिम भरा है। इसलिए, होस्ट को ऐसा माना जाना चाहिए जो अविश्वसनीय (untrusted) कोड चलाता है।

क्या OpenHands पेड API के बजाय लोकल मॉडल का उपयोग कर सकता है?

हाँ। OpenHands, Ollama या vLLM द्वारा सर्व किए गए लोकल मॉडल का समर्थन करता है। इसलिए आप इसे पूरी तरह से self-hosted चला सकते हैं, जिसमें प्रति-टोकन कोई लागत नहीं आती और कोई भी डेटा आपके सर्वर से बाहर नहीं जाता। आपको एक ऐसी मशीन की आवश्यकता होगी जिसमें एक सक्षम कोडिंग मॉडल के लिए पर्याप्त मेमोरी हो, जो Ollama गाइड में बताए गए साइजिंग प्रश्न के समान है।

क्या मुझे OpenHands को अपने मुख्य सर्वर पर चलाना चाहिए?

नहीं। चूँकि यह एजेंट द्वारा लिखे गए कोड को चलाता है और Docker socket को होल्ड करता है, इसलिए इसे एक अलग, एकल-उद्देश्य वाले VPS पर रखें जिसे आप आवश्यकता पड़ने पर दोबारा बना सकें (rebuild)। इसे डेटाबेस, वेबसाइट या अपनी अन्य सेवाओं के साथ रखने का मतलब है कि एजेंट द्वारा की गई कोई गलती या उसमें मौजूद कोई बग उन चीजों तक पहुँच सकता है जिन्हें उसे कभी नहीं छूना चाहिए था।