VPS पर Docker Compose के साथ Dify कैसे इंस्टॉल करें

Dify क्या है, और आप इसे चलाने के लिए किस चीज़ के लिए साइन अप कर रहे हैं

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

इसे स्वयं चलाने का अर्थ है कई गतिशील हिस्सों (moving parts) को मैनेज करना। अक्टूबर 2026 तक, Dify का डॉक्यूमेंटेड डिफ़ॉल्ट स्टैक 15 लंबे समय तक चलने वाले कंटेनर्स और एक वन-टाइम टास्क से शुरू होता है जो फ़ाइल अनुमतियों (permissions) को सेट करके बंद हो जाता है। इनमें से सात Dify की अपनी सेवाएं हैं: API सर्वर, वेबसॉकेट सर्वर, बैकग्राउंड वर्कर, शेड्यूलर, वेब फ्रंटएंड, प्लगइन डेमन और एजेंट बैकएंड। बाकी आठ डिपेंडेंसीज़ हैं: एक Postgres डेटाबेस, एक Redis कैश, एक Weaviate वेक्टर डेटाबेस, एक nginx फ्रंट डोर, दो कोड सैंडबॉक्स और दो SSRF प्रॉक्सी। Docker Compose इन सबको आपस में जोड़ता है, लेकिन यह एक वास्तविक स्टैक है, और Dify की डॉक्यूमेंटेड न्यूनतम आवश्यकता 4 GiB RAM और दो CPU कोर है। यदि वह VPS कुछ और भी चलाने वाला है, तो उसे विज्ञापित आंकड़ों के बजाय मापे गए आंकड़ों के आधार पर आकार दें, क्योंकि PhotoPrism और Immich की वास्तविक RAM आवश्यकताएं उनके प्रकाशित न्यूनतम आंकड़ों से काफी अधिक होती हैं, और एक फोटो सर्वर उसी बॉक्स को साझा करते हुए सबसे पहले Dify के डेटाबेस और वेक्टर स्टोर को भूखा कर देगा। CPU का दबाव भी इसी तरह काम करता है: Jellyfin लाइब्रेरी को ब्राउज़ करते समय बहुत कम संसाधन लगते हैं, लेकिन जैसे ही कोई ट्रांसकोडिंग शुरू करता है, Dify का वर्कर उसके पीछे कतार में लग जाता है। राहत की बात यह है कि आप Dify पर चाहे कितने भी ऐप्स बनाएं, कंटेनर्स की संख्या स्थिर रहती है। यह OpenBot की तुलना में बिलिंग के लिहाज से बेहतर है, जहाँ हर AI सहकर्मी को अपना कंटेनर और ब्राउज़र मिलता है और हर नई नियुक्ति के साथ मेमोरी की न्यूनतम आवश्यकता बढ़ जाती है।

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

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

आपको Ubuntu 24.04 पर चलने वाला एक VPS चाहिए जिसमें कम से कम 4 GiB RAM और दो CPU cores हों। साथ ही, Docker और Docker Compose plugin इंस्टॉल होना चाहिए (Dify के लिए Compose 2.24.0 या बाद का वर्शन आवश्यक है)। आपके पास एक ऐसा user होना चाहिए जिसके पास sudo हो या जो docker group का सदस्य हो। नीचे दी गई clone कमांड git, curl और jq का भी उपयोग करती है। यदि आप Docker के लिए नए हैं, तो VPS पर Docker Compose की बुनियादी जानकारी में इंस्टॉलेशन और उन मुख्य कमांड्स को कवर किया गया है जिन्हें यह गाइड आधार मानती है। सर्वर पर पॉइंट किया गया एक domain name होना भी फायदेमंद है, क्योंकि आप bare IP address के बजाय Dify के सामने TLS रखना चाहेंगे।

चरण 1: Dify और उसकी Compose फाइलें प्राप्त करें

Dify अपना Docker सेटअप मुख्य रिपॉजिटरी में रखता है। नवीनतम release को clone करें, development branch को नहीं, और docker डायरेक्टरी में जाएँ:

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

यदि clone "Remote branch null" त्रुटि के साथ विफल हो जाता है, तो इसका मतलब है कि GitHub API lookup ने कुछ भी नहीं लौटाया है; releases पेज से एक version चुनें और उसे मैन्युअल रूप से --branch में पास करें।

.env फाइल मुख्य कॉन्फ़िगरेशन है। कुछ भी शुरू करने से पहले इसे पढ़ें। जो मान सबसे पहले मायने रखते हैं, वे वे हैं जो पासवर्ड और सीक्रेट सेट करते हैं: SECRET_KEY, Postgres पासवर्ड, और Redis पासवर्ड। SECRET_KEY खाली आता है, और यदि आप इसे वैसा ही छोड़ देते हैं, तो Dify एक key जनरेट करता है और उसे अपनी स्टोरेज डायरेक्टरी में रखता है। पासवर्ड का मामला अलग है: उदाहरण फाइल Postgres और Redis दोनों के लिए समान difyai123456 सेट करती है, और कोड सैंडबॉक्स, प्लगइन डेमन, और Weaviate के लिए फिक्स्ड, सार्वजनिक रूप से ज्ञात keys सेट करती है। इन्हें वैसा ही छोड़ देना सबसे आम तरीका है जिससे एक self-hosted Dify breached हो जाता है। यदि आप अपनी खुद की secret key सेट करना चाहते हैं, तो एक जनरेट करें:

openssl rand -base64 42

इसे SECRET_KEY में पेस्ट करें, और फाइल में प्रत्येक पासवर्ड और key फील्ड के लिए एक मजबूत, अद्वितीय मान सेट करें। Redis पासवर्ड CELERY_BROKER_URL के अंदर भी दिखाई देता है, इसलिए उसे वहाँ भी बदलें, अन्यथा worker Redis तक नहीं पहुँच पाएगा।

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

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

docker compose up -d

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

docker compose ps

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

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

ज्यादातर quick installs यहीं रुक जाते हैं और यहीं से अधिकांश incidents शुरू होते हैं। Dify का अपना nginx हर interface पर port 80 पर clear text में listen करता है और port 443 को भी publish करता है। आप नहीं चाहेंगे कि आपका admin login और model keys plain HTTP पर यात्रा करें, और आप यह भी नहीं चाहेंगे कि internal services बाहर से reachable हों।

एक 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 हैं। यह भी ध्यान रखें कि Docker द्वारा publish की गई ports को Docker के अपने firewall rules संभालते हैं, न कि ufw, और default stack plugin daemon के debugging port, 5003, को हर interface पर publish करता है। EXPOSE_PLUGIN_DEBUGGING_PORT को .env में 127.0.0.1:5003 पर सेट करें, जब तक कि आप वास्तव में किसी अन्य machine से plugins को debug न करना चाहते हों।

TLS के लिए, सबसे साफ तरीका यह है कि Dify के web port को loopback पर bind करें और इसके आगे Let's Encrypt certificate के साथ एक reverse proxy चलाएँ, ताकि public internet पर केवल proxy ही HTTPS के जरिए बात करे। Dify का .env आपको exposed port बदलने की सुविधा देता है; इसे 127.0.0.1 पर bind करने के लिए सेट करें और अपने proxy को उस पर point करें। EXPOSE_NGINX_SSL_PORT के लिए भी ऐसा ही करें, क्योंकि Dify का nginx default रूप से host port 443 को claim करता है और आपके proxy को इसकी आवश्यकता होती है। running an AI agent safely on a VPS में दिए गए agent-hardening के विचार यहाँ भी लागू होते हैं: moving parts को loopback पर रखें, केवल वही expose करें जो public होना जरूरी है, और एक hardened front door को TLS पर बात करने दें। जहाँ किसी tool का interface केवल आपके लिए है और उसे कभी भी certificate की आवश्यकता नहीं है, वहाँ proxy को छोड़ दें और इसे SSH tunnel के माध्यम से access करें, जैसे self-hosting the open-kritt security scanner अपने dashboard को loopback पर bind रखता है और उसे publish करने के बजाय आपके laptop पर forward करता है। यदि पूरी टीम को Dify की आवश्यकता है लेकिन public internet को नहीं, तो एक overlay network इस विचार को एक laptop से आगे बढ़ाता है: advertising the server's private subnet to your tailnet हर approved device को private address पर builder तक पहुँचने देता है, जबकि firewall SSH के अलावा बाकी सब के लिए बंद रहता है। यदि आप इस सर्वर को हाथ से चलाने के बजाय किसी coding agent के माध्यम से manage करते हैं, तो उसे keys सौंपने से पहले यह तय कर लें कि वह बिना निगरानी के कितना काम कर सकता है, क्योंकि the permission mode you leave Claude Code in यह तय करता है कि क्या वह .env को rewrite करने या stack को restart करने से पहले आपसे अनुमति लेगा। यदि आप एक session में container logs देख रहे हैं और दूसरे में proxy config edit कर रहे हैं, तो those two sessions can pass text to each other on the same box, जो हर बार stack restart करने पर terminals के बीच output copy करने से बेहतर है।

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

Dify तेजी से विकसित होता है और इसके अपडेट में सुरक्षा सुधार शामिल होते हैं। चूंकि आपने एक release tag को clone किया है, इसलिए अपडेट करने का अर्थ किसी branch को pull करने के बजाय अगले tag को checkout करना है। पहले database का बैकअप लें, फिर docker डायरेक्टरी से यह करें:

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

Database migrations स्टार्टअप पर स्वचालित रूप से चलते हैं और उनमें से कुछ को वापस (reverse) नहीं किया जा सकता है, इसीलिए बैकअप लेना सबसे पहले जरूरी है। हर अपग्रेड से पहले release notes पढ़ें, न कि केवल बड़े अपडेट्स के लिए: Dify का कहना है कि अपग्रेड के चरण releases के बीच भिन्न होते हैं। उदाहरण के लिए, 1.17.1 नोट्स (सितंबर 2026) उन लोगों को सलाह देते हैं जो मौजूदा डेटा के साथ bundled Weaviate चला रहे हैं कि वे सीधे उस वर्ज़न पर न जाएं, बल्कि प्रत्येक minor release के माध्यम से चरण-दर-चरण आगे बढ़ें। Dify releases के बीच .env schema को भी बदलता है, इसलिए नया tag checkout करने के बाद .env.example की तुलना अपने .env से करें और अपने बदलावों को लागू करें, क्योंकि कोई नया variable जिसे आपने सेट नहीं किया है, वह container को शुरू होने से रोक सकता है।

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

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

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

FAQ

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

Dify के लिए कम से कम 4 GiB RAM और दो CPU cores, तथा Docker Compose 2.24.0 या उसके बाद का वर्ज़न आवश्यक है। यह न्यूनतम आवश्यकता डिफ़ॉल्ट स्टैक के आकार पर आधारित है: अक्टूबर 2026 तक, इसमें 15 लंबे समय तक चलने वाले कंटेनर और एक बार का इनिशियलाइज़ेशन टास्क शामिल है। अपने अपलोड किए गए दस्तावेज़ों और वेक्टर इंडेक्स के लिए पर्याप्त डिस्क स्पेस रखें, और यदि सर्वर पर कोई अन्य सर्विस चल रही है तो अधिक मेमोरी का उपयोग करें।

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

नहीं। Dify का बंडल किया गया वेब सर्वर सादे HTTP पर चलता है, और यह आपके एडमिन लॉगिन और मॉडल API कीज़ को संभालता है। इसके सामने Let's Encrypt सर्टिफिकेट वाला एक रिवर्स प्रॉक्सी लगाएँ, Dify के पोर्ट को केवल लूपबैक (loopback) पर बाइंड करें, और केवल HTTPS प्रॉक्सी को इंटरनेट के लिए खुला रखें। इसके साथ एक डिफ़ॉल्ट-डिनाय (default-deny) फायरवॉल का उपयोग करें जो IPv4 और IPv6 दोनों को कवर करे।

मैं self-hosted Dify को अपडेट कैसे करूँ?

डेटाबेस का बैकअप लें, फिर docker डायरेक्टरी से docker compose down चलाएँ, git fetch --tags करें, नए रिलीज़ टैग के साथ git checkout करें, फिर docker compose pull और docker compose up -d चलाएँ। रिलीज़ नोट्स को पहले पढ़ें, क्योंकि अपग्रेड के चरण रिलीज़ के अनुसार अलग-अलग हो सकते हैं, माइग्रेशन अपरिवर्तनीय हो सकते हैं, और Dify कभी-कभी नए .env वेरिएबल्स जोड़ता है, जिन्हें न सेट करने पर कंटेनर स्टार्ट होने में विफल हो सकता है।

Dify इंस्टॉल करने के बाद सबसे पहला काम क्या करना चाहिए?

/install पर जाएँ और तुरंत एडमिन अकाउंट बनाएँ। जब तक वह अकाउंट नहीं बनता, कोई भी व्यक्ति जो पेज तक पहुँच सकता है, उसे क्लेम कर सकता है। जैसे ही कंटेनर हेल्दी हो जाएँ और फायरवॉल को दुनिया के लिए खोलने से पहले, इसे सेट अप कर लें।