Docker Compose দিয়ে VPS-এ Dify কীভাবে হোস্ট করবেন

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

Dify হলো লার্জ ল্যাঙ্গুয়েজ মডেলের ওপর ভিত্তি করে অ্যাপ্লিকেশন তৈরির একটি self-hostable প্ল্যাটফর্ম। এতে চ্যাট অ্যাপ, এজেন্ট এবং রিট্রিভাল পাইপলাইন ডিজাইনের জন্য একটি ওয়েব ইন্টারফেস, আপনার নিজের কোড থেকে সেগুলোকে কল করার জন্য একটি API এবং প্রম্পট, ডেটাসেট ও মডেল কি (keys) ম্যানেজ করার একটি কেন্দ্রীয় জায়গা পাবেন। এটি এমন একটি টুল যা ছোট টিমগুলো ব্যবহার করে, যাতে সবাই আলাদা আলাদা স্ক্রিপ্টে API কি ছড়িয়ে না দিয়ে একটি শেয়ারড প্রাইভেট বেস ব্যবহার করে কাজ করতে পারে। যদি এজেন্ট, টুল কল এবং রিট্রিভাল পাইপলাইনের মতো শব্দগুলো আপনার কাছে অস্পষ্ট মনে হয়, তবে প্রথমে এই কনসেপ্টগুলো শুরু থেকে বুঝে নেওয়া ভালো। এতে Dify-এর বিল্ডার স্ক্রিনগুলোকে আপনার কাছে অপরিচিত কোনো সুইচবোর্ডের বদলে পরিচিত কন্ট্রোল প্যানেল বলে মনে হবে।

এটি নিজে রান করার অর্থ হলো অনেকগুলো চলমান অংশ সামলানো। 2026 সালের অক্টোবর পর্যন্ত, Dify-এর ডকুমেন্টেশনে থাকা ডিফল্ট স্ট্যাক 15টি দীর্ঘমেয়াদী কন্টেইনার এবং একটি ওয়ান-টাইম টাস্ক দিয়ে শুরু হয়, যা ফাইল পারমিশন সেট করে বন্ধ হয়ে যায়। এর মধ্যে সাতটি হলো Dify-এর নিজস্ব সার্ভিস: API সার্ভার, একটি websocket সার্ভার, একটি ব্যাকগ্রাউন্ড ওয়ার্কার, একটি শিডিউলার, ওয়েব ফ্রন্টএন্ড, একটি প্লাগইন ডেমোন এবং একটি এজেন্ট ব্যাকএন্ড। বাকি আটটি হলো ডিপেন্ডেন্সি: একটি Postgres ডেটাবেস, একটি Redis ক্যাশ, একটি Weaviate ভেক্টর ডেটাবেস, একটি nginx ফ্রন্ট ডোর, দুটি কোড স্যান্ডবক্স এবং দুটি SSRF প্রক্সি। Docker Compose এগুলোর সবগুলোকে একত্রে যুক্ত করে, কিন্তু এটি একটি বড় স্ট্যাক এবং Dify-এর জন্য নূন্যতম 4 GiB RAM এবং দুটি CPU কোর প্রয়োজন। যদি সেই VPS-এ অন্য কিছুও রান করার পরিকল্পনা থাকে, তবে বিজ্ঞাপনের তথ্যের ওপর ভিত্তি না করে পরিমাপ করা সংখ্যার ওপর ভিত্তি করে সাইজ নির্ধারণ করুন। কারণ PhotoPrism এবং Immich-এর প্রকৃত RAM-এর চাহিদা তাদের প্রকাশিত নূন্যতম চাহিদার চেয়ে অনেক বেশি, এবং একই সার্ভারে থাকা একটি ফটো সার্ভার সবার আগে Dify-এর ডেটাবেস এবং ভেক্টর স্টোরের রিসোর্স দখল করে নেবে। CPU-এর ক্ষেত্রেও একই সমস্যা হয়: Jellyfin লাইব্রেরি ব্রাউজ করার সময় খুব কম রিসোর্স খরচ করে, কিন্তু যখনই কেউ ট্রান্সকোড শুরু করে, তখন Dify-এর ওয়ার্কার কিউ (queue) পিছিয়ে পড়ে। সান্ত্বনার বিষয় হলো, আপনি যতগুলো অ্যাপই তৈরি করুন না কেন, Dify-এর কন্টেইনার সংখ্যা নির্দিষ্ট থাকে। এটি OpenBot-এর তুলনায় অনেক সাশ্রয়ী, যেখানে প্রতিটি AI কো-ওয়ার্কারের জন্য আলাদা কন্টেইনার এবং ব্রাউজার লাগে এবং নতুন কর্মী যোগ করার সাথে সাথে মেমরির চাহিদা বাড়তে থাকে।

যেহেতু Dify আপনার মডেল API কি এবং অনেক ক্ষেত্রে আপনার আপলোড করা ব্যক্তিগত ডকুমেন্ট সংরক্ষণ করে, তাই প্রথম মিনিট থেকেই এই সার্ভারটিকে সংবেদনশীল হিসেবে বিবেচনা করুন। এই গাইডে আমরা এটি ইনস্টল করব এবং তারপর যেকোনো সিক্রেট হোল্ড করা সার্ভিসের মতো একে সুরক্ষিত (harden) করব।

পূর্বশর্তসমূহ

আপনার একটি Ubuntu 24.04 চালিত VPS প্রয়োজন, যাতে কমপক্ষে 4 GiB RAM এবং দুটি CPU কোর রয়েছে। এছাড়া Docker এবং Docker Compose প্লাগইন ইনস্টল করা থাকতে হবে (Dify-এর জন্য Compose 2.24.0 বা তার পরবর্তী সংস্করণ প্রয়োজন)। আপনার এমন একজন ব্যবহারকারী থাকতে হবে যার sudo সুবিধা আছে অথবা যিনি docker গ্রুপের সদস্য। নিচের clone কমান্ডটিতে git, curl এবং jq ব্যবহার করা হয়েছে। আপনি যদি Docker-এ নতুন হন, তবে VPS-এ Docker Compose-এর মৌলিক বিষয়সমূহ নির্দেশিকাটি দেখুন; সেখানে ইনস্টলেশন এবং এই গাইডে ব্যবহৃত মূল কমান্ডগুলো আলোচনা করা হয়েছে। সার্ভারের দিকে নির্দেশ করা একটি ডোমেইন নাম থাকা ভালো, কারণ আপনি সরাসরি IP অ্যাড্রেসের পরিবর্তে Dify-এর সামনে TLS ব্যবহার করতে চাইবেন।

ধাপ 1: Dify এবং এর Compose ফাইলগুলো সংগ্রহ করুন

Dify তাদের Docker সেটআপ মূল রিপোজিটরিতে রাখে। ডেভেলপমেন্ট ব্রাঞ্চ নয়, বরং সর্বশেষ রিলিজটি ক্লোন করুন এবং 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

যদি ক্লোন করার সময় "Remote branch null" ত্রুটি দেখায়, তবে বুঝবেন GitHub API থেকে কোনো তথ্য পাওয়া যায়নি; সেক্ষেত্রে রিলিজ পেজ থেকে একটি ভার্সন বেছে নিন এবং সেটি ম্যানুয়ালি --branch-এ প্রদান করুন।

.env ফাইলটি হলো মূল কনফিগারেশন। কোনো কিছু শুরু করার আগে এটি পড়ে নিন। যে মানগুলো সবার আগে সেট করা প্রয়োজন সেগুলো হলো পাসওয়ার্ড এবং সিক্রেট: SECRET_KEY, Postgres পাসওয়ার্ড এবং Redis পাসওয়ার্ড। SECRET_KEY খালি অবস্থায় থাকে, আপনি যদি এটি পরিবর্তন না করেন তবে Dify নিজেই একটি কি (key) তৈরি করে তা স্টোরেজ ডিরেক্টরিতে রেখে দেবে। পাসওয়ার্ডের বিষয়টি ভিন্ন: উদাহরণস্বরূপ ফাইলে Postgres এবং Redis উভয়ের জন্যই একই difyai123456 সেট করা থাকে, এবং কোড স্যান্ডবক্স, প্লাগইন ডেমোন ও Weaviate-এর জন্য নির্দিষ্ট, সর্বজনবিদিত কি (key) দেওয়া থাকে। এগুলো ডিফল্ট অবস্থায় রেখে দেওয়া হলো একটি self-hosted Dify সার্ভার হ্যাক হওয়ার সবচেয়ে সাধারণ কারণ। আপনি যদি নিজের সিক্রেট কি সেট করতে চান, তবে একটি তৈরি করে নিন:

openssl rand -base64 42

সেটিকে SECRET_KEY-এ পেস্ট করুন এবং ফাইলের প্রতিটি পাসওয়ার্ড ও কি ফিল্ডের জন্য শক্তিশালী ও অনন্য মান সেট করুন। Redis পাসওয়ার্ডটি CELERY_BROKER_URL ফাইলের ভেতরেও থাকে, তাই সেখানেও এটি পরিবর্তন করুন, অন্যথায় ওয়ার্কার Redis-এর সাথে সংযোগ স্থাপন করতে পারবে না।

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

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

docker compose up -d

প্রথমবার চালানোর সময় এটি বেশ কিছু ইমেজ ডাউনলোড করে এবং ডাটাবেজ ইনিশিয়ালাইজ করে, তাই এক মিনিট সময় দিন। কন্টেইনারগুলো ঠিকমতো চলছে কি না তা পরীক্ষা করুন:

docker compose ps

প্রতিটি দীর্ঘস্থায়ী সার্ভিসকে অবশ্যই running পড়তে হবে; একবার কাজ শেষ হয়ে গেলে পারমিশন সংক্রান্ত ওয়ান-টাইম টাস্কটি নিজে থেকেই বন্ধ হয়ে যায়। Dify ডিফল্টভাবে পোর্ট 80-এ একটি বান্ডেল করা nginx কন্টেইনারের মাধ্যমে এর ওয়েব ইন্টারফেস পরিবেশন করে। http://YOUR_SERVER/install-এ আপনার প্রথম ভিজিটের সময় আপনি অ্যাডমিন অ্যাকাউন্ট তৈরি করবেন। অন্য কেউ এই পোর্টে পৌঁছানোর আগেই দ্রুত এটি সম্পন্ন করুন, কারণ অ্যাকাউন্ট তৈরি না হওয়া পর্যন্ত যে কেউ পেজটি লোড করে সেটির নিয়ন্ত্রণ নিতে পারে এবং আপনার ইনস্ট্যান্সের মালিক হয়ে যেতে পারে।

ধাপ 3: সরাসরি উন্মুক্ত করবেন না। সামনে TLS এবং একটি ফায়ারওয়াল রাখুন

অধিকাংশ দ্রুত ইনস্টলেশন এখানেই থেমে যায় এবং অধিকাংশ নিরাপত্তা ঘটনার সূত্রপাত এখান থেকেই হয়। Dify-এর নিজস্ব Nginx প্রতিটি ইন্টারফেসে পোর্ট 80-এ plain HTTP এবং পোর্ট 443-এ সেবা প্রদান করে। আপনি নিশ্চয়ই চাইবেন না যে আপনার অ্যাডমিন লগইন এবং মডেল কি (keys) 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-এ একই পোর্টগুলো উন্মুক্ত রাখতে পারে। এটি সেই IPv6 firewall gap, যা অনেক সেলফ-হোস্টারকে বিপদে ফেলে। নিশ্চিত করুন যে উভয় স্ট্যাকই ফিল্টার করা হয়েছে। আরও জেনে রাখুন, Docker যে পোর্টগুলো পাবলিশ করে তা Docker-এর নিজস্ব ফায়ারওয়াল রুল দ্বারা নিয়ন্ত্রিত হয়, ufw দ্বারা নয়। ডিফল্ট স্ট্যাকটি প্লাগইন ডেমনের ডিবাগিং পোর্ট 5003 প্রতিটি ইন্টারফেসে উন্মুক্ত রাখে। যদি না আপনি অন্য কোনো মেশিন থেকে প্লাগইন ডিবাগ করতে চান, তবে .env ফাইলে EXPOSE_PLUGIN_DEBUGGING_PORT-কে 127.0.0.1:5003 হিসেবে সেট করুন।

TLS-এর জন্য সবচেয়ে পরিচ্ছন্ন উপায় হলো Dify-এর ওয়েব পোর্টকে loopback-এ bind করা এবং সামনে একটি reverse proxy চালানো, যা Let's Encrypt সার্টিফিকেট ব্যবহার করবে। এতে পাবলিক ইন্টারনেটে শুধুমাত্র প্রক্সিটি HTTPS-এ কথা বলবে। Dify-এর .env ব্যবহার করে আপনি উন্মুক্ত পোর্ট পরিবর্তন করতে পারেন; এটিকে 127.0.0.1-এ bind করার জন্য সেট করুন এবং আপনার প্রক্সিকে সেই পোর্টের দিকে নির্দেশ করুন। EXPOSE_NGINX_SSL_PORT-এর ক্ষেত্রেও একই কাজ করুন, কারণ Dify-এর Nginx ডিফল্টভাবে হোস্ট পোর্ট 443 দখল করে রাখে, যা আপনার প্রক্সির প্রয়োজন। running an AI agent safely on a VPS-এ বর্ণিত এজেন্ট-হার্ডেনিং কৌশলগুলো এখানেও প্রযোজ্য: সচল অংশগুলোকে loopback-এ রাখুন, শুধুমাত্র প্রয়োজনীয় অংশগুলো পাবলিক করুন এবং একটি সুরক্ষিত ফ্রন্ট ডোরকে TLS হ্যান্ডেল করতে দিন। যদি কোনো টুলের ইন্টারফেস শুধুমাত্র আপনার ব্যবহারের জন্য হয় এবং সেখানে সার্টিফিকেটের প্রয়োজন না থাকে, তবে প্রক্সি এড়িয়ে SSH tunnel ব্যবহার করুন। যেমন self-hosting the open-kritt security scanner-এ ড্যাশবোর্ডটিকে loopback-এ bind করে ল্যাপটপে ফরোয়ার্ড করা হয়, যাতে তা সরাসরি পাবলিশ না হয়। যদি পুরো টিমের Dify ব্যবহারের প্রয়োজন হয় কিন্তু পাবলিক ইন্টারনেটের নয়, তবে একটি overlay network এই ধারণাকে এক ল্যাপটপের গণ্ডি ছাড়িয়ে প্রসারিত করে: advertising the server's private subnet to your tailnet ব্যবহার করে অনুমোদিত প্রতিটি ডিভাইস একটি প্রাইভেট ঠিকানায় বিল্ডারকে অ্যাক্সেস করতে পারবে, যেখানে ফায়ারওয়াল SSH ছাড়া বাকি সবকিছুর জন্য বন্ধ থাকবে। যদি আপনি হাতে কাজ না করে কোনো কোডিং এজেন্টের মাধ্যমে এই সার্ভার পরিচালনা করেন, তবে তাকে দায়িত্ব দেওয়ার আগে নির্ধারণ করুন সে কতটা কাজ স্বয়ংক্রিয়ভাবে করতে পারবে। কারণ the permission mode you leave Claude Code in ঠিক করে দেয় যে, .env ফাইলটি পরিবর্তন বা স্ট্যাক রিস্টার্ট করার আগে সে অনুমতি চাইবে কি না। যদি এমন হয় যে একটি সেশনে আপনি কন্টেইনার লগ দেখছেন এবং অন্যটিতে প্রক্সি কনফিগারেশন এডিট করছেন, তবে those two sessions can pass text to each other on the same box—এটি প্রতিবার স্ট্যাক রিস্টার্টের সময় টার্মিনালের মধ্যে টেক্সট কপি করার চেয়ে অনেক বেশি কার্যকর।

ধাপ 4: প্যাচ আপডেট রাখা

Dify দ্রুত পরিবর্তিত হয় এবং এর আপডেটগুলোতে নিরাপত্তা সংক্রান্ত ফিক্স অন্তর্ভুক্ত থাকে। যেহেতু আপনি একটি নির্দিষ্ট release tag ক্লোন করেছেন, তাই আপডেট করার অর্থ হলো নতুন tag-এ চেক আউট করা, কোনো branch পুল করা নয়। প্রথমে ডাটাবেস ব্যাকআপ নিন, তারপর docker ডিরেক্টরি থেকে নিচের কমান্ডটি চালান:

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

স্টার্টআপের সময় ডাটাবেস মাইগ্রেশন স্বয়ংক্রিয়ভাবে সম্পন্ন হয় এবং এর মধ্যে কিছু মাইগ্রেশন রিভার্স করা সম্ভব নয়, তাই ব্যাকআপ নেওয়া জরুরি। প্রতিটি আপগ্রেডের আগে রিলিজ নোটগুলো পড়ুন, শুধু বড় আপগ্রেডের ক্ষেত্রে নয়: Dify-এর মতে রিলিজভেদে আপগ্রেড পদ্ধতি ভিন্ন হতে পারে। উদাহরণস্বরূপ, 1.17.1 রিলিজ নোট (সেপ্টেম্বর 2026) অনুযায়ী, যারা বিদ্যমান ডাটা সহ bundled Weaviate ব্যবহার করছেন, তাদের সরাসরি সেই ভার্সনে না গিয়ে প্রতিটি মাইনর রিলিজ ধাপে ধাপে আপডেট করতে বলা হয়েছে। এছাড়া রিলিজের সাথে সাথে Dify-এর .env স্কিমাও পরিবর্তিত হয়, তাই নতুন tag চেক আউট করার পর .env.example-এর সাথে আপনার .env তুলনা করুন এবং প্রয়োজনীয় পরিবর্তনগুলো স্থানান্তর করুন। কারণ নতুন কোনো ভেরিয়েবল সেট করা না থাকলে কন্টেইনার স্টার্ট হতে বাধাগ্রস্ত হতে পারে।

ধাপ 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

Dify self-host করার জন্য সিস্টেমের প্রয়োজনীয়তা কী?

Dify-এর নথিপত্র অনুযায়ী ন্যূনতম 4 GiB RAM এবং দুটি CPU কোর প্রয়োজন, সেই সাথে Docker Compose 2.24.0 বা তার পরবর্তী সংস্করণ থাকতে হবে। এই ন্যূনতম প্রয়োজনীয়তা ডিফল্ট স্ট্যাকের আকারের ওপর ভিত্তি করে নির্ধারিত: অক্টোবর 2026 অনুযায়ী, এতে 15টি দীর্ঘস্থায়ী কন্টেইনার এবং একটি প্রাথমিক ইনিশিয়ালাইজেশন টাস্ক অন্তর্ভুক্ত থাকে। আপনার আপলোড করা ডকুমেন্ট এবং ভেক্টর ইনডেক্সের জন্য পর্যাপ্ত ডিস্ক স্পেস রাখুন, এবং যদি সার্ভারে অন্য কোনো অ্যাপ্লিকেশন চলে তবে আরও বেশি মেমোরি বরাদ্দ করুন।

Dify-কে সরাসরি port 80-এ উন্মুক্ত করা কি নিরাপদ?

না। Dify-এর সাথে থাকা ওয়েব সার্ভারটি সাধারণ HTTP-তে কাজ করে, যা আপনার অ্যাডমিন লগইন এবং মডেল API কী-গুলোকে অরক্ষিত রাখে। এর সামনে একটি Let's Encrypt সার্টিফিকেটসহ reverse proxy ব্যবহার করুন, Dify-এর নিজস্ব পোর্টকে loopback-এ bind করুন এবং শুধুমাত্র HTTPS প্রক্সিকে ইন্টারনেটের মুখোমুখি রাখুন। এর সাথে IPv4 এবং IPv6 উভয়কেই কভার করে এমন একটি default-deny ফায়ারওয়াল ব্যবহার করুন।

আমি কীভাবে একটি self-hosted Dify আপডেট করব?

প্রথমে ডাটাবেসের ব্যাকআপ নিন, তারপর docker ডিরেক্টরি থেকে docker compose down চালান, এরপর git fetch --tags করুন, নতুন রিলিজ ট্যাগ দিয়ে git checkout করুন, তারপর docker compose pull এবং সবশেষে docker compose up -d চালান। রিলিজ নোটগুলো আগে পড়ে নিন, কারণ রিলিজভেদে আপগ্রেড পদ্ধতি ভিন্ন হতে পারে, ডাটাবেস মাইগ্রেশন অপরিবর্তনীয় হতে পারে এবং Dify মাঝে মাঝে নতুন .env ভেরিয়েবল যোগ করে, যার একটি অনুপস্থিত থাকলে কন্টেইনার চালু হতে বাধা পেতে পারে।

Dify ইনস্টল করার পর প্রথম কাজ কী?

/install ভিজিট করুন এবং অবিলম্বে অ্যাডমিন অ্যাকাউন্ট তৈরি করুন। যতক্ষণ পর্যন্ত এই অ্যাকাউন্টটি তৈরি না হয়, যে কেউ এই পেজে প্রবেশ করে এর নিয়ন্ত্রণ নিতে পারে। কন্টেইনারগুলো সচল হওয়ার সাথে সাথেই এবং ফায়ারওয়াল সবার জন্য উন্মুক্ত করার আগেই এটি সেটআপ করে নিন।