VPS वर Docker Compose ने Dify self-host कसे करावे

Dify म्हणजे काय आणि तुम्ही कोणती सेवा चालवण्याची जबाबदारी घेत आहात

Dify हे large language models वर आधारित अॅप्लिकेशन्स तयार करण्यासाठी self-host करता येणारे प्लॅटफॉर्म आहे. यात chat apps, agents आणि retrieval pipelines डिझाइन करण्यासाठी web interface, तुमच्या स्वतःच्या code मधून त्यांना call करण्यासाठी API आणि prompts, datasets व model keys व्यवस्थापित करण्यासाठी एकच ठिकाण मिळते. लहान टीमसाठी हे उपयुक्त साधन आहे. सर्वजण API keys वेगवेगळ्या scripts मध्ये विखुरण्याऐवजी एका shared private base वर काम करू शकतात. agent, tool call आणि retrieval pipeline यांसारख्या संज्ञा अजून स्पष्ट नसतील, तर आधी या संकल्पना सुरुवातीपासून समजून घ्या. त्यामुळे Dify च्या builder screens वरील controls अधिक परिचित वाटतील आणि ते नाव नसलेल्या switches ची भिंत वाटणार नाहीत.

Dify स्वतः चालवणे म्हणजे अनेक घटक चालवणे. Dify हे Docker containers च्या संचाच्या रूपात उपलब्ध होते: API server, background worker, web frontend, Postgres database, Redis cache आणि vector database. हे सर्व Docker Compose वापरून एकमेकांशी जोडलेले असतात. हे single binary पेक्षा अधिक घटकांचे आहे. मात्र Compose ही जोडणी हाताळते. काही gigabytes RAM मोकळी असलेला VPS ते सहज चालवू शकतो. त्याच VPS वर दुसरी सेवाही चालवायची असल्यास, जाहिरात केलेल्या आकड्यांऐवजी मोजलेल्या आकड्यांनुसार क्षमता ठरवा. कारण PhotoPrism आणि Immich ची प्रत्यक्ष RAM आवश्यकता प्रकाशित केलेल्या minimums पेक्षा बरीच जास्त असते. त्याच मशीनवर photo server चालू असल्यास Dify च्या database आणि vector store ला सर्वप्रथम memory कमी पडेल. CPU contention चा परिणामही तसाच होतो. 90s video store सारखा दिसणारा Jellyfin library फक्त artwork browse करत असताना जवळजवळ कोणतीही अतिरिक्त क्षमता वापरत नाही. मात्र कोणी transcode सुरू करताच Dify च्या worker queues ला त्यासाठी प्रतीक्षा करावी लागते. Dify वर कितीही apps तयार केली तरी containers ची संख्या निश्चित राहते. त्यामुळे OpenBot मध्ये प्रत्येक AI coworker साठी स्वतंत्र container आणि स्वतंत्र browser असतात आणि प्रत्येक नवीन coworker मुळे memory requirement पुन्हा वाढते, त्या तुलनेत खर्चाचा वाढीचा नमुना अधिक नियंत्रित राहतो.

Dify मध्ये तुमच्या model API keys आणि अनेकदा retrieval साठी लोड केलेली private documents साठवली जातात. त्यामुळे ते चालणारे machine पहिल्या क्षणापासून sensitive समजा. हे मार्गदर्शक Dify install करते आणि secrets असलेल्या कोणत्याही सेवेप्रमाणे त्याची सुरक्षा मजबूत करते.

पूर्वअट

तुमच्याकडे Docker आणि Docker Compose plugin स्थापित असलेला Ubuntu 24.04 चालणारा VPS असणे आवश्यक आहे. तसेच तुमच्याकडे sudo असणे किंवा docker group चे सदस्यत्व असणे आवश्यक आहे. Docker तुमच्यासाठी नवीन असल्यास, VPS वर Docker Compose ची मूलभूत माहिती या मार्गदर्शकात अपेक्षित असलेली installation प्रक्रिया आणि मुख्य commands स्पष्ट करते. सर्व्हरकडे निर्देश करणारे domain name उपलब्ध असणे उपयुक्त आहे, कारण Dify समोर bare IP address ऐवजी TLS वापरणे अपेक्षित आहे.

पायरी 1: Dify आणि त्याच्या Compose फाइल्स मिळवा

Dify त्याची Docker रचना मुख्य repository मध्ये ठेवते. ते clone करून docker directory मध्ये जा:

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

.env फाइलमध्ये संपूर्ण configuration असते. कोणतीही प्रक्रिया सुरू करण्यापूर्वी ती वाचा. सुरुवातीला महत्त्वाची असलेली मूल्ये passwords आणि secrets सेट करणारी आहेत: SECRET_KEY, Postgres password आणि Redis password. Example file मध्ये placeholder values असतात. त्या values तशाच ठेवल्यास self-hosted Dify breach होण्याची ही सर्वात सामान्य कारणांपैकी एक ठरते. वास्तविक secret key तयार करा:

openssl rand -base64 42

ती SECRET_KEY मध्ये paste करा आणि फाइलमधील प्रत्येक password field साठी मजबूत, अद्वितीय value सेट करा.

पायरी 2: ते सुरू करा

स्टॅक सुरू करा:

docker compose up -d

पहिल्यांदा चालवताना अनेक images pull होतात आणि database initialize केला जातो, त्यामुळे एक मिनिट प्रतीक्षा करा. Containers निरोगी स्थितीत आहेत का ते तपासा:

docker compose ps

प्रत्येक सेवेने running वाचले पाहिजे. Dify आपला web interface port 80 वरील bundled nginx container द्वारे, default configuration मध्ये, उपलब्ध करून देते. http://YOUR_SERVER/install येथे पहिल्यांदा भेट दिल्यावर admin account तयार करा. Port वर इतर कोणताही प्रवेश होण्यापूर्वी हे त्वरित करा. हा account तयार होईपर्यंत page load करणारी कोणतीही व्यक्ती तो claim करून तुमच्या instance ची मालकी घेऊ शकते.

पायरी 3: ते थेट सार्वजनिक करू नका. त्याच्या समोर TLS आणि firewall ठेवा

बहुतेक जलद installations इथे थांबतात आणि बहुतेक incidents इथून सुरू होतात. Dify चे स्वतःचे nginx port 80 वर, plain HTTP मध्ये, प्रत्येक interface वर ऐकते. तुमचे admin login आणि model keys plain HTTP वरून जावेत असे तुम्हाला नको आहे. तसेच internal services बाहेरून उपलब्ध असाव्यात असेही नको आहे.

फक्त SSH आणि web traffic ला परवानगी देणाऱ्या default-deny firewall ने server सुरक्षित करा:

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

लक्षात ठेवा की फक्त IPv4 कव्हर करणारे firewall IPv6 वर तेच ports खुले ठेवू शकते. हा IPv6 firewall gap अनेक self-hosters ना अडचणीत आणतो. दोन्ही stacks वर filtering लागू आहे याची खात्री करा.

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 कल्पना येथेही लागू होतात: बदलणारे घटक loopback वर ठेवा, जे सार्वजनिक असणे आवश्यक आहे तेवढेच expose करा आणि एका hardened front door कडून TLS हाताळू द्या. एखाद्या tool चे interface फक्त तुमच्यासाठी असेल आणि त्याला certificate ची गरज कधीच नसेल, तर proxy वगळा आणि SSH tunnel द्वारे त्याच्यापर्यंत पोहोचा. open-kritt security scanner self-host करणे याच पद्धतीने dashboard loopback वर bind ठेवते आणि ते प्रकाशित करण्याऐवजी तुमच्या laptop कडे forward करते. संपूर्ण team ला Dify आवश्यक असेल पण public internet ची गरज नसेल, तर overlay network ही कल्पना एका laptop पुरती मर्यादित ठेवत नाही: server चे private subnet तुमच्या tailnet वर जाहीर करणे यामुळे प्रत्येक मंजूर device ला private address वरून builder पर्यंत पोहोचता येते आणि firewall SSH व्यतिरिक्त सर्व traffic साठी बंद ठेवता येतो. हा box तुम्ही हाताने न चालवता coding agent द्वारे administer करत असाल, तर त्याला keys देण्यापूर्वी तो unsupervised किती काम करू शकतो हे ठरवा. कारण तुम्ही Claude Code मध्ये ठेवलेला permission mode .env पुन्हा लिहिण्यापूर्वी किंवा stack restart करण्यापूर्वी तो थांबून विचारेल की नाही हे ठरवतो. एका session मध्ये container logs tail करताना दुसऱ्या session मध्ये proxy config संपादित करत असाल, तर ती दोन sessions त्याच box वर एकमेकांना text पाठवू शकतात. त्यामुळे प्रत्येक वेळी stack restart केल्यानंतर terminals मधील output पुन्हा copy करावा लागत नाही.

पायरी 4: ते अद्ययावत ठेवा

Dify मध्ये जलद गतीने बदल होतात आणि अद्यतनांमध्ये सुरक्षा दुरुस्त्या समाविष्ट असतात. docker निर्देशिकेतून pull आणि restart केल्यावर अद्यतन प्रक्रिया पूर्ण होते:

git pull
docker compose pull
docker compose up -d

मुख्य आवृत्तीवर उन्नत करण्यापूर्वी release notes वाचा. कारण Dify कधीकधी releases दरम्यान .env schema बदलते. तुम्ही सेट न केलेला नवीन variable असल्यास container सुरू होणे थांबू शकते.

पायरी 5: पुन्हा निर्माण करता न येणाऱ्या गोष्टींचा बॅकअप घ्या

Dify सर्व्हरवरील दोन गोष्टी बदलता किंवा पुन्हा निर्माण करता येत नाहीत: तुमचे अॅप्स, वापरकर्ते आणि settings साठवणारा Postgres database, तसेच अपलोड केलेली documents आणि vector index साठवणारा volume. दोन्ही docker directory अंतर्गत Docker volumes मध्ये असतात. ठरावीक वेळापत्रकानुसार त्यांचे snapshots घ्या आणि ते snapshots सर्व्हरबाहेरील ठिकाणी कॉपी करा. या snapshots मध्ये प्रत्येक model key आणि अपलोड केलेली document एका file मध्ये असते. त्यामुळे ते सर्व्हरबाहेर पाठवण्यापूर्वी encrypt करा. याचे कारण मजबूत password server मधील कमकुवत दुवा Vaultwarden backup ठरू शकतो याच कारणासारखेच आहे. Model API key पुन्हा जारी करता येते; परंतु तुम्ही एक आठवडा घालवून तयार केलेले app पुन्हा मिळवता येत नाही. हीच बाब अशा कोणत्याही agent ला लागू होते ज्याची state तो चालत असलेल्या machine पेक्षा अधिक काळ टिकणे आवश्यक आहे: KiroCrew ला नेहमी सुरू असलेल्या container म्हणून चालू ठेवणे म्हणजे पुढील reboot वेळी नाहीशा होणारी memory आणि schedules snapshot करणे.

तुम्ही येथे तयार केलेल्या agents ना तुमच्या स्वतःच्या datasets पलीकडे जाऊन live web शोधता यावे असे वाटत असल्यास, त्यांना self-hosted SearXNG instance कडे निर्देशित करणे query stream तुमच्या नियंत्रणातील hardware वर ठेवते. मात्र ते सुरू करण्यापूर्वी निर्माण होणाऱ्या prompt injection surface विषयी माहिती वाचणे उपयुक्त ठरेल. अधिक autonomous आणि code चालवणाऱ्या agent साठी Agent Zero self-host करणे पहा. तसेच VPS वर स्वतःचा AI agent तयार करणे या सर्वांच्या पायाभूत बाबी स्पष्ट करते.

FAQ

Dify self-host करण्यासाठी कोणत्या system requirements आवश्यक आहेत?

Dify सुमारे अर्धा डझन containers असलेल्या Docker Compose stack म्हणून चालते. त्यामुळे किमान 2 GB मोकळ्या RAM असलेला VPS वापरा. शक्य असल्यास 4 GB RAM ठेवा. याशिवाय दोन CPU cores आणि uploaded documents तसेच vector index साठी पुरेशी disk space आवश्यक आहे. Memory pressure 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 चा असू द्या. IPv4 आणि IPv6 दोन्हींना लागू होणाऱ्या default-deny firewall सोबत ही रचना वापरा.

self-hosted Dify कसे update करावे?

docker directory मधून git pull चालवा. त्यानंतर नवीन images fetch करण्यासाठी आणि restart करण्यासाठी docker compose pull आणि docker compose up -d चालवा. प्रथम release notes वाचा. Dify काही वेळा versions दरम्यान नवीन .env variables जोडते. यांपैकी एखादा variable नसल्यास container सुरू होण्यास अपयश येऊ शकते.

Dify install केल्यानंतर सर्वप्रथम काय करावे?

/install वर जा आणि त्वरित admin account तयार करा. तो account तयार होईपर्यंत page वर पोहोचू शकणारी कोणतीही व्यक्ती तो account claim करू शकते. containers healthy होताच आणि firewall इंटरनेटसाठी उघडण्यापूर्वी हे setup पूर्ण करा.