Docker Compose के जरिए VPS पर Dify कैसे इंस्टॉल करें

Dify क्या है, और आप इसे चलाने के लिए किस बात के लिए सहमत हो रहे हैं

Dify लार्ज लैंग्वेज मॉडल्स (LLMs) पर आधारित एप्लिकेशन बनाने के लिए एक self-hostable प्लेटफॉर्म है। इसमें आपको चैट ऐप्स, एजेंट्स और रिट्रीवल पाइपलाइन्स को डिज़ाइन करने के लिए एक वेब इंटरफेस मिलता है, साथ ही अपने कोड से उन्हें कॉल करने के लिए एक API और प्रॉम्प्ट्स, डेटासेट्स तथा मॉडल कीज़ को मैनेज करने के लिए एक केंद्रीय स्थान मिलता है। यह उस तरह का टूल है जिसे एक छोटी टीम इसलिए सेटअप करती है ताकि हर कोई एक साझा प्राइवेट बेस पर काम कर सके, न कि अलग-अलग स्क्रिप्ट्स में API कीज़ बिखरी रहें। यदि 'एजेंट', 'टूल कॉल' और 'रिट्रीवल पाइपलाइन' जैसे शब्द अभी भी स्पष्ट नहीं हैं, तो पहले इन कॉन्सेप्ट्स को शुरू से समझने से Dify की बिल्डर स्क्रीन आपको अनजाने बटनों की दीवार के बजाय परिचित कंट्रोल्स जैसी लगने लगेगी।

इसे स्वयं चलाने का अर्थ है कई घटकों को एक साथ चलाना। Dify कई Docker containers के रूप में release होता है: एक API server, एक background worker, एक web frontend, एक Postgres database, एक Redis cache और एक vector database। Docker Compose इन सभी को आपस में जोड़ता है। यह किसी एक binary से अधिक है, लेकिन Compose यह wiring संभालता है। कुछ gigabytes की अतिरिक्त RAM वाला VPS इसे आसानी से चला सकता है। यदि उसी VPS पर कोई और service भी चलनी है, तो उसका आकार advertised आंकड़ों के बजाय मापे गए आंकड़ों के आधार पर तय करें। इसका कारण यह है कि PhotoPrism और Immich की वास्तविक RAM आवश्यकताएँ उनके प्रकाशित minimums से काफी अधिक होती हैं। उसी host पर photo server चलाने से सबसे पहले Dify का database और vector store उपलब्ध संसाधनों की कमी से प्रभावित होंगे। CPU contention का प्रभाव भी इसी तरह होता है। 90s के video store जैसा बदला गया Jellyfin library केवल artwork browse करते समय लगभग कोई अतिरिक्त संसाधन नहीं लेता। लेकिन जैसे ही कोई transcode शुरू करता है, Dify का worker उसकी queue के पीछे रुक जाता है। इसका लाभ यह है कि आप Dify पर कितने भी apps बनाएँ, उसके containers की संख्या fixed रहती है। इसका resource cost OpenBot की तुलना में अधिक नियंत्रित रहता है, जहाँ हर AI coworker को अपना container और अपना browser मिलता है और हर नया coworker memory की न्यूनतम आवश्यकता फिर बढ़ा देता है।

चूंकि Dify आपकी मॉडल API कीज़ और अक्सर आपके द्वारा रिट्रीवल के लिए लोड किए गए प्राइवेट दस्तावेज़ों को सुरक्षित रखता है, इसलिए जिस सर्वर पर यह चलता है उसे पहले मिनट से ही संवेदनशील मानें। यह गाइड इसे इंस्टॉल करती है, और फिर इसे उसी तरह सुरक्षित (harden) करती है जैसे आप किसी भी ऐसी सर्विस को करेंगे जो सीक्रेट्स रखती है।

आवश्यक शर्तें

आपको Ubuntu 24.04 पर चलने वाला एक VPS चाहिए जिसमें Docker और Docker Compose plugin इंस्टॉल हो, साथ ही एक ऐसा user जिसके पास sudo हो या जो docker group का सदस्य हो। यदि Docker आपके लिए नया है, तो VPS पर Docker Compose की बुनियादी बातें में इंस्टॉलेशन और उन मुख्य commands को कवर किया गया है जिन्हें यह गाइड मानकर चलती है। सर्वर पर पॉइंट किया गया एक domain name होना फायदेमंद है, क्योंकि आप bare IP address के बजाय Dify के सामने TLS रखना चाहेंगे।

Step 1: Dify और उसकी Compose files प्राप्त करें

Dify अपना Docker सेटअप मुख्य repository में रखता है। इसे clone करें और docker directory में जाएँ:

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

.env फ़ाइल पूरी configuration है। कुछ भी शुरू करने से पहले इसे पढ़ें। सबसे महत्वपूर्ण values वे हैं जो passwords और secrets सेट करती हैं: SECRET_KEY, Postgres password, और Redis password। उदाहरण फ़ाइल placeholder values के साथ आती है, और उन्हें वैसा ही छोड़ देना self-hosted Dify के breached होने का सबसे आम कारण है। एक वास्तविक secret key generate करें:

openssl rand -base64 42

इसे SECRET_KEY में पेस्ट करें, और फ़ाइल में प्रत्येक password फ़ील्ड के लिए एक मजबूत और unique value सेट करें।

चरण 2: इसे शुरू करें

स्टैक को चालू करें:

docker compose up -d

पहली बार चलाने पर यह कई images को pull करता है और database को initialize करता है, इसलिए इसे एक मिनट का समय दें। जांचें कि containers healthy हैं या नहीं:

docker compose ps

प्रत्येक service को running दिखाना चाहिए। Dify अपने web interface को डिफ़ॉल्ट रूप से port 80 पर एक bundled nginx container के माध्यम से serve करता है। http://YOUR_SERVER/install पर अपनी पहली विजिट पर आप admin account बनाते हैं। इसे तुरंत करें, इससे पहले कि कोई और उस port तक पहुँच सके, क्योंकि जब तक वह account मौजूद नहीं होता, कोई भी व्यक्ति जो page load करता है, वह उस पर दावा कर सकता है और आपकी instance का मालिक बन सकता है।

चरण 3: इसे सीधे expose न करें। इसके सामने TLS और firewall लगाएँ

यहीं पर अधिकांश त्वरित इंस्टॉलेशन रुक जाते हैं और अधिकांश सुरक्षा घटनाएँ शुरू होती हैं। Dify का अपना nginx हर interface पर, बिना किसी सुरक्षा के, port 80 पर listen करता है। आप नहीं चाहेंगे कि आपका admin login और model keys plain HTTP पर जाएँ, और आप यह भी नहीं चाहेंगे कि internal services बाहर से सुलभ हों।

एक default-deny firewall के साथ सर्वर को सुरक्षित करें जो केवल SSH और web traffic की अनुमति देता है:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

याद रखें कि जो firewall केवल IPv4 को कवर करता है, वह IPv6 पर भी वही ports खुले छोड़ सकता है, यह IPv6 firewall gap है जो कई self-hosters को फँसा लेता है। सुनिश्चित करें कि दोनों stacks filtered हैं।

TLS के लिए सबसे साफ तरीका यह है कि Dify के web port को loopback पर bind करें और सामने Let’s Encrypt certificate वाला reverse proxy चलाएँ। इससे public internet पर HTTPS बोलने वाला केवल proxy ही उपलब्ध रहेगा। Dify का .env exposed port बदलने देता है; इसे 127.0.0.1 पर bind करने के लिए सेट करें और proxy को उसी पते पर भेजें। VPS पर AI agent को सुरक्षित तरीके से चलाना में दिए गए agent-hardening विचार यहाँ भी लागू होते हैं: सभी बदलने वाले components को loopback पर रखें, केवल आवश्यक चीजों को public expose करें और एक hardened front door से TLS संभालें। यदि किसी tool का interface केवल आपके लिए है और उसे certificate की बिल्कुल जरूरत नहीं है, तो proxy को छोड़कर SSH tunnel से access करें। open-kritt security scanner को self-host करना भी इसी तरह अपने dashboard को loopback पर bind रखता है और उसे publish करने के बजाय आपके laptop पर forward करता है। यदि पूरी team को Dify चाहिए, लेकिन public internet से access नहीं चाहिए, तो overlay network इस विचार को एक laptop से आगे scale करता है: अपने server के private subnet को tailnet पर advertise करना हर approved device को private address पर builder तक पहुँचने देता है, जबकि firewall SSH के अलावा सभी connections के लिए बंद रहता है। यदि आप इस box को हाथ से नहीं, बल्कि coding agent के माध्यम से administer करते हैं, तो उसे keys देने से पहले तय करें कि वह बिना supervision के कितना काम कर सकता है। Claude Code में छोड़ा गया permission mode यह निर्धारित करता है कि .env को rewrite करने या stack restart करने से पहले वह अनुमति माँगने के लिए रुकेगा या नहीं। यदि एक session container logs को tail कर रहा हो और दूसरा proxy config edit कर रहा हो, तो वे दोनों sessions एक ही box पर एक-दूसरे को text भेज सकते हैं। इससे हर बार stack restart करने पर output को terminals के बीच copy करने की जरूरत नहीं पड़ती।

चरण 4: इसे पैच करते रहें

Dify तेजी से विकसित होता है, और अपडेट में सुरक्षा सुधार शामिल होते हैं। अपडेट करने के लिए docker डायरेक्टरी से pull और restart करना होता है:

git pull
docker compose pull
docker compose up -d

किसी बड़े version jump से पहले release notes पढ़ें, क्योंकि Dify कभी-कभी releases के बीच .env schema में बदलाव करता है, और कोई नया variable जिसे आपने सेट नहीं किया है, वह container को start होने से रोक सकता है।

चरण 5: जिसे आप दोबारा नहीं बना सकते उसका बैकअप लें

Dify बॉक्स पर दो चीजें ऐसी हैं जिन्हें बदला नहीं जा सकता: Postgres डेटाबेस, जिसमें आपके ऐप्स, उपयोगकर्ता और सेटिंग्स होती हैं, और वह वॉल्यूम जिसमें अपलोड किए गए दस्तावेज़ और वेक्टर इंडेक्स स्टोर होते हैं। ये दोनों docker डायरेक्टरी के अंतर्गत Docker वॉल्यूम में रहते हैं। इनका एक निश्चित समय पर स्नैपशॉट लें और स्नैपशॉट की प्रतियां सर्वर से बाहर कहीं और सुरक्षित रखें। उन स्नैपशॉट्स में हर मॉडल की और अपलोड किया गया दस्तावेज़ एक ही फाइल में होता है, इसलिए उन्हें सर्वर से बाहर भेजने से पहले एन्क्रिप्ट करें। इसका कारण वही है जो Vaultwarden बैकअप के एक सुरक्षित पासवर्ड सर्वर का कमजोर बिंदु बन जाने के मामले में होता है। एक मॉडल API की को दोबारा जारी किया जा सकता है, लेकिन जिस ऐप को बनाने में आपने एक हफ्ता लगाया है, उसे नहीं। यही तर्क किसी भी ऐसे एजेंट पर लागू होता है जिसकी स्थिति (state) को उस मशीन से अधिक समय तक जीवित रहना है जिस पर वह चल रहा है: KiroCrew को हमेशा चलने वाले कंटेनर के रूप में बनाए रखना उस मेमोरी और शेड्यूल का स्नैपशॉट लेने पर निर्भर करता है जो अन्यथा अगले रीबूट पर गायब हो जाएंगे।

जब आप चाहते हैं कि आपके द्वारा बनाए गए एजेंट आपके अपने डेटासेट से आगे बढ़कर लाइव वेब पर खोज करें, तो उन्हें एक self-hosted SearXNG इंस्टेंस की ओर निर्देशित करना क्वेरी स्ट्रीम को आपके नियंत्रण वाले हार्डवेयर पर रखता है। हालांकि, इसे चालू करने से पहले प्रॉम्प्ट इंजेक्शन के खतरों के बारे में पढ़ लेना उचित है। अधिक स्वायत्त और कोड चलाने वाले एजेंट के लिए, self-hosting Agent Zero देखें, और VPS पर अपना खुद का AI एजेंट बनाना उन सभी के आधारभूत सिद्धांतों को कवर करता है।

FAQ

Dify को self-host करने के लिए सिस्टम आवश्यकताएं क्या हैं?

Dify लगभग आधा दर्जन containers के एक Docker Compose stack के रूप में चलता है। इसलिए, कम से कम 2 GB RAM (आदर्श रूप से 4 GB), कुछ CPU cores और आपके द्वारा अपलोड किए गए documents तथा vector index के लिए पर्याप्त disk space वाले VPS की योजना बनाएं। Memory का दबाव Dify से नहीं, बल्कि database और vector store से आता है।

क्या Dify को सीधे port 80 पर expose करना सुरक्षित है?

नहीं। Dify का bundled web server plain HTTP पर listen करता है, और यह आपके admin login तथा model API keys को संभालता है। इसके सामने Let's Encrypt certificate वाला एक reverse proxy रखें, Dify के port को loopback पर bind करें, और केवल HTTPS proxy को ही internet के सामने रखें। इसके साथ एक default-deny firewall का उपयोग करें जो IPv4 और IPv6 दोनों को कवर करे।

मैं self-hosted Dify को update कैसे करूँ?

docker directory से, git pull चलाएं, फिर नए images को fetch करने और restart करने के लिए docker compose pull और docker compose up -d का उपयोग करें। पहले release notes पढ़ें, क्योंकि Dify कभी-कभी versions के बीच नए .env variables जोड़ता है, और एक भी missing variable होने पर container start होने से रुक सकता है।

Dify install करने के बाद सबसे पहला काम क्या करना चाहिए?

/install पर जाएं और तुरंत admin account बनाएं। जब तक वह account नहीं बनता, कोई भी व्यक्ति जो उस page तक पहुंच सकता है, उसे claim कर सकता है। जैसे ही containers healthy हो जाएं और firewall को दुनिया के लिए खोलने से पहले, इसे set up कर लें।