آموزش نصب و راه‌اندازی Dify با Docker Compose روی VPS

Dify چیست و برای اجرای چه چیزی ثبت‌نام می‌کنید

Dify یک پلتفرم با قابلیت self-hosting برای ساخت برنامه‌ها بر پایه مدل‌های زبانی بزرگ (LLM) است. شما یک رابط وب برای طراحی برنامه‌های چت، عامل‌ها (agents) و خط‌لوله‌های بازیابی (retrieval pipelines)، یک API برای فراخوانی آن‌ها از کد خودتان و یک مکان واحد برای مدیریت پرامپت‌ها، مجموعه‌داده‌ها و کلیدهای مدل دریافت می‌کنید. این ابزاری است که یک تیم کوچک راه‌اندازی می‌کند تا همه به‌جای پخش کردن کلیدهای API در اسکریپت‌های مختلف، روی یک بستر خصوصی مشترک کار کنند. اگر مفاهیمی مانند عامل، فراخوانی ابزار و خط‌لوله بازیابی هنوز برایتان مبهم است، یادگیری این مفاهیم از پایه باعث می‌شود صفحات سازنده Dify به‌جای مجموعه‌ای از کلیدهای نامشخص، مانند کنترل‌های آشنا به نظر برسند.

اجرای شخصی آن به معنای مدیریت بخش‌های متحرک بسیاری است. تا اکتبر 2026، پشته پیش‌فرض مستندشده Dify شامل 15 کانتینر در حال اجرا و یک تسک یک‌باره است که مجوزهای فایل را تنظیم کرده و خارج می‌شود. هفت مورد از آن‌ها سرویس‌های خود Dify هستند: سرور API، سرور websocket، پردازشگر پس‌زمینه (background worker)، زمان‌بند (scheduler)، فرانت‌اند وب، دیمون پلاگین و بک‌اند عامل. هشت مورد دیگر وابستگی‌ها هستند: دیتابیس Postgres، کش Redis، دیتابیس برداری Weaviate، درگاه nginx، دو sandbox کد و دو پروکسی SSRF. ابزار Docker Compose همه آن‌ها را به هم متصل می‌کند، اما این یک پشته واقعی است و حداقل سخت‌افزار مستندشده برای Dify برابر با 4 GiB رم و دو هسته CPU است. اگر قرار است آن VPS سرویس دیگری را نیز میزبانی کند، منابع را بر اساس اعداد اندازه‌گیری‌شده تعیین کنید، نه اعداد تبلیغاتی؛ زیرا حداقل رم واقعی PhotoPrism و Immich بسیار بالاتر از مقادیر اعلام‌شده آن‌هاست و یک سرور عکس که در همان سرور باشد، ابتدا دیتابیس و ذخیره‌ساز برداری Dify را با کمبود منابع مواجه می‌کند. رقابت بر سر CPU نیز به همین شکل است: یک کتابخانه Jellyfin که به شکل یک ویدیو کلوپ دهه 90 طراحی شده، هنگام مرور تصاویر هزینه پردازشی ناچیزی دارد، اما به محض اینکه شخصی شروع به transcode کند، صف‌های پردازشگر Dify پشت آن معطل می‌مانند. نکته دلگرم‌کننده این است که تعداد کانتینرهای Dify صرف‌نظر از تعداد برنامه‌هایی که روی آن می‌سازید ثابت است، که الگوی هزینه‌ای ملایم‌تری نسبت به OpenBot است که در آن هر همکار هوش مصنوعی کانتینر و مرورگر مخصوص خود را دارد و هر استخدام جدید، حداقل حافظه مورد نیاز را افزایش می‌دهد.

از آنجا که Dify کلیدهای API مدل شما و اغلب اسناد خصوصی که برای بازیابی بارگذاری کرده‌اید را نگهداری می‌کند، سروری که روی آن اجرا می‌شود را از همان دقیقه اول حساس تلقی کنید. این راهنما آن را نصب کرده و سپس به شکلی که هر سرویس دارای اسرار را ایمن می‌کنید، آن را مقاوم‌سازی (harden) می‌کند.

پیش‌نیازها

شما به یک VPS با سیستم‌عامل Ubuntu 24.04، حداقل 4 GiB رم و دو هسته CPU نیاز دارید. همچنین باید Docker به همراه پلاگین Docker Compose نصب شده باشد (Dify به نسخه 2.24.0 یا بالاتر از Compose نیاز دارد). کاربر شما باید دسترسی sudo داشته باشد یا عضو گروه docker باشد. دستور clone در ادامه از git، curl و jq استفاده می‌کند. اگر با Docker آشنا نیستید، اصول Docker Compose روی VPS نصب و دستورات اصلی مورد نیاز این راهنما را پوشش می‌دهد. داشتن یک نام دامنه که به سرور اشاره می‌کند توصیه می‌شود، زیرا احتمالاً ترجیح می‌دهید به جای استفاده از یک آدرس IP خام، از TLS در مقابل Dify استفاده کنید.

گام 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" مواجه شد، به این دلیل است که جستجوی API گیت‌هاب نتیجه‌ای نداشته است؛ یک نسخه را از صفحه releases انتخاب کرده و آن را به‌صورت دستی به --branch بدهید.

فایل .env پیکربندی اصلی است. پیش از انجام هر کاری آن را مطالعه کنید. مقادیری که در ابتدا اهمیت دارند، آن‌هایی هستند که رمزهای عبور و اسرار (secrets) را تعیین می‌کنند: SECRET_KEY، رمز عبور Postgres و رمز عبور Redis. فایل SECRET_KEY به‌صورت خالی ارائه می‌شود و اگر آن را به همان شکل رها کنید، Dify یک کلید تولید کرده و در دایرکتوری ذخیره‌سازی خود نگه می‌دارد. رمزهای عبور موضوع متفاوتی هستند: فایل نمونه، مقدار difyai123456 یکسانی را برای Postgres و Redis تنظیم کرده و کلیدهای ثابت و عمومی شناخته‌شده‌ای را برای sandbox کد، daemon افزونه و Weaviate در نظر گرفته است. باقی گذاشتن این مقادیر به همان شکلی که ارائه شده‌اند، رایج‌ترین دلیل برای به خطر افتادن (compromise) یک نمونه Dify است که به‌صورت self-hosted اجرا می‌شود. اگر ترجیح می‌دهید کلید امنیتی خود را تنظیم کنید، یکی تولید کنید:

openssl rand -base64 42

آن را در SECRET_KEY جای‌گذاری کنید و برای هر فیلد رمز عبور و کلید در فایل، یک مقدار قوی و منحصربه‌فرد تنظیم نمایید. رمز عبور Redis در داخل CELERY_BROKER_URL نیز ظاهر می‌شود، بنابراین آن را در آنجا نیز تغییر دهید، در غیر این صورت worker نمی‌تواند به Redis متصل شود.

گام 2: راه‌اندازی

پشته (stack) را بالا بیاورید:

docker compose up -d

اجرای اول چندین image را دانلود کرده و دیتابیس را مقداردهی اولیه می‌کند، بنابراین یک دقیقه به آن زمان بدهید. بررسی کنید که containerها در وضعیت سالم (healthy) باشند:

docker compose ps

هر سرویس با اجرای طولانی‌مدت باید وضعیت running را داشته باشد؛ وظیفهٔ مجوزدهی یک‌باره، پس از انجام کارش خاتمه می‌یابد. Dify رابط وب خود را به‌صورت پیش‌فرض از طریق یک container داخلی nginx روی پورت 80 ارائه می‌دهد. در اولین بازدید از http://YOUR_SERVER/install، حساب کاربری مدیر را ایجاد کنید. این کار را بلافاصله انجام دهید، پیش از آنکه هر کس دیگری بتواند به پورت دسترسی پیدا کند؛ زیرا تا زمانی که آن حساب وجود نداشته باشد، هر کسی که صفحه را بارگذاری کند می‌تواند آن را تصاحب کرده و مالک instance شما شود.

گام 3: آن را به‌صورت خام در معرض قرار ندهید. از TLS و فایروال استفاده کنید

اینجاست که اکثر نصب‌های سریع متوقف می‌شوند و اکثر حوادث امنیتی آغاز می‌گردند. سرویس nginx داخلی Dify روی پورت 80، به‌صورت متن‌باز (clear) و روی تمامی اینترفیس‌ها گوش می‌دهد و پورت 443 را نیز منتشر می‌کند. شما نمی‌خواهید اطلاعات ورود مدیریت و کلیدهای مدل شما از طریق 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) فیلتر شده‌اند. همچنین بدانید که پورت‌هایی که Docker منتشر می‌کند توسط قوانین فایروال خود Docker مدیریت می‌شوند، نه ufw، و پشته پیش‌فرض، پورت دیباگ پلاگین daemon یعنی 5003 را روی همه اینترفیس‌ها منتشر می‌کند. مقدار EXPOSE_PLUGIN_DEBUGGING_PORT را در .env روی 127.0.0.1:5003 تنظیم کنید، مگر اینکه واقعاً قصد داشته باشید پلاگین‌ها را از ماشین دیگری دیباگ کنید.

برای TLS، تمیزترین راه این است که پورت وب Dify را روی loopback محدود کنید و یک reverse proxy با گواهی Let’s Encrypt در مقابل آن قرار دهید، به‌طوری که تنها چیزی که در اینترنت عمومی قرار دارد، پروکسی با پروتکل HTTPS باشد. متغیر .env در Dify به شما اجازه می‌دهد پورت در معرض قرار گرفته را تغییر دهید؛ آن را روی 127.0.0.1 تنظیم کنید و پروکسی خود را به آن سمت هدایت نمایید. همین کار را برای EXPOSE_NGINX_SSL_PORT انجام دهید، زیرا nginx در Dify به‌صورت پیش‌فرض پورت 443 میزبان را اشغال می‌کند و پروکسی شما به آن نیاز دارد. ایده‌های مقاوم‌سازی عامل (agent-hardening) در اجرای ایمن یک عامل هوش مصنوعی روی VPS در اینجا نیز صدق می‌کنند: بخش‌های متحرک را روی loopback نگه دارید، فقط آنچه را که باید عمومی باشد در معرض قرار دهید و اجازه دهید یک درگاه ورودی مقاوم‌شده، TLS را مدیریت کند. در مواردی که رابط کاربری یک ابزار فقط برای شماست و نیازی به گواهی ندارد، از پروکسی صرف‌نظر کرده و از طریق SSH tunnel به آن دسترسی پیدا کنید؛ همان‌طور که میزبانی شخصی اسکنر امنیتی open-kritt داشبورد خود را روی loopback محدود کرده و به جای انتشار عمومی، آن را به لپ‌تاپ شما فوروارد می‌کند. اگر کل یک تیم به Dify نیاز دارند اما اینترنت عمومی نیازی ندارد، یک شبکه overlay این ایده را فراتر از یک لپ‌تاپ مقیاس‌پذیر می‌کند: تبلیغ زیرشبکه خصوصی سرور در tailnet به هر دستگاه تاییدشده اجازه می‌دهد با یک آدرس خصوصی به سازنده دسترسی پیدا کند، در حالی که فایروال برای همه چیز به‌جز SSH بسته می‌ماند. اگر این سرور را به جای دسترسی دستی، از طریق یک عامل کدنویسی مدیریت می‌کنید، پیش از سپردن کلیدها مشخص کنید که چه میزان دسترسی بدون نظارت مجاز است، زیرا حالت دسترسی که برای Claude Code تعیین می‌کنید مشخص می‌کند که آیا پیش از بازنویسی .env یا راه‌اندازی مجدد پشته، از شما اجازه می‌گیرد یا خیر. اگر در نهایت یک نشست (session) را برای مشاهده لاگ‌های کانتینر و نشست دیگری را برای ویرایش پیکربندی پروکسی باز گذاشتید، این دو نشست می‌توانند متن را روی همان ماشین به یکدیگر منتقل کنند، که بسیار بهتر از کپی کردن خروجی بین ترمینال‌ها در هر بار راه‌اندازی مجدد پشته است.

گام 4: به‌روز نگه داشتن

پروژه Dify با سرعت زیادی توسعه می‌یابد و به‌روزرسانی‌ها شامل اصلاحات امنیتی مهمی هستند. از آنجا که شما یک release tag را کلون کرده‌اید، به‌روزرسانی به معنای checkout کردن تگ بعدی است، نه pull کردن یک branch. ابتدا از دیتابیس نسخه پشتیبان تهیه کنید و سپس از دایرکتوری docker دستورات زیر را اجرا کنید:

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

مهاجرت‌های دیتابیس به‌صورت خودکار در زمان راه‌اندازی اجرا می‌شوند و برخی از آن‌ها قابل بازگشت نیستند؛ به همین دلیل تهیه نسخه پشتیبان پیش از هر کاری الزامی است. پیش از هر ارتقا، نه فقط نسخه‌های اصلی (major)، یادداشت‌های انتشار (release notes) را مطالعه کنید. Dify اعلام کرده است که مراحل ارتقا بین نسخه‌ها متفاوت است؛ برای مثال، یادداشت‌های نسخه 1.17.1 (سپتامبر 2026) به کاربرانی که از Weaviate باندل‌شده با داده‌های موجود استفاده می‌کنند، توصیه می‌کند که مستقیماً به آن نسخه جهش نکنند و مرحله‌به‌مرحله از طریق نسخه‌های فرعی (minor) ارتقا یابند. همچنین Dify ساختار .env را بین نسخه‌ها تغییر می‌دهد؛ بنابراین پس از checkout کردن یک تگ جدید، فایل .env.example را با .env خود مقایسه کرده و تغییرات لازم را اعمال کنید، زیرا یک متغیر جدید که تنظیم نشده باشد، می‌تواند مانع از شروع به کار container شود.

گام 5: پشتیبان‌گیری از داده‌هایی که قابل بازیابی نیستند

دو بخش در سرور Dify غیرقابل جایگزینی هستند: پایگاه داده Postgres که برنامه‌ها، کاربران و تنظیمات شما را در خود نگه می‌دارد، و volumeای که اسناد بارگذاری‌شده و ایندکس برداری (vector index) را ذخیره می‌کند. هر دو در مسیر docker تحت Docker volumes قرار دارند. از آن‌ها به‌صورت زمان‌بندی‌شده اسنپ‌شات تهیه کنید و اسنپ‌شات‌ها را از سرور خارج کنید. این اسنپ‌شات‌ها حاوی تمام کلیدهای مدل و اسناد بارگذاری‌شده در یک فایل واحد هستند؛ بنابراین پیش از خروج از سرور، آن‌ها را رمزنگاری کنید. دلیل این کار همان است که پشتیبان‌گیری از Vaultwarden می‌تواند به نقطه ضعف یک سرور رمز عبور مستحکم تبدیل شود. کلید API یک مدل قابل صدور مجدد است، اما برنامه‌ای که یک هفته برای ساخت آن وقت گذاشته‌اید، خیر. همین منطق برای هر عاملی (agent) که وضعیت آن باید پس از خاموش شدن ماشین باقی بماند، صادق است: اجرای مداوم KiroCrew به عنوان یک کانتینر همیشه روشن به تهیه اسنپ‌شات از حافظه و زمان‌بندی‌هایی وابسته است که در غیر این صورت با ریبوت بعدی از بین می‌روند.

هنگامی که می‌خواهید عامل‌هایی که در اینجا می‌سازید فراتر از مجموعه داده‌های خودتان عمل کنند و در وب زنده جستجو کنند، اتصال آن‌ها به یک نمونه SearXNG شخصی‌سازی‌شده جریان پرس‌وجوها را روی سخت‌افزاری که کنترل می‌کنید نگه می‌دارد؛ هرچند پیش از فعال‌سازی، مطالعه درباره سطح حمله تزریق پرامپت (prompt injection) که ایجاد می‌شود، توصیه می‌شود. برای یک عامل خودمختارتر با قابلیت اجرای کد، میزبانی شخصی Agent Zero را ببینید و ساخت عامل هوش مصنوعی شخصی روی یک VPS مبانی زیربنایی همه آن‌ها را پوشش می‌دهد.

FAQ

حداقل سیستم مورد نیاز برای میزبانی شخصی Dify چیست؟

مستندات Dify حداقل 4 گیگابایت رم و دو هسته CPU، به همراه Docker Compose نسخه 2.24.0 یا بالاتر را توصیه می‌کنند. این حداقل، نشان‌دهنده حجم stack پیش‌فرض است: 15 کانتینر در حال اجرا به همراه یک تسک مقداردهی اولیه، طبق وضعیت اکتبر 2026. فضای دیسک کافی برای اسناد بارگذاری‌شده و ایندکس برداری در نظر بگیرید و اگر سرویس‌های دیگری روی سرور دارید، رم بیشتری اختصاص دهید.

آیا قرار دادن مستقیم Dify روی پورت 80 امن است؟

خیر. وب‌سرور پیش‌فرض Dify از پروتکل HTTP ساده استفاده می‌کند و این پورت، صفحه ورود مدیریت و کلیدهای API مدل‌های شما را در معرض دید قرار می‌دهد. از یک reverse proxy با گواهی Let's Encrypt در مقابل آن استفاده کنید، پورت Dify را فقط روی loopback تنظیم کنید و اجازه دهید تنها proxy با پروتکل HTTPS به اینترنت متصل باشد. این تنظیمات را با یک فایروال با سیاست default-deny که هم IPv4 و هم IPv6 را پوشش می‌دهد، تکمیل کنید.

چگونه Dify را در میزبانی شخصی به‌روزرسانی کنم؟

ابتدا از دیتابیس نسخه پشتیبان تهیه کنید، سپس از دایرکتوری docker دستورات docker compose down، git fetch --tags، git checkout را برای تگ نسخه جدید، docker compose pull و docker compose up -d اجرا کنید. حتماً یادداشت‌های انتشار (release notes) را مطالعه کنید، زیرا مراحل ارتقا بین نسخه‌ها متفاوت است، مهاجرت‌های دیتابیس ممکن است غیرقابل بازگشت باشند و Dify گاهی متغیرهای محیطی جدیدی به .env اضافه می‌کند که نبود آن‌ها می‌تواند مانع از بالا آمدن کانتینر شود.

اولین کاری که پس از نصب Dify باید انجام دهم چیست؟

به /install مراجعه کرده و بلافاصله حساب کاربری مدیر را ایجاد کنید. تا زمانی که این حساب وجود نداشته باشد، هر کسی که به صفحه دسترسی داشته باشد می‌تواند آن را تصاحب کند. به محض اینکه کانتینرها در وضعیت سالم قرار گرفتند و پیش از آنکه فایروال را برای دسترسی عمومی باز کنید، این حساب را تنظیم کنید.