آموزش نصب و راه اندازی Dify روی سرور با Docker Compose
برای اجرای Dify با 6 کانتینر به حداقل 4 GB رم نیاز دارید. پیش از اجرای دستور docker-compose up تمام مقادیر فایل .env را تغییر دهید و بلافاصله در مسیر /install اکانت ادمین بسازید.
Dify چیست و برای اجرای چه چیزی ثبتنام میکنید
Dify یک پلتفرم با قابلیت self-hosting برای ساخت برنامهها بر پایه مدلهای زبانی بزرگ (LLM) است. شما یک رابط وب برای طراحی برنامههای چت، عاملها (agents) و خطلولههای بازیابی (retrieval pipelines)، یک API برای فراخوانی آنها از کد خودتان، و یک مکان واحد برای مدیریت پرامپتها، مجموعهدادهها و کلیدهای مدل در اختیار دارید. این ابزاری است که یک تیم کوچک برای ایجاد یک بستر مشترک و خصوصی راهاندازی میکند تا همه بر روی آن کار کنند، نه اینکه کلیدهای API را در اسکریپتهای مختلف پراکنده کنند.
اجرای آن بهصورت مستقل یعنی مدیریت چندین جزء مرتبط. Dify بهصورت مجموعهای از containerهای Docker عرضه میشود: یک سرور API، یک worker پسزمینه، یک frontend وب، یک پایگاهداده Postgres، یک cache از نوع Redis و یک پایگاهداده برداری که همگی با Docker Compose به یکدیگر متصل شدهاند. این ساختار بیش از یک binary منفرد است، اما Compose اتصال اجزا را مدیریت میکند و یک VPS با چند گیگابایت RAM آزاد، آن را بهراحتی اجرا میکند. اگر قرار است همان VPS سرویس دیگری را نیز اجرا کند، اندازه آن را بر اساس اعداد اندازهگیریشده تعیین کنید، نه اعداد اعلامشده؛ زیرا حداقل RAM واقعی PhotoPrism و Immich بسیار بیشتر از حداقلهای منتشرشده آنهاست و یک photo server که روی همان سیستم اجرا میشود، ابتدا منابع database و vector store مربوط به Dify را تمام میکند. فشار رقابت روی CPU نیز به همین شکل اثر میگذارد: یک library در Jellyfin که ظاهر یک فروشگاه ویدئویی دهه 90 را دارد هنگام مرور artwork تقریباً هیچ هزینهای برای سرویسدهی ندارد، اما بهمحض آنکه کاربری transcode را شروع کند، queueهای worker مربوط به Dify پشت آن قرار میگیرند. نکته مثبت این است که تعداد containerهای Dify، صرفنظر از تعداد appهایی که با آن میسازید، ثابت میماند؛ بنابراین هزینه آن روند ملایمتری دارد نسبت به OpenBot که برای هر همکار AI یک container و یک browser جداگانه ایجاد میکند و هر نیروی جدید دوباره حداقل RAM موردنیاز را افزایش میدهد.
از آنجا که Dify کلیدهای API مدل شما و اغلب اسناد خصوصی که برای بازیابی بارگذاری کردهاید را نگهداری میکند، از همان دقیقه اول با سروری که آن را اجرا میکند به عنوان یک سیستم حساس برخورد کنید. این راهنما ابتدا آن را نصب میکند و سپس آن را به همان شیوهای که هر سرویس دارای اطلاعات محرمانه را ایمن میکنید، مقاومسازی (harden) میکند.
پیشنیازها
شما به یک VPS با سیستمعامل Ubuntu 24.04 نیاز دارید که Docker و افزونه Docker Compose روی آن نصب شده باشد. همچنین باید کاربری با دسترسی sudo یا عضویت در گروه docker داشته باشید. اگر با Docker آشنا نیستید، اصول اولیه Docker Compose روی VPS نصب و دستورات اصلی مورد نیاز این راهنما را پوشش میدهد. داشتن یک نام دامنه که به سرور اشاره میکند توصیه میشود، زیرا برای Dify به جای استفاده از یک IP خام، به TLS نیاز خواهید داشت.
گام 1: دریافت Dify و فایلهای Compose آن
Dify تنظیمات Docker خود را در مخزن اصلی نگهداری میکند. آن را کلون کرده و وارد دایرکتوری docker شوید:
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .envفایل .env کل پیکربندی را در بر میگیرد. پیش از انجام هر کاری، آن را مطالعه کنید. مقادیری که در ابتدا اهمیت دارند، آنهایی هستند که رمزهای عبور و اسرار را تعیین میکنند: SECRET_KEY، رمز عبور Postgres و رمز عبور Redis. فایل نمونه با مقادیر پیشفرض عرضه میشود و باقی گذاشتن آنها به همان صورت، رایجترین راه برای نفوذ به یک نمونه Dify میزبانیشده توسط کاربر است. یک کلید امنیتی واقعی تولید کنید:
openssl rand -base64 42آن را در SECRET_KEY جایگذاری کنید و برای هر فیلد رمز عبور در فایل، یک مقدار قوی و منحصربهفرد تنظیم نمایید.
گام 2: راهاندازی سرویس
پشته (stack) را بالا بیاورید:
docker compose up -dاجرای اولیه چندین image را دانلود کرده و دیتابیس را مقداردهی اولیه میکند، بنابراین یک دقیقه صبر کنید. بررسی کنید که containerها در وضعیت سلامت (healthy) باشند:
docker compose psهر سرویس باید وضعیت running را نشان دهد. Dify رابط کاربری وب خود را بهصورت پیشفرض از طریق یک container داخلی nginx روی پورت 80 ارائه میدهد. در اولین بازدید از http://YOUR_SERVER/install، حساب کاربری مدیر (admin) را ایجاد کنید. این کار را بلافاصله انجام دهید، پیش از آنکه هر کس دیگری بتواند به این پورت دسترسی پیدا کند؛ زیرا تا زمانی که این حساب ایجاد نشده باشد، هر کسی که صفحه را بارگذاری کند میتواند آن را تصاحب کرده و مالک instance شما شود.
گام 3: آن را بهصورت خام در معرض قرار ندهید. از TLS و فایروال استفاده کنید
این همان نقطهای است که اکثر نصبهای سریع در آن متوقف میشوند و اکثر حوادث امنیتی از آنجا آغاز میگردند. سرویس nginx داخلی Dify روی پورت 80 و بهصورت متنباز (بدون رمزنگاری) روی تمام اینترفیسها گوش میدهد. شما نمیخواهید اطلاعات ورود مدیریت و کلیدهای مدل شما از طریق HTTP ساده منتقل شوند و همچنین نباید سرویسهای داخلی از خارج قابل دسترسی باشند.
سرور را با یک فایروال با سیاست پیشفرض 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 باز بگذارد؛ این همان شکاف فایروال IPv6 است که بسیاری از کاربران self-host را دچار مشکل میکند. اطمینان حاصل کنید که هر دو پشته (stack) فیلتر شدهاند.
برای TLS، تمیزترین روش این است که پورت وب Dify را به loopback bind کنید و یک reverse proxy را با گواهی Let’s Encrypt در جلوی آن اجرا کنید؛ در این حالت، تنها مؤلفهای که در اینترنت عمومی قرار دارد، proxy است که با HTTPS ارتباط برقرار میکند. .env در Dify امکان تغییر پورت exposeشده را فراهم میکند؛ آن را طوری تنظیم کنید که روی 127.0.0.1 bind شود و proxy را به همان مقصد هدایت کنید. ایدههای hardening مربوط به agent در اجرای ایمن یک AI agent روی VPS در اینجا نیز کاربرد دارند: مؤلفههای متغیر را روی loopback نگه دارید، فقط مواردی را expose کنید که باید عمومی باشند و اجازه دهید یک درگاه ورودی hardenشده با TLS ارتباط برقرار کند. اگر رابط یک ابزار فقط برای خودتان است و اصلاً به گواهی نیاز ندارد، proxy را حذف کنید و از طریق SSH tunnel به آن دسترسی پیدا کنید؛ همانطور که self-hosting اسکنر امنیتی open-kritt داشبورد خود را روی loopback bind میکند و آن را بهجای انتشار عمومی، به لپتاپ شما forward میکند. اگر کل یک تیم به Dify نیاز دارد اما نباید در اینترنت عمومی قرار بگیرد، یک overlay network این ایده را فراتر از یک لپتاپ گسترش میدهد: اعلام subnet خصوصی سرور به tailnet شما به هر دستگاه تأییدشده اجازه میدهد از طریق یک آدرس خصوصی به builder دسترسی پیدا کند، در حالی که firewall برای همهچیز بهجز SSH بسته میماند. اگر این سرور را بهجای کار دستی، از طریق یک coding agent مدیریت میکنید، پیش از آنکه کلیدها را در اختیارش بگذارید، مشخص کنید تا چه اندازه اجازه دارد بدون نظارت عمل کند؛ زیرا حالت مجوزی که Claude Code را در آن رها میکنید تعیین میکند که آیا پیش از بازنویسی .env یا restart کردن stack برای تأیید متوقف میشود یا نه. اگر یک session مشغول tail کردن لاگهای container باشد و session دیگری configuration مربوط به proxy را ویرایش کند، این دو session میتوانند روی همان سرور متن را برای یکدیگر ارسال کنند؛ این روش بهتر از آن است که هر بار پس از restart کردن stack، خروجی را میان terminalها کپی کنید.
گام 4: بهروز نگه داشتن
Dify با سرعت توسعه مییابد و بهروزرسانیها شامل اصلاحات امنیتی هستند. برای بهروزرسانی، کافی است تغییرات را از مخزن دریافت کرده و سرویس را در دایرکتوری docker مجدداً راهاندازی کنید:
git pull
docker compose pull
docker compose up -dپیش از ارتقای نسخه اصلی (major version)، یادداشتهای انتشار (release notes) را مطالعه کنید؛ زیرا Dify گاهی اوقات در نسخههای جدید، طرحواره .env را تغییر میدهد و ممکن است یک متغیر جدید که تنظیم نکردهاید، مانع از شروع به کار container شود.
گام 5: پشتیبانگیری از دادههایی که قابل بازیابی نیستند
دو مورد در یک سرور Dify غیرقابل جایگزین هستند: پایگاه داده Postgres که برنامهها، کاربران و تنظیمات شما را در خود نگه میدارد، و volumeای که اسناد بارگذاریشده و ایندکس برداری (vector index) را ذخیره میکند. هر دوی این موارد در دایرکتوری docker تحت Docker volumes قرار دارند. از آنها بهصورت زمانبندیشده اسنپشات بگیرید و اسنپشاتها را از سرور خارج کنید. یک API key مدل را میتوان دوباره صادر کرد، اما برنامهای که یک هفته برای ساخت آن وقت گذاشتهاید، قابل بازیابی نیست. همین منطق برای هر عاملی (agent) که وضعیت آن باید فراتر از طول عمر ماشینی که روی آن اجرا میشود باقی بماند، صادق است: فعال نگهداشتن KiroCrew به عنوان یک کانتینر همیشهروشن به اسنپشات گرفتن از حافظه و زمانبندیهایی وابسته است که در غیر این صورت با reboot بعدی از بین میروند.
هنگامی که میخواهید عاملهایی که در اینجا میسازید فراتر از مجموعه دادههای خودتان بروند و وب زنده را جستجو کنند، اتصال آنها به یک نمونه SearXNG خودمیزبان (self-hosted) جریان پرسوجوها را روی سختافزاری که کنترل میکنید نگه میدارد؛ هرچند پیش از فعالسازی، مطالعه درباره سطح حمله تزریق پرامپت (prompt injection) که ایجاد میشود، ارزشمند است. برای یک عامل خودمختارتر با قابلیت اجرای کد، به میزبانی Agent Zero مراجعه کنید و ساخت عامل هوش مصنوعی خود روی یک VPS مبانی زیربنایی همه آنها را پوشش میدهد.
FAQ
حداقل سیستم مورد نیاز برای میزبانی شخصی Dify چیست؟
Dify بهصورت یک stack شامل حدود 6 کانتینر در Docker Compose اجرا میشود. بنابراین برای یک VPS حداقل 2 گیگابایت رم آزاد (ترجیحاً 4 گیگابایت)، به همراه چند هسته CPU و فضای دیسک کافی برای اسناد بارگذاریشده و ایندکس برداری (vector index) در نظر بگیرید. فشار اصلی روی حافظه، ناشی از پایگاه داده و ذخیرهساز برداری است، نه خودِ Dify.
آیا قرار دادن مستقیم Dify روی پورت 80 امن است؟
خیر. وبسرور داخلی Dify از پروتکل HTTP ساده استفاده میکند و درگاه ورود مدیریت و کلیدهای API مدلهای شماست. یک reverse proxy با گواهی Let's Encrypt در مقابل آن قرار دهید، پورت Dify را فقط به loopback محدود کنید و اجازه دهید تنها proxy با پروتکل HTTPS در دسترس اینترنت باشد. این تنظیمات را با یک فایروال که سیاست پیشفرض آن مسدودسازی (default-deny) است و هر دو پروتکل IPv4 و IPv6 را پوشش میدهد، تکمیل کنید.
چگونه Dify را که بهصورت شخصی میزبانی شده است، بهروزرسانی کنم؟
از داخل دایرکتوری docker، دستور git pull را اجرا کنید، سپس برای دریافت imageهای جدید و راهاندازی مجدد، docker compose pull و docker compose up -d را به کار ببرید. ابتدا یادداشتهای انتشار (release notes) را مطالعه کنید، زیرا Dify گاهی اوقات متغیرهای .env جدیدی بین نسخهها اضافه میکند و نبودِ یک متغیر میتواند مانع از بالا آمدن کانتینر شود.
اولین کاری که پس از نصب Dify باید انجام دهم چیست؟
به /install بروید و بلافاصله حساب کاربری مدیر (admin) را ایجاد کنید. تا زمانی که این حساب وجود ندارد، هر کسی که به صفحه دسترسی داشته باشد میتواند آن را تصاحب کند. بهمحض اینکه کانتینرها در وضعیت سالم قرار گرفتند و پیش از آنکه فایروال را برای دسترسی عمومی باز کنید، این حساب را تنظیم کنید.