Docker Compose کے ذریعے VPS پر Dify کیسے انسٹال کریں
Dify کو 6 کنٹینرز کے ساتھ چلانے کے لیے کم از کم 4 GB RAM درکار ہے۔ بوٹ کرنے سے پہلے .env فائل میں تمام سیکریٹس تبدیل کریں اور کسی اور سے پہلے /install پر ایڈمن اکاؤنٹ بنائیں۔
Dify کیا ہے، اور آپ اسے چلانے کے لیے کن چیزوں کا عہد کر رہے ہیں
Dify بڑے لینگویج ماڈلز (LLMs) پر ایپلی کیشنز بنانے کے لیے ایک self-hostable پلیٹ فارم ہے۔ آپ کو چیٹ ایپس، ایجنٹس، اور retrieval pipelines ڈیزائن کرنے کے لیے ایک ویب انٹرفیس، انہیں اپنے کوڈ سے کال کرنے کے لیے ایک API، اور پرامپٹس، ڈیٹا سیٹس، اور ماڈل کیز کو منظم کرنے کے لیے ایک مرکزی جگہ ملتی ہے۔ یہ اس قسم کا ٹول ہے جسے ایک چھوٹی ٹیم اس لیے سیٹ کرتی ہے تاکہ ہر کوئی ایک مشترکہ نجی بنیاد پر کام کر سکے، بجائے اس کے کہ API کیز کو مختلف اسکرپٹس میں بکھیر دیا جائے۔ اگر agent، tool call، اور retrieval pipeline جیسے الفاظ ابھی بھی مبہم ہیں، تو ان تصورات کو شروع سے سمجھنا Dify کے بلڈر اسکرینز کو غیر واضح سوئچز کی دیوار کے بجائے مانوس کنٹرولز کے طور پر پڑھنے میں مدد دے گا۔
اسے خود چلانے کا مطلب ہے کئی متحرک حصوں کو سنبھالنا۔ Dify Docker containers کے ایک سیٹ کے طور پر آتا ہے: ایک API سرور، ایک background worker، ایک ویب فرنٹ اینڈ، ایک Postgres ڈیٹا بیس، ایک Redis کیش، اور ایک ویکٹر ڈیٹا بیس، جو سب Docker Compose کے ذریعے آپس میں جڑے ہوتے ہیں۔ یہ ایک سنگل بائنری سے زیادہ ہے، لیکن Compose ان کے روابط کو سنبھال لیتا ہے، اور چند گیگا بائٹس RAM والا VPS اسے آسانی سے چلا سکتا ہے۔ اگر وہ VPS کچھ اور بھی چلا رہا ہے، تو اس کا سائز اشتہاری اعداد و شمار کے بجائے پیمائش شدہ نمبروں کی بنیاد پر طے کریں، کیونکہ PhotoPrism اور Immich کی حقیقی RAM کی کم از کم ضرورت ان کے شائع شدہ کم از کم تقاضوں سے کافی زیادہ ہوتی ہے، اور ایک فوٹو سرور جو اسی باکس پر چل رہا ہو، سب سے پہلے Dify کے ڈیٹا بیس اور ویکٹر اسٹور کو متاثر کرے گا۔ CPU کا تنازعہ بھی اسی طرح اثر انداز ہوتا ہے: Jellyfin لائبریری جو 90 کی دہائی کے ویڈیو اسٹور جیسی دکھتی ہے، جب تک صرف آرٹ ورک براؤز کر رہی ہو تو اسے چلانے میں تقریباً کوئی خرچ نہیں آتا، لیکن جیسے ہی کوئی transcode شروع کرتا ہے، Dify کا ورکر اس کے پیچھے قطار میں لگ جاتا ہے۔ تسلی کی بات یہ ہے کہ Dify کے کنٹینرز کی تعداد مقرر رہتی ہے چاہے آپ اس پر کتنی ہی ایپس کیوں نہ بنائیں، جو کہ OpenBot کے مقابلے میں زیادہ مستحکم ہے، جہاں ہر AI ورکر کا اپنا کنٹینر اور اپنا براؤزر ہوتا ہے اور ہر نئی ہائرنگ میموری کی کم از کم حد کو مزید بڑھا دیتی ہے۔
چونکہ Dify آپ کی ماڈل API کیز اور اکثر نجی دستاویزات کو محفوظ رکھتا ہے جو آپ نے retrieval کے لیے لوڈ کی ہوتی ہیں، اس لیے جس باکس پر یہ چل رہا ہو اسے پہلے منٹ سے ہی حساس سمجھیں۔ یہ گائیڈ اسے انسٹال کرتی ہے، اور پھر اسے اسی طرح محفوظ (harden) کرتی ہے جیسے آپ کسی بھی ایسی سروس کو کرتے ہیں جو خفیہ معلومات رکھتی ہو۔
تقاضے
آپ کو Ubuntu 24.04 پر چلنے والا ایک VPS درکار ہے جس میں Docker اور Docker Compose پلگ ان انسٹال ہوں۔ اس کے علاوہ، آپ کے پاس ایسا صارف ہونا چاہیے جس کے پاس sudo کے حقوق ہوں یا وہ docker گروپ کا رکن ہو۔ اگر آپ Docker سے واقف نہیں ہیں، تو VPS پر Docker Compose کی بنیادی باتیں میں انسٹالیشن اور ان بنیادی کمانڈز کا احاطہ کیا گیا ہے جنہیں یہ گائیڈ فرض کرتی ہے۔ سرور کی طرف اشارہ کرنے والا ایک ڈومین نام ہونا بھی فائدہ مند ہے، کیونکہ آپ Dify کے سامنے محض IP ایڈریس کے بجائے TLS استعمال کرنا چاہیں گے۔
مرحلہ 1: Dify اور اس کی Compose فائلیں حاصل کریں
Dify اپنا Docker سیٹ اپ مرکزی repository میں رکھتا ہے۔ اسے clone کریں اور docker ڈائریکٹری میں جائیں:
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env.env فائل مکمل کنفیگریشن پر مشتمل ہے۔ کوئی بھی کام شروع کرنے سے پہلے اسے پڑھ لیں۔ سب سے اہم اقدار وہ ہیں جو پاس ورڈز اور سیکریٹس سیٹ کرتی ہیں: SECRET_KEY، Postgres پاس ورڈ، اور Redis پاس ورڈ۔ مثال کے طور پر دی گئی فائل میں placeholder اقدار موجود ہیں، اور انہیں اسی طرح چھوڑ دینا سب سے عام طریقہ ہے جس سے self-hosted Dify کا سیکیورٹی بریچ ہو سکتا ہے۔ ایک حقیقی secret key جنریٹ کریں:
openssl rand -base64 42اسے SECRET_KEY میں پیسٹ کریں، اور فائل میں موجود ہر پاس ورڈ فیلڈ کے لیے ایک مضبوط اور منفرد ویلیو سیٹ کریں۔
مرحلہ 2: اسے شروع کریں
اسٹیک کو چلائیں:
docker compose up -dپہلی بار چلانے پر یہ کئی images ڈاؤن لوڈ کرتا ہے اور ڈیٹا بیس کو initialize کرتا ہے، لہذا اسے ایک منٹ کا وقت دیں۔ چیک کریں کہ کنٹینرز صحت مند ہیں:
docker compose psہر سروس کو running ظاہر ہونا چاہیے۔ Dify اپنا ویب انٹرفیس بائی ڈیفالٹ پورٹ 80 پر ایک بنڈل nginx کنٹینر کے ذریعے پیش کرتا ہے۔ http://YOUR_SERVER/install پر اپنے پہلے وزٹ پر آپ ایڈمن اکاؤنٹ بنائیں۔ یہ کام فوراً کریں، اس سے پہلے کہ کوئی اور اس پورٹ تک رسائی حاصل کر سکے، کیونکہ جب تک وہ اکاؤنٹ موجود نہیں ہوتا، کوئی بھی شخص جو صفحہ لوڈ کرے گا وہ اس کا دعویٰ کر کے آپ کی انسٹینس کا مالک بن سکتا ہے۔
مرحلہ 3: اسے براہ راست بے نقاب نہ کریں۔ TLS اور فائر وال کا استعمال کریں
یہ وہ مقام ہے جہاں زیادہ تر فوری تنصیبات رک جاتی ہیں اور زیادہ تر حادثات شروع ہوتے ہیں۔ Dify کا اپنا nginx ہر انٹرفیس پر، غیر محفوظ طریقے سے، port 80 پر listen کرتا ہے۔ آپ نہیں چاہیں گے کہ آپ کا ایڈمن لاگ ان اور ماڈل کیز plain HTTP پر سفر کریں، اور آپ یہ بھی نہیں چاہیں گے کہ اندرونی سروسز باہر سے قابل رسائی ہوں۔
سرور کو default-deny فائر وال کے ساتھ محفوظ کریں جو صرف SSH اور ویب ٹریفک کی اجازت دیتی ہو:
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableیاد رکھیں کہ جو فائر وال صرف IPv4 کا احاطہ کرتی ہے وہ IPv6 پر انہی ports کو کھلا چھوڑ سکتی ہے، یہ IPv6 firewall gap ہے جو بہت سے self-hosters کو متاثر کرتا ہے۔ تصدیق کریں کہ دونوں stacks فلٹر شدہ ہیں۔
TLS کے لیے، سب سے صاف طریقہ یہ ہے کہ Dify کی ویب پورٹ کو loopback پر bind کریں اور سامنے Let's Encrypt سرٹیفکیٹ کے ساتھ ایک reverse proxy چلائیں، تاکہ عوامی انٹرنیٹ پر صرف proxy ہی HTTPS کے ذریعے بات کرے۔ Dify کی .env آپ کو بے نقاب پورٹ تبدیل کرنے کی سہولت دیتی ہے؛ اسے 127.0.0.1 پر bind کرنے کے لیے سیٹ کریں اور اپنی proxy کو اس کی طرف پوائنٹ کریں۔ running an AI agent safely on a VPS میں موجود agent-hardening کے خیالات یہاں بھی لاگو ہوتے ہیں: متحرک حصوں کو loopback پر رکھیں، صرف وہی بے نقاب کریں جو عوامی ہونا ضروری ہے، اور ایک مضبوط فرنٹ ڈور کو TLS استعمال کرنے دیں۔ جہاں کسی ٹول کا انٹرفیس صرف آپ کے لیے ہو اور اسے کبھی سرٹیفکیٹ کی ضرورت نہ ہو، تو proxy کو چھوڑ دیں اور اسے SSH tunnel کے ذریعے حاصل کریں، جس طرح self-hosting the open-kritt security scanner اپنے ڈیش بورڈ کو loopback پر bind رکھتا ہے اور اسے پبلش کرنے کے بجائے آپ کے لیپ ٹاپ پر فارورڈ کرتا ہے۔ اگر پوری ٹیم کو Dify کی ضرورت ہو لیکن عوامی انٹرنیٹ کو نہیں، تو ایک overlay network اس آئیڈیا کو ایک لیپ ٹاپ سے آگے بڑھاتا ہے: advertising the server's private subnet to your tailnet ہر منظور شدہ ڈیوائس کو ایک نجی پتے پر بلڈر تک رسائی دیتا ہے جبکہ فائر وال SSH کے علاوہ ہر چیز کے لیے بند رہتی ہے۔ اگر آپ اس باکس کو ہاتھ سے چلانے کے بجائے کسی coding agent کے ذریعے ایڈمنسٹریٹ کرتے ہیں، تو اس سے پہلے کہ آپ اسے چابیاں دیں، یہ طے کر لیں کہ وہ بغیر نگرانی کے کتنا کام کر سکتا ہے، کیونکہ the permission mode you leave Claude Code in یہ فیصلہ کرتا ہے کہ آیا وہ .env کو دوبارہ لکھنے یا اسٹیک کو دوبارہ شروع کرنے سے پہلے آپ سے پوچھے گا یا نہیں۔ اگر آپ ایک سیشن میں کنٹینر لاگز دیکھ رہے ہوں اور دوسرے میں proxy کنفیگریشن ایڈٹ کر رہے ہوں، تو those two sessions can pass text to each other on the same box، جو ہر بار اسٹیک ری اسٹارٹ کرنے پر ٹرمینلز کے درمیان آؤٹ پٹ کاپی کرنے سے بہتر ہے۔
مرحلہ 4: اپ ڈیٹ رکھیں
Dify تیزی سے اپ ڈیٹ ہوتا ہے اور اس کے نئے ورژنز میں سیکیورٹی فکسز شامل ہوتے ہیں۔ اپ ڈیٹ کرنے کا طریقہ یہ ہے کہ docker ڈائریکٹری سے pull کریں اور دوبارہ اسٹارٹ کریں:
git pull
docker compose pull
docker compose up -dمیجر ورژن اپ گریڈ سے پہلے ریلیز نوٹس ضرور پڑھیں، کیونکہ Dify کبھی کبھار ریلیز کے درمیان .env اسکیمہ تبدیل کر دیتا ہے۔ کوئی نیا ویری ایبل جو آپ نے سیٹ نہ کیا ہو، کنٹینر کو اسٹارٹ ہونے سے روک سکتا ہے۔
مرحلہ 5: ان چیزوں کا بیک اپ لیں جنہیں آپ دوبارہ تخلیق نہیں کر سکتے
Dify باکس پر دو چیزیں ناقابلِ تلافی ہیں: Postgres ڈیٹا بیس، جس میں آپ کی ایپس، صارفین اور ترتیبات محفوظ ہوتی ہیں، اور وہ والیوم جو اپ لوڈ کردہ دستاویزات اور ویکٹر انڈیکس کو اسٹور کرتا ہے۔ یہ دونوں docker ڈائریکٹری کے تحت Docker والیومز میں موجود ہوتے ہیں۔ ان کا ایک شیڈول کے مطابق اسنیپ شاٹ لیں، اور اسنیپ شاٹس کو سرور سے باہر کاپی کریں۔ ان اسنیپ شاٹس میں ہر ماڈل کی (key) اور اپ لوڈ کردہ دستاویز ایک ہی فائل میں موجود ہوتی ہے، اس لیے انہیں باکس سے باہر بھیجنے سے پہلے انکرپٹ (encrypt) کریں، اسی وجہ سے کہ Vaultwarden کا بیک اپ ایک مضبوط پاس ورڈ سرور کا کمزور ترین نقطہ ثابت ہو سکتا ہے۔ ماڈل کی API کی (key) دوبارہ جاری کی جا سکتی ہے؛ لیکن وہ ایپ جسے بنانے میں آپ نے ایک ہفتہ صرف کیا ہو، اسے دوبارہ نہیں بنایا جا سکتا۔ یہی منطق کسی بھی ایسے ایجنٹ پر لاگو ہوتی ہے جس کی حالت (state) کو اس مشین سے زیادہ دیر تک قائم رہنا ہو جس پر وہ چل رہا ہے: KiroCrew کو ہمیشہ آن رہنے والے کنٹینر کے طور پر چلانا دراصل اس میموری اور شیڈولز کا اسنیپ شاٹ لینے پر منحصر ہے جو بصورت دیگر اگلے ریبوٹ پر ختم ہو جائیں گے۔
جب آپ چاہتے ہیں کہ آپ کے بنائے ہوئے ایجنٹس آپ کے اپنے ڈیٹا سیٹس سے آگے بڑھ کر لائیو ویب پر تلاش کریں، تو انہیں ایک self-hosted SearXNG انسٹینس کی طرف موڑنا کوئری اسٹریم کو آپ کے کنٹرول کردہ ہارڈویئر پر رکھتا ہے، حالانکہ اسے آن کرنے سے پہلے اس پرامپٹ انجیکشن سرفیس کے بارے میں پڑھنا ضروری ہے جو اس سے کھلتی ہے۔ زیادہ خود مختار، کوڈ چلانے والے ایجنٹ کے لیے، self-hosting Agent Zero دیکھیں، اور VPS پر اپنا AI ایجنٹ بنانا ان سب کی بنیادی معلومات کا احاطہ کرتا ہے۔
FAQ
Dify کو self-host کرنے کے لیے سسٹم کی ضروریات کیا ہیں؟
Dify تقریباً نصف درجن containers پر مشتمل ایک Docker Compose stack کے طور پر چلتا ہے، لہذا کم از کم 2 GB مفت RAM والے VPS کا منصوبہ بنائیں، مثالی طور پر 4 GB، اس کے ساتھ چند CPU cores اور اپنی اپ لوڈ کردہ دستاویزات اور vector index کے لیے کافی disk space درکار ہے۔ میموری کا دباؤ database اور vector store کی وجہ سے ہوتا ہے، نہ کہ خود Dify کی وجہ سے۔
کیا Dify کو براہ راست port 80 پر expose کرنا محفوظ ہے؟
نہیں۔ Dify کا بنڈل شدہ web server سادہ HTTP پر listen کرتا ہے، اور یہ آپ کے admin login اور model API keys کے سامنے ہوتا ہے۔ اس کے سامنے Let's Encrypt سرٹیفکیٹ کے ساتھ ایک reverse proxy لگائیں، Dify کی اپنی port کو loopback پر bind کریں، اور صرف HTTPS proxy کو انٹرنیٹ کے سامنے رہنے دیں۔ اسے ایک default-deny firewall کے ساتھ جوڑیں جو IPv4 اور IPv6 دونوں کا احاطہ کرتی ہو۔
میں self-hosted Dify کو کیسے اپ ڈیٹ کروں؟
docker ڈائریکٹری سے، git pull چلائیں، پھر نئی images حاصل کرنے اور دوبارہ شروع کرنے کے لیے docker compose pull اور docker compose up -d چلائیں۔ پہلے release notes پڑھیں، کیونکہ Dify بعض اوقات ورژنز کے درمیان نئے .env ویری ایبلز شامل کرتا ہے، اور ایک کی کمی container کو چلنے سے روک سکتی ہے۔
Dify انسٹال کرنے کے بعد سب سے پہلا کام کیا کرنا چاہیے؟
/install پر جائیں اور فوری طور پر admin اکاؤنٹ بنائیں۔ جب تک وہ اکاؤنٹ موجود نہیں ہوتا، کوئی بھی شخص جو اس صفحے تک پہنچ سکتا ہے، اس کا دعویٰ کر سکتا ہے۔ جیسے ہی containers صحت مند ہوں، اور اس سے پہلے کہ آپ firewall کو دنیا کے لیے کھولیں، اسے سیٹ اپ کر لیں۔