VPS-এর জন্য সেরা Open WebUI বিকল্পসমূহ

কোন Open WebUI বিকল্পটি VPS-এর জন্য উপযুক্ত

Open WebUI-এর বিকল্পগুলোকে সাধারণত ল্যাপটপের প্রেক্ষাপটে তুলনা করা হয়, যেখানে RAM সস্তা এবং কোনো কিছুই পাবলিক অ্যাড্রেসে লিসেন করে না। একটি VPS এই দুটি বাস্তবতাই বদলে দেয়, যা র‍্যাঙ্কিংকেও প্রভাবিত করে। যখনই দ্বিতীয় কোনো ব্যবহারকারী লগ ইন করেন, তখন Open WebUI-ই সঠিক ডিফল্ট পছন্দ হিসেবে থেকে যায়, কারণ এটি প্রকৃত ইউজার অ্যাকাউন্ট এবং একটি অ্যাডমিন প্যানেলসহ রিলিজ হয়। যখন ইন্টারফেসটি শেষ গিগাবাইট RAM-এর জন্য মডেলের সাথে প্রতিযোগিতা করে, তখন হালকা প্রজেক্টগুলো এগিয়ে থাকে। তবে এই সুবিধার মূল্য হলো অথেন্টিকেশন: সেগুলোতে কোনো অথেন্টিকেশন নেই।

নিচের সবকিছুই প্রতিটি প্রজেক্টের নিজস্ব ডকুমেন্টেশন থেকে নেওয়া হয়েছে, যা 2026 সালের আগস্ট মাসে পড়া হয়েছে। চারটি অক্ষ কেবল তখনই গুরুত্বপূর্ণ হয়ে ওঠে যখন সার্ভারটি ইন্টারনেট থেকে অ্যাক্সেসযোগ্য হয়।

পাবলিক IP-এর ক্ষেত্রে যে চারটি বিষয় গুরুত্বপূর্ণ

• মডেলের পাশে মেমোরি। মডেল সার্ভার হলো সার্ভারের সবচেয়ে ব্যয়বহুল প্রসেস। ইন্টারফেস যে পরিমাণ মেমোরি দখল করে, তা মডেলের জন্য বরাদ্দ মেমোরি থেকে কমে যায়।
• অথেন্টিকেশন। কিছু প্রজেক্টে ইউজার অ্যাকাউন্ট ও রোল থাকে। অন্যগুলো ধরে নেয় যে এটি আপনার ল্যাপটপে একা চলছে, তাই সেগুলোতে কোনো লগইন সিস্টেম থাকে না।
• রিমোট ইনফারেন্স। যে UI শুধুমাত্র 127.0.0.1:11434-এ পৌঁছাতে পারে, তা মডেলকে ইন্টারফেসের একই বক্সে থাকতে বাধ্য করে।
• রক্ষণাবেক্ষণ। একটি SQLite ফাইলসহ একটি কন্টেইনার পরিচালনা করা আর MongoDB ও ভেক্টর ডাটাবেসসহ ছয়টি কন্টেইনার পরিচালনা করা সম্পূর্ণ ভিন্ন কাজ।

মডেল ইন্টারফেসের জন্য কতটা RAM অবশিষ্ট রাখে

ইন্টারফেসটি সার্ভারের সবচেয়ে বড় অংশ নয়, বরং মডেলটিই সবচেয়ে বড়। প্রকাশিত ডাউনলোডের আকারগুলো আপনাকে একটি ন্যূনতম ধারণা দেয়, কারণ মডেলটি যখন উত্তর দেয় তখন এর ওয়েটগুলো (weights) মেমরিতে থাকতে হয়। এছাড়া কনটেক্সট ক্যাশ (context cache) বরাদ্দ হওয়ার পর প্রকৃত মেমরি ব্যবহারের পরিমাণ ডাউনলোডের আকারের চেয়ে বেশি হয়।

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

এগুলো হলো 2026 সালের আগস্ট মাসে Ollama লাইব্রেরি পেজে প্রকাশিত পরিসংখ্যান। এগুলো প্রকাশিত আকার, পরিমাপকৃত মান নয়। একটি 4 GB VPS-এ, qwen3:4b যার আকার 2.5 GB, তা অপারেটিং সিস্টেম এবং অন্যান্য কাজের জন্য 1.5 GB-এর কম জায়গা অবশিষ্ট রাখে। কথোপকথন দীর্ঘ হওয়ার সাথে সাথে কনটেক্সট ক্যাশ সেই জায়গা দখল করতে থাকে, আর এই কারণেই আপনার সেট করা num_ctx কেবল গুণগত মানের বিষয় নয়, বরং মেমরি ব্যবস্থাপনারও একটি সিদ্ধান্ত। qwen3:8b যার আকার 5.2 GB, তা ওই সার্ভারে কোনোভাবেই চলবে না। ল্যাপটপ রিভিউগুলোতে এই পরিস্থিতি কখনোই আলোচনা করা হয় না, অথচ এখানেই কয়েকশ মেগাবাইট দখল করা একটি চ্যাট ইন্টারফেস নির্ধারণ করে যে মডেলটি আদৌ চলবে কি না। আপনি যদি এই ট্যাগগুলোর চেয়ে বড় কোনো সার্ভার সাইজ করেন, তবে CPU-only VPS-এ 27B মডেলের হিসাব থেকে দেখা যায় যে, ইন্টারফেসের মেমরি ব্যবহারের বিষয়টি কত দ্রুত গুরুত্বহীন হয়ে পড়ে।

কোনো রিভিউয়ের সংখ্যার ওপর নির্ভর না করে নিজে পরিমাপ করুন। কন্টেইনার চালু হওয়ার এক মিনিট পর নয়, বরং প্রকৃত ব্যবহারের এক ঘণ্টা পর docker stats --no-stream চালান, কারণ যে মেমরি গুরুত্বপূর্ণ তা প্রথম ব্যবহারের সময় বরাদ্দ হয়। Ollama পাঁচ মিনিট নিষ্ক্রিয় থাকার পর ওয়েটগুলো রিলিজ করে দেয়, তাই কথোপকথনের মধ্যবর্তী সময়ে নেওয়া রিডিং প্রকৃত সর্বোচ্চ ব্যবহারকে কম করে দেখায়। ফলে পরবর্তী মেসেজ আসার সময় পুরো লোড আবার নতুন করে তৈরি হয়, যদি না আপনি keep_alive ব্যবহার করে মডেলটিকে মেমরিতে স্থায়ীভাবে রাখেন।

Open WebUI: একাধিক ব্যবহারকারীর জন্য ডিফল্ট হিসেবে এটিই সেরা

Open WebUI একটি মাত্র ইমেজ থেকে চলে এবং এর সমস্ত ডেটা একটি ভলিউমে সংরক্ষণ করে।

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

প্রজেক্টের README-তে দেওয়া কমান্ডটি -p 3000:8080 পাবলিশ করে, যা প্রতিটি ইন্টারফেসে লিসেন করে। 127.0.0.1: প্রিফিক্সটি এটিকে শুধুমাত্র লুপব্যাক (loopback)-এ সীমাবদ্ধ রাখে। একটি VPS-এর ক্ষেত্রে লাইনের অন্য যেকোনো কিছুর চেয়ে এই প্রিফিক্সটি বেশি গুরুত্বপূর্ণ, কারণ Docker নিজস্ব iptables রুল তৈরি করে এবং পাবলিশ করা পোর্ট আপনার ufw ডিনাই রুলগুলোকে উপেক্ষা করে।

নিচে বর্ণিত টানেল বা প্রক্সির মাধ্যমে পেজটিতে প্রবেশ করুন এবং প্রথম অ্যাকাউন্টটি তৈরি করুন। সেই অ্যাকাউন্টটিই অ্যাডমিনিস্ট্রেটর হিসেবে গণ্য হবে। পরবর্তীতে তৈরি করা অ্যাকাউন্টগুলো ডিফল্টভাবে pending রোল পায়, যা DEFAULT_USER_ROLE-এর ডকুমেন্টেশনে উল্লেখ করা ডিফল্ট সেটিংস। তাই কোনো অপরিচিত ব্যক্তি পেজটিতে প্রবেশ করলেও অ্যাডমিন অনুমোদন না দেওয়া পর্যন্ত আপনার মডেল ব্যবহার করতে পারবে না।

নিচে উল্লিখিত অন্যান্য প্রজেক্টের তুলনায় Open WebUI বেশি মেমরি খরচ করে, কারণ এর কাজের পরিধি বড়। এর নিজস্ব পারফরম্যান্স পেজে মেমরি খরচের কারণগুলো উল্লেখ করা আছে। ডিফল্ট এমবেডিং ইঞ্জিন কন্টেইনারের ভেতরে একটি sentence-transformers মডেল লোড করে, যা প্রতিটি ওয়ার্কার প্রসেসের জন্য প্রায় 500 MB মেমরি নেয়। RAG_EMBEDDING_ENGINE=ollama সেট করলে এই কাজটি আপনার চলমান মডেল সার্ভারের ওপর ন্যস্ত হয়। AUDIO_STT_ENGINE=webapi ব্যবহার করলে লোকাল স্পিচ-টু-টেক্সট মডেল লোড হওয়া বন্ধ থাকে। SQLite-এ DATABASE_POOL_SIZE আনসেট থাকলে পুলটি একটি বড় ইন্টারনাল সাইজে ফিরে যায় এবং প্রতিটি কানেকশন নিজস্ব পেজ ক্যাশ ও মেমরি ম্যাপ তৈরি করে। তাই ছোট সার্ভারের ক্ষেত্রে DATABASE_POOL_SIZE=8 এবং DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 সেট করুন। ENABLE_AUTOCOMPLETE_GENERATION=False ব্যবহার করলে ব্যবহারকারী টাইপ করার সময় ইন্টারফেসটি মডেলের কাছে কোনো কমপ্লিশন রিকোয়েস্ট পাঠাবে না।

LibreChat: মাল্টি-ইউজার, সাথে একটি স্ট্যাক

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

ইন্টারফেসটি 3080 পোর্টে কাজ করে। যখন আপনার কেবল একটি লগইন বক্স নয়, বরং একটি পূর্ণাঙ্গ আইডেন্টিটি সিস্টেম প্রয়োজন হয়, তখন LibreChat বিবেচনা করা উচিত: এটি LDAP এবং OAuth2 লগইন সমর্থন করে এবং এতে ইউজার ও রোলের জন্য একটি অ্যাডমিন প্যানেল রয়েছে। এই সক্ষমতাগুলো একটি স্ট্যাকের মাধ্যমে আসে।

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

ডিফল্ট compose ফাইলটি 6 টি সার্ভিস চালু করে: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API। এর কোনোটিই মডেল নয়। MongoDB এবং pgvector উভয়েরই নিজস্ব মেমোরি প্রয়োজন, এবং 4 GB র‍্যামের বক্সে এই মেমোরিটুকু মডেলের জন্য বরাদ্দ থাকা জরুরি।

আপগ্রেড করার প্রক্রিয়াটি একটি git অপারেশন, আর এখানেই মানুষ ভুল করে থাকে।

docker compose down
git pull
docker compose pull
docker compose up -d

আপনি যদি ট্র্যাক করা docker-compose.yml ফাইলটি এডিট করেন, তবে git pull একটি কনফ্লিক্ট বা দ্বন্দ্বের কারণে আটকে যাবে এবং আপগ্রেডটি অসম্পূর্ণ থেকে যাবে। আপনার পরিবর্তনগুলো docker-compose.override.yml ফাইলে রাখুন, যা এই কাজের জন্যই প্রজেক্টে দেওয়া হয়েছে, এবং সিক্রেটগুলো .env ফাইলে রাখুন। ফাইল দুটি ট্র্যাক করা হয় না, তাই git pull এগুলোর কোনো পরিবর্তন করে না।

librechat.yaml ফাইলে একটি কাস্টম এন্ডপয়েন্ট ব্যবহার করে LibreChat-কে আপনার নিজস্ব মডেল সার্ভারের দিকে নির্দেশ করুন।

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

model-host-কে Ollama চলমান বক্সের ঠিকানায় প্রতিস্থাপন করুন। apiKey ফিল্ডটি থাকা বাধ্যতামূলক, যদিও Ollama এর মান উপেক্ষা করে, তাই একটি প্লেসহোল্ডার ব্যবহার করলেই চলবে। যদি LibreChat ডকারে চলে এবং Ollama একই মেশিনে চলে, তবে কন্টেইনারের ভেতরে localhost বলতে কন্টেইনার নিজেকেই বোঝায়, তাই সেখানে host.docker.internal ব্যবহার করুন।

Hollama এবং OrionChat: ব্রাউজারই সব কাজ করে

Hollama একটি ছোট কন্টেইনার থেকে ব্রাউজার অ্যাপ্লিকেশন পরিবেশন করে। চ্যাটগুলো সার্ভারে নয়, বরং আপনার ব্রাউজারের স্টোরেজে থাকে।

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

এই কমান্ডের README সংস্করণে --rm ব্যবহার করা হয়েছে, যা বন্ধ হওয়ার সাথে সাথে কন্টেইনারটি মুছে ফেলে, ফলে রিবুট করার পর ইন্টারফেসটি আর ফিরে আসে না। একটি reverse proxy-এর পেছনে এটি চালানোর সময় -e VITE_ALLOWED_HOSTS='chat.example.com' যোগ করুন, কারণ ইমেজটি শুধুমাত্র হোস্ট localhost-কে অনুমতি দেয় এবং অন্য কোনো হোস্টনামের অনুরোধ আসলে অ্যাপের পরিবর্তে blocked-host এরর দেখায়।

OrionChat আরও এক ধাপ এগিয়ে, এর কোনো সার্ভার কম্পোনেন্টই নেই। রিপোজিটরি ক্লোন করে আপনার চলমান ওয়েব সার্ভার দিয়ে ফোল্ডারটি পরিবেশন করুন, অথবা সরাসরি ডিস্ক থেকে index.html ওপেন করুন। API কি ব্রাউজারের localStorage-এ সংরক্ষিত থাকে, চ্যাট হিস্ট্রি ব্রাউজারেই থেকে যায় এবং চ্যাটের সংখ্যা 512 ছাড়িয়ে গেলে অ্যাপটি সবচেয়ে পুরনো চ্যাটগুলো মুছে ফেলে।

এই প্রজেক্টগুলোর কোনোটিতেই লগইন নেই, কারণ কোনোটিতেই এমন সার্ভার নেই যা লগইন যাচাই করতে পারে। ল্যাপটপের ক্ষেত্রে এটি ঠিক আছে। কিন্তু VPS-এর ক্ষেত্রে এর অর্থ হলো, পেজটি কখনোই 0.0.0.0-এ পাবলিশ করা যাবে না এবং একটি গুরুত্বপূর্ণ বিষয় যা এড়িয়ে যাওয়া সহজ: ব্রাউজার সরাসরি মডেলকে কল করে, সার্ভারকে নয়।

এই একটি তথ্যই নির্ধারণ করে যে এই দুটি কোথায় ব্যবহারযোগ্য। আপনার ব্রাউজারকে সরাসরি Ollama-এর কাছে পৌঁছাতে হয়, তাই Ollama-কে loopback-এর বাইরে listen করতে হয় এবং Ollama-তে কোনো ধরনের অথেন্টিকেশন নেই। এর ফলে দুটি ব্রাউজার নিয়ম কার্যকর হয়। HTTPS-এর মাধ্যমে পরিবেশিত কোনো পেজ plain HTTP এন্ডপয়েন্টকে কল করতে পারে না এবং কনসোলে Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked. প্রিন্ট হয়। অন্য যেকোনো অরিজিনের কল has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource দিয়ে প্রত্যাখ্যান করা হয়, যতক্ষণ না আপনি সেই অরিজিনকে অনুমতি দিচ্ছেন।

Ollama-এর ডকুমেন্টেশনে এই সেটিংস পরিবর্তনের উপায় হলো একটি systemd override।

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss এখন 0.0.0.0:11434 প্রিন্ট করা উচিত, যেখানে আগে 127.0.0.1:11434 প্রিন্ট হতো। এই পরিবর্তনটি তখনই করুন যখন কোনো ফায়ারওয়াল বা অথেন্টিকেটিং প্রক্সি ইতিমধ্যে নিয়ন্ত্রণ করছে যে কারা এই পোর্টে পৌঁছাতে পারবে, কারণ একটি উন্মুক্ত 11434 পোর্ট মানেই একটি উন্মুক্ত মডেল সার্ভার এবং ম্যাস স্ক্যানাররা খুব দ্রুত নতুন পাবলিক পোর্ট খুঁজে বের করে। নিচের SSH টানেলটি এই পুরো সমস্যাটি এড়িয়ে যায়: সেক্ষেত্রে পেজটি একটি localhost অরিজিনে চলে, যা Ollama ডিফল্টভাবেই অনুমতি দেয় এবং পোর্টটি কখনোই বক্সের বাইরে যায় না।

প্রতিটি কি একটি রিমোট Ollama বা vLLM endpoint ব্যবহার করতে পারে

Open WebUI এটি করতে পারে এবং সংযোগটি সার্ভার সাইড থেকে তৈরি হয়। OLLAMA_BASE_URL=http://model-host:11434 এটিকে Ollama-এর দিকে নির্দেশ করে। vLLM বা অন্য যেকোনো OpenAI-সামঞ্জস্যপূর্ণ সার্ভারের জন্য, একটি নন-এম্পটি OPENAI_API_KEY সহ OPENAI_API_BASE_URL=http://model-host:8000/v1 সেট করুন এবং /v1 সাফিক্সটি বজায় রাখুন, যা বাধ্যতামূলক। OPENAI_API_BASE_URLS সেমিকোলন দ্বারা পৃথক করা একাধিক ব্যাকএন্ড গ্রহণ করে।

LibreChat উপরে দেখানো কাস্টম এন্ডপয়েন্টের baseURL-এর মাধ্যমে এটি করতে পারে। সেই অনুরোধটিও সার্ভার থেকে বেরিয়ে যায়, তাই কোনো ব্রাউজার রুল এখানে প্রযোজ্য নয়। একই বেস URL এবং একই প্লেসহোল্ডার কি চ্যাট উইন্ডোর বাইরেও কাজ করে, যা আপনার হোস্ট করা মডেলে একটি কোডিং এজেন্টকে নির্দেশ করার জন্য যথেষ্ট।

Hollama এবং OrionChat তাদের সেটিংসে আপনার টাইপ করা যেকোনো এন্ডপয়েন্টের দিকে নির্দেশ করতে পারে, কিন্তু অনুরোধটি আপনার ব্রাউজার থেকে বেরিয়ে যায়। উপরের সেকশনের সবকিছু তাদের ক্ষেত্রে প্রযোজ্য এবং এখানে অন্য কোনোটির ক্ষেত্রে নয়।

ইন্টারফেসকে মডেল থেকে আলাদা করা হলো রিমোট এন্ডপয়েন্ট ব্যবহারের সবচেয়ে বড় সুবিধা। ইন্টারফেসটিকে একটি ছোট বক্সে রাখুন এবং মডেলটিকে সেখানে রাখুন যেখানে পর্যাপ্ত মেমোরি আছে। এটি সেই পয়েন্ট যেখানে আপনাকে সিদ্ধান্ত নিতে হবে Ollama নাকি vLLM অনুরোধগুলো সার্ভ করবে, কারণ যখন একাধিক ব্যক্তি একসাথে মডেলের সাথে কথা বলে তখন এই দুটির আচরণ খুব ভিন্ন হয়। যদি মডেল সার্ভারটি এখনো তৈরি না হয়ে থাকে, তবে VPS-এ Ollama চালানো দিয়ে শুরু করুন, এবং শুধুমাত্র CPU-যুক্ত বক্সে রানার বেছে নেওয়ার আগে Ollama এবং llama.cpp-এর তুলনা পড়ুন।

লগইন ছাড়া কোনো চ্যাট UI কখনোই 0.0.0.0-তে প্রকাশ করবেন না

Open WebUI-এর হার্ডেনিং পেজে বলা হয়েছে যে, এই প্রজেক্টটি "ব্যক্তিগত ও বিশ্বস্ত নেটওয়ার্কের জন্য তৈরি, যেমনটা ডাটাবেস, কন্টেইনার রেজিস্ট্রি বা CI সার্ভারের মতো অন্যান্য self-hosted অবকাঠামোর ক্ষেত্রে হয়"। তারা এটিকে VPN-এর পেছনে অথবা প্রমাণীকরণসহ (authentication) কোনো reverse proxy-র পেছনে রাখার পরামর্শ দেয়। যে প্রজেক্টে কোনো লগইন ব্যবস্থাই নেই, সেটিকে অন্তত একই পর্যায়ের নিরাপত্তা দেওয়া উচিত।

কোনো কিছুতে আস্থা রাখার আগে সেটি কোথায় listen করছে তা যাচাই করুন।

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

127.0.0.1:3000 লেখা একটি লাইন থাকা মানে আপনি নিরাপদ। 0.0.0.0:3000 লেখা একটি লাইন থাকার অর্থ হলো আপনার চ্যাট ইন্টারফেসটি পাবলিক ইন্টারনেটে উন্মুক্ত। আপনার নিজের মেশিন থেকে curl -sI http://YOUR.VPS.IP:3000 কমান্ডটি চালিয়ে HTTP/1.1 200 OK উত্তর পাওয়া গেলে সেটি আরও স্পষ্টভাবে একই কথা বলে।

WEBUI_AUTH=False ব্যবহার করে Open WebUI-এর লগইন বন্ধ করা কেবল এমন একক ব্যবহারকারীর মেশিনের জন্য প্রযোজ্য, যেখানে অন্য কেউ পৌঁছাতে পারে না। এছাড়া, যেসব ইনস্টলেশনে আগে থেকেই অ্যাকাউন্ট রয়েছে, সেখানে এটি কার্যকর হয় না এবং You can't turn off authentication because there are existing users. বার্তাটি দেখায়।

প্যাটার্ন এক: loopback-এ bind করা এবং SSH-এর মাধ্যমে অ্যাক্সেস করা। প্রতিটি পোর্ট 127.0.0.1-তে প্রকাশ করুন, তারপর আপনার প্রয়োজনীয় পোর্টটি ফরওয়ার্ড করুন: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, এবং আপনার ল্যাপটপে http://localhost:3000 খুলুন। যেহেতু কিছুই পাবলিকলি প্রকাশ করা হয়নি, তাই কেউ এটি স্ক্যান করতে পারবে না। Hollama বা OrionChat-এর ক্ষেত্রে, একই কমান্ডে -L 11434:127.0.0.1:11434 ব্যবহার করে মডেল পোর্টটি ফরওয়ার্ড করুন এবং Ollama-কে loopback-এ রেখে দিন। এই প্যাটার্নের শক্তি আপনার SSH সেটআপের ওপর নির্ভর করে, তাই এর সাথে key-only SSH এবং একটি সুরক্ষিত sshd ব্যবহার করুন।

প্যাটার্ন দুই: এমন একটি reverse proxy যা অ্যাপের কাছে অনুরোধ পৌঁছানোর আগেই প্রমাণীকরণ সম্পন্ন করে। অ্যাপটিকে loopback-এ রাখুন, proxy-কে পোর্ট 443-এর নিয়ন্ত্রণ দিন এবং এর সামনে single sign-on বসান। Docker Compose label দ্বারা পরিচালিত Traefik এবং পরিচয় প্রদানকারী হিসেবে Authentik ব্যবহার করলে সার্ভারের প্রতিটি অ্যাপের জন্য একটি লগইন এবং একটি সার্টিফিকেট থাকে। Open WebUI-কে TLS (transport layer security)-এর পেছনে রাখলে WEBUI_SESSION_COOKIE_SECURE=true এবং WEBUI_SESSION_COOKIE_SAME_SITE=strict সেট করুন। JWT_EXPIRES_IN-এর ডিফল্ট চার সপ্তাহের সময়সীমা কমিয়ে আনুন, কারণ Open WebUI-এর ডকুমেন্টেশন অনুযায়ী Redis ছাড়া সাইন-আউট করলে টোকেনটি বাতিল হয় না: এটি মেয়াদ শেষ না হওয়া পর্যন্ত কার্যকর থাকে।

প্যাটার্ন দুই ব্রাউজার-ভিত্তিক প্রজেক্টগুলোকে রক্ষা করতে পারে না। পেজের সামনে থাকা একটি proxy মডেল এন্ডপয়েন্টকে সুরক্ষা দেয় না এবং সেই পেজ থেকে ভিন্ন কোনো hostname-এ fetch করলে আপনার session cookie সেখানে যায় না। ফলে Ollama-এর সামনে থাকা প্রমাণীকরণকারী proxy লগইন ফর্মের দিকে redirect করে এবং চ্যাটটি ব্যর্থ হয়। হয় মডেল এন্ডপয়েন্টটিকে পেজের একই hostname-এর অধীনে রুট করুন, অথবা প্যাটার্ন এক ব্যবহার করুন।

কোনটি বেছে নেবেন

যদি আপনি ছাড়া অন্য কেউ এটি ব্যবহার করেন, তবে Open WebUI চালান। এতে প্রকৃত অ্যাকাউন্ট ব্যবস্থা রয়েছে, নতুন ব্যবহারকারীরা একটি অনুমোদন সারিতে (approval queue) যুক্ত হন এবং এর রক্ষণাবেক্ষণকারীরা এমন হার্ডেনিং নির্দেশিকা প্রকাশ করেন যা আপনি অনুসরণ করতে পারেন। যদি আপনার LDAP বা অ্যাডমিন প্যানেলের প্রয়োজন হয়, তবে LibreChat চালান এবং নিশ্চিত করুন যে docker stats ব্যবহার করে এর ছয়টি সার্ভিস এবং আপনার মডেলটি আসলেই আপনার সার্ভারে জায়গা করে নিতে পারবে কি না। যদি এটি একটি ছোট সার্ভারে একজন মাত্র ব্যবহারকারীর জন্য হয় এবং মডেলটি ইতিমধ্যে অধিকাংশ RAM দখল করে রাখে, তবে SSH tunnel-এর মাধ্যমে Hollama বা OrionChat পরিবেশন করুন এবং ব্রাউজারকে স্টেট ধরে রাখতে দিন। একটি VPS-এ ভুল সিদ্ধান্ত হলো এগুলোর যেকোনো একটিকে কোনো লগইন ব্যবস্থা ছাড়া সরাসরি 0.0.0.0-এ উন্মুক্ত করে রাখা।

FAQ

Open WebUI সরাসরি পাবলিক IP-তে এক্সপোজ করা কি নিরাপদ?

এর নিজস্ব হার্ডেনিং পেজে এটিকে একটি ডাটাবেস বা CI সার্ভারের মতো ব্যক্তিগত এবং বিশ্বস্ত নেটওয়ার্কের জন্য তৈরি সফটওয়্যার হিসেবে বর্ণনা করা হয়েছে। এতে প্রকৃত ইউজার অ্যাকাউন্ট ব্যবস্থা রয়েছে এবং প্রথম অ্যাকাউন্টটি অ্যাডমিনিস্ট্রেটর হিসেবে কাজ করে, যেখানে পরবর্তী অ্যাকাউন্টগুলো অনুমোদিত না হওয়া পর্যন্ত pending থাকে; তাই এটি লগইনহীন UI-এর চেয়ে অনেক বেশি নিরাপদ। তবুও এটিকে TLS সহ একটি reverse proxy-এর পেছনে রাখুন এবং সম্ভব হলে single sign-on ব্যবহার করুন। কন্টেইনার পোর্টটিকে 127.0.0.1:3000:8080 হিসেবে পাবলিশ করুন যাতে Docker-এর নিজস্ব iptables রুল আপনার অজান্তে সেটিকে ইন্টারনেটে উন্মুক্ত করতে না পারে।

VPS-এ কোন Open WebUI বিকল্পটি সবচেয়ে কম RAM ব্যবহার করে?

ব্রাউজার-ভিত্তিক Hollama এবং OrionChat সবচেয়ে কম RAM ব্যবহার করে, কারণ অ্যাপ্লিকেশনটি ক্লায়েন্ট সাইডে চলে। সার্ভার শুধুমাত্র স্ট্যাটিক ফাইল পাঠায় এবং OrionChat-এর জন্য কোনো অ্যাপ্লিকেশন কন্টেইনারের প্রয়োজনই হয় না। Open WebUI একটি Python প্রসেস, একটি ডাটাবেস এবং ডিফল্টভাবে একটি লোকাল এম্বেডিং মডেল মেমরিতে রাখে, যা শুধুমাত্র এম্বেডিং মডেলের জন্যই প্রতি ওয়ার্কার প্রায় 500 MB মেমরি খরচ করে। আপনার নিজের সার্ভারে docker stats --no-stream ব্যবহার করে এই সংখ্যাগুলো যাচাই করুন, কারণ আপনি যে ফিচারগুলো চালু করবেন তার ওপর ভিত্তি করে এই ব্যবহার পরিবর্তিত হতে পারে।

এই চ্যাট UI গুলো কি অন্য হোস্টের Ollama সার্ভার ব্যবহার করতে পারে?

Open WebUI এবং LibreChat এটি করতে পারে এবং তাদের সার্ভারই সংযোগটি তৈরি করে, তাই ব্রাউজারের কোনো রুল এখানে প্রযোজ্য নয়। Open WebUI-এর জন্য OLLAMA_BASE_URL সেট করুন, অথবা LibreChat-এর কাস্টম এন্ডপয়েন্টে baseURL ব্যবহার করুন। vLLM বা অন্য কোনো OpenAI-সামঞ্জস্যপূর্ণ সার্ভারের জন্য /v1 সাফিক্স সহ OPENAI_API_BASE_URL ব্যবহার করুন এবং একটি নন-এম্পটি API কি (key) প্রদান করুন। Hollama এবং OrionChat যেকোনো ঠিকানায় পয়েন্ট করা যেতে পারে, তবে অনুরোধটি আপনার ব্রাউজার থেকে আসে, তাই এন্ডপয়েন্টটি অবশ্যই আপনার ব্রাউজার থেকে অ্যাক্সেসযোগ্য হতে হবে।

আমার ব্রাউজার চ্যাট UI কেন Ollama-তে পৌঁছাতে পারছে না?

দুটি কারণে সাধারণত এমনটি ঘটে। Ollama ডিফল্টভাবে 127.0.0.1:11434-এ বাইন্ড করে, তাই অন্য মেশিনের ব্রাউজার এটিকে খুঁজে পায় না যতক্ষণ না OLLAMA_HOST পরিবর্তন করা হয়। এছাড়া, Ollama শুধুমাত্র localhost থেকে ক্রস-অরিজিন অনুরোধ গ্রহণ করে, তাই আপনার নিজস্ব ডোমেইন থেকে পরিবেশিত কোনো পেজকে No 'Access-Control-Allow-Origin' header is present on the requested resource দিয়ে প্রত্যাখ্যান করা হয় যতক্ষণ না সেই অরিজিনটি OLLAMA_ORIGINS-এ তালিকাভুক্ত করা হয়। যদি পেজটি HTTPS হয় এবং এন্ডপয়েন্টটি HTTP হয়, তবে ব্রাউজার সেটিকে মিক্সড কন্টেন্ট হিসেবে ব্লক করে দেয়, যা Ollama-এর কাছে পৌঁছানোর আগেই ঘটে। উভয় ভেরিয়েবল একটি systemctl edit ollama.service ওভাররাইডে সেট করুন, অথবা SSH-এর মাধ্যমে পোর্টটি ফরওয়ার্ড করুন, তাহলেই সমস্যার সমাধান হয়ে যাবে।