Docker Compose দিয়ে VPS-এ Dify self-host করুন

Dify কী এবং আপনি কী চালানোর জন্য সাইন আপ করছেন

Dify হলো large language model-এর ওপর application তৈরির জন্য একটি self-hostable platform। এতে chat app, agent এবং retrieval pipeline ডিজাইন করার জন্য web interface, নিজের code থেকে সেগুলো call করার জন্য API, এবং prompt, dataset ও model key পরিচালনার জন্য একটি কেন্দ্রীয় স্থান পাবেন। ছোট কোনো team সাধারণত এমন tool চালু করে, যাতে সবাই আলাদা আলাদা script-এ API key ছড়িয়ে না রেখে একটি shared private base-এর ওপর কাজ করতে পারে। agent, tool call এবং retrieval pipeline-এর মতো শব্দগুলোর অর্থ এখনও অস্পষ্ট হলে, এই ধারণাগুলো একেবারে শুরু থেকে বুঝে নেওয়া আগে শেষ করুন। তাহলে Dify-এর builder screen-গুলোকে label-বিহীন switch-এর দেয়াল মনে হবে না; পরিচিত control হিসেবে পড়তে পারবেন।

নিজে এটি চালানোর অর্থ হলো একাধিক অংশ একসঙ্গে চালানো। Dify একগুচ্ছ Docker container হিসেবে release হয়: একটি API server, একটি background worker, একটি web frontend, একটি Postgres database, একটি Redis cache এবং একটি vector database। Docker Compose এগুলোকে পরস্পরের সঙ্গে সংযুক্ত করে। এটি একটি single binary-এর চেয়ে বড় ব্যবস্থা, কিন্তু Compose সংযোগের কাজ সামলে নেয়। কয়েক gigabyte অতিরিক্ত RAM থাকা একটি VPS-এ এটি স্বাচ্ছন্দ্যে চলে। একই VPS-এ অন্য কিছু চালানোর পরিকল্পনা থাকলে বিজ্ঞাপনে দেওয়া সংখ্যা নয়, মাপা resource usage অনুযায়ী capacity নির্ধারণ করুন। কারণ PhotoPrism এবং Immich-এর প্রকৃত RAM floor প্রকাশিত minimum requirement-এর তুলনায় অনেক বেশি। একই server-এ photo server চললে প্রথমে Dify-এর database এবং vector store পর্যাপ্ত memory পাবে না। CPU contention-ও একইভাবে সমস্যা তৈরি করে। 90s-এর video store-এর মতো সাজানো একটি Jellyfin library শুধু artwork browse করার সময় প্রায় কোনো resource ব্যবহার করে না। কিন্তু কেউ transcode শুরু করলেই Dify-এর worker queue-কে তার পরে অপেক্ষা করতে হয়। সুবিধা হলো, আপনি যত application-ই তৈরি করুন, Dify-এর container-এর সংখ্যা নির্দিষ্ট থাকে। এটি OpenBot-এর তুলনায় resource planning-এর দিক থেকে সহজ, কারণ সেখানে প্রতিটি AI coworker-এর জন্য আলাদা container এবং আলাদা browser থাকে, আর প্রতিটি নতুন coworker যোগ হলে memory floor আবার বেড়ে যায়।

Dify আপনার model API key এবং প্রায়ই retrieval-এর জন্য load করা private document সংরক্ষণ করে। তাই এটি যে server-এ চলছে, প্রথম minute থেকেই সেটিকে sensitive system হিসেবে বিবেচনা করুন। এই guide-এ প্রথমে Dify install করা হবে। এরপর secrets ধারণকারী যেকোনো service-এর মতো এটিকেও harden করা হবে।

পূর্বশর্ত

আপনার একটি VPS প্রয়োজন, যেখানে Ubuntu 24.04, Docker এবং Docker Compose plugin ইনস্টল করা আছে। এছাড়া sudo-এর অধিকারসম্পন্ন কোনো user অথবা docker group-এর সদস্যপদ থাকতে হবে। Docker আপনার কাছে নতুন হলে, VPS-এ Docker Compose-এর মৌলিক বিষয়-এ এই নির্দেশিকায় ব্যবহৃত install পদ্ধতি ও মূল command-গুলো ব্যাখ্যা করা হয়েছে। সার্ভারের দিকে নির্দেশ করা একটি 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 রয়েছে। কোনো কাজ শুরু করার আগে এটি পড়ুন। শুরুতে যে value-গুলো সবচেয়ে গুরুত্বপূর্ণ, সেগুলো password এবং secret নির্ধারণ করে: SECRET_KEY, Postgres password এবং Redis password। উদাহরণ ফাইলটিতে placeholder value থাকে। এগুলো অপরিবর্তিত রাখাই self-hosted Dify compromised হওয়ার সবচেয়ে সাধারণ কারণ। একটি প্রকৃত secret key তৈরি করুন:

openssl rand -base64 42

এটি SECRET_KEY-এ বসান এবং ফাইলটির প্রতিটি password field-এর জন্য শক্তিশালী ও স্বতন্ত্র value নির্ধারণ করুন।

ধাপ 2: এটি চালু করুন

স্ট্যাক চালু করুন:

docker compose up -d

প্রথমবার চালানোর সময় কয়েকটি image download হয় এবং database initialize হয়। তাই এক মিনিট সময় দিন। Container-গুলো healthy কি না পরীক্ষা করুন:

docker compose ps

প্রতিটি service-এর running পড়া উচিত। Dify ডিফল্টভাবে port 80-এ bundled nginx container-এর মাধ্যমে web interface পরিবেশন করে। http://YOUR_SERVER/install-এ প্রথমবার গেলে admin account তৈরি করুন। port-এ অন্য কেউ পৌঁছানোর আগেই এটি করুন। কারণ ওই account তৈরি না হওয়া পর্যন্ত page load করা যে কেউ এটি claim করে আপনার instance-এর মালিক হতে পারে।

ধাপ 3: এটিকে সরাসরি প্রকাশ করবেন না। সামনে TLS এবং firewall রাখুন

বেশিরভাগ দ্রুত installation এখানে থেমে যায়, আর বেশিরভাগ incident এখান থেকেই শুরু হয়। Dify-এর নিজস্ব nginx port 80-এ plain HTTP-তে সব interface-এ listening করে। আপনি চান না যে আপনার admin login এবং model key plain HTTP-তে আদান-প্রদান হোক। আপনি এটাও চান না যে internal service-গুলো বাইরে থেকে reachable থাকুক।

শুধু 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-এ একই port খোলা রাখতে পারে। এটিই IPv6 firewall gap, যা অনেক self-hoster-এর সমস্যা তৈরি করে। উভয় stack-ই filtered কি না নিশ্চিত করুন।

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-কে ওই address-এ পাঠান। VPS-এ AI agent নিরাপদে চালানো-এর agent-hardening ধারণাগুলো এখানেও প্রযোজ্য: পরিবর্তনশীল উপাদানগুলো loopback-এ রাখুন, যা public হওয়া আবশ্যক শুধু সেটিই 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 থেকে access দেওয়ার প্রয়োজন না থাকলে overlay network এই ধারণাকে একটি laptop-এর বাইরে প্রসারিত করে। server-এর private subnet আপনার tailnet-এ প্রকাশ করা হলে প্রতিটি অনুমোদিত device private address ব্যবহার করে builder-এ পৌঁছাতে পারে, আর firewall SSH ছাড়া সবকিছুর জন্য বন্ধ থাকে। আপনি যদি হাতে না করে coding agent দিয়ে এই server পরিচালনা করেন, তবে তাকে keys দেওয়ার আগে নির্ধারণ করুন সে unsupervised অবস্থায় কতটা কাজ করতে পারবে। কারণ Claude Code-এ রেখে দেওয়া permission mode নির্ধারণ করে, .env rewrite করা বা stack restart করার আগে সে থেমে অনুমতি চাইবে কি না। এক session-এ container log tail করার সময় অন্য session-এ proxy config সম্পাদনা করলে, একই server-এ ওই দুই session একে অপরকে text পাঠাতে পারে। এতে stack restart করার সময় প্রতিবার এক terminal থেকে অন্য terminal-এ output copy করতে হয় না।

ধাপ 4: নিয়মিত patch প্রয়োগ করুন

Dify দ্রুত পরিবর্তিত হয়, এবং update-গুলোর মধ্যে security fix থাকে। docker directory থেকে pull এবং restart করলেই update করা যায়:

git pull
docker compose pull
docker compose up -d

Major version-এ upgrade করার আগে release note পড়ুন। কারণ Dify মাঝে মাঝে release-গুলোর মধ্যে .env schema পরিবর্তন করে। আপনি সেট না করা কোনো নতুন variable থাকলে container start নাও হতে পারে।

ধাপ 5: যা পুনরায় তৈরি করা যায় না, তার ব্যাকআপ নিন

একটি Dify সার্ভারে দুটি জিনিস প্রতিস্থাপন করা যায় না: Postgres database, যেখানে আপনার app, user এবং setting থাকে, এবং uploaded document ও vector index সংরক্ষণকারী volume। দুটিই docker directory-এর অধীনে Docker volume হিসেবে থাকে। নির্ধারিত সময়সূচি অনুযায়ী এগুলোর snapshot নিন এবং snapshot-গুলো server-এর বাইরে copy করুন। একটি snapshot-এই প্রতিটি model key ও uploaded document থাকে। তাই server থেকে সরানোর আগে snapshot encrypt করুন। কারণ একটি শক্তিশালী password server-এর দুর্বল দিক হিসেবে Vaultwarden backup প্রকাশ পেতে পারে। Model API key নতুন করে নেওয়া যায়। কিন্তু এক সপ্তাহ ধরে তৈরি করা app পুনরায় তৈরি করা যায় না। যে agent-এর state চালু থাকা machine-এর বাইরে টিকে থাকা দরকার, তার ক্ষেত্রেও একই যুক্তি প্রযোজ্য: KiroCrew-কে সবসময় চালু থাকা container হিসেবে চালু রাখা বলতে মূলত সেই memory ও schedule-এর snapshot নেওয়াই বোঝায়, যা না হলে পরবর্তী reboot-এ হারিয়ে যাবে।

এখানে তৈরি করা agent-গুলোকে নিজের dataset-এর বাইরে গিয়ে live web search করাতে চাইলে তাদের একটি self-hosted SearXNG instance-এর দিকে নির্দেশ করা query stream আপনার নিয়ন্ত্রণাধীন hardware-এ রাখে। তবে এটি চালু করার আগে যে prompt injection surface তৈরি হয়, তা সম্পর্কে পড়ে নেওয়া উচিত। আরও স্বয়ংক্রিয় এবং code চালাতে পারে এমন agent-এর জন্য Agent Zero self-host করুন। আর একটি VPS-এ নিজের AI agent তৈরি করা এসবের ভিত্তিগত বিষয়গুলো ব্যাখ্যা করে।

FAQ

self-hosted Dify চালানোর জন্য system requirements কী?

Dify প্রায় অর্ধ ডজন container-এর Docker Compose stack হিসেবে চলে। তাই অন্তত 2 GB free RAM, আদর্শভাবে 4 GB RAM, কয়েকটি CPU core এবং আপনার upload করা document ও vector index সংরক্ষণের জন্য পর্যাপ্ত disk-সহ একটি VPS পরিকল্পনা করুন। Memory pressure Dify নিজে থেকে নয়, database এবং vector store থেকে তৈরি হয়।

Dify-কে সরাসরি port 80-এ expose করা কি নিরাপদ?

না। Dify-এর bundled web server plain HTTP-তে listen করে এবং এটি আপনার admin login ও model API key-এর সামনে থাকে। সামনে Let's Encrypt certificate-সহ একটি reverse proxy রাখুন, Dify-এর নিজস্ব port loopback-এ bind করুন এবং শুধু HTTPS proxy-কে Internet-facing রাখুন। এর সঙ্গে IPv4 ও IPv6 উভয় কভার করে এমন default-deny firewall ব্যবহার করুন।

self-hosted Dify কীভাবে update করব?

docker directory থেকে git pull চালান। এরপর নতুন image fetch করে restart করার জন্য docker compose pull এবং docker compose up -d চালান। আগে release note পড়ুন, কারণ Dify version-এর মধ্যে মাঝে মাঝে নতুন .env variable যোগ করে। কোনো variable অনুপস্থিত থাকলে container start নাও হতে পারে।

Dify install করার পর প্রথমে কী করতে হবে?

/install-এ যান এবং সঙ্গে সঙ্গে admin account তৈরি করুন। ওই account তৈরি না হওয়া পর্যন্ত page-এ পৌঁছাতে পারে এমন যে কেউ account-টি claim করতে পারে। container-গুলো healthy হওয়ার সঙ্গে সঙ্গে এটি সেট up করুন এবং Internet-এর জন্য firewall খুলে দেওয়ার আগে কাজটি সম্পন্ন করুন।