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-এর কম জায়গা রাখে এবং কথোপকথন বাড়ার সাথে সাথে কনটেক্সট ক্যাশ সেই জায়গা থেকেও মেমরি দখল করে নেয়। qwen3:8b যার আকার 5.2 GB, তা এই সার্ভারে একেবারেই চলবে না। ল্যাপটপ রিভিউগুলোতে এই পরিস্থিতি কখনোই আলোচনা করা হয় না, এবং এখানেই কয়েকশ মেগাবাইট দখল করা একটি চ্যাট ইন্টারফেস নির্ধারণ করে যে মডেলটি আদৌ চলবে কি না। আপনি যদি এই ট্যাগগুলোর চেয়ে অনেক বড় কোনো সার্ভারের আকার নির্ধারণ করেন, তবে শুধুমাত্র CPU-ভিত্তিক VPS-এ একটি 27B মডেলের হিসাব দেখায় যে ইন্টারফেসের মেমরি ব্যবহার কতটা দ্রুত গুরুত্বহীন হয়ে পড়ে।

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

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: প্রিফিক্সটি এটিকে লুপব্যাকে সীমাবদ্ধ রাখে। একটি 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 ফাইলে রাখুন। উভয় ফাইলই আনট্র্যাকড (untracked), তাই 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-তে কোনো ধরনের প্রমাণীকরণ (authentication) নেই। এর থেকে দুটি ব্রাউজার নিয়ম অনুসরণ করতে হয়। HTTPS-এর মাধ্যমে পরিবেশিত কোনো পেজ সাধারণ 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 tunnel-টি এই পুরো সমস্যার সমাধান করে: সেক্ষেত্রে পেজটি একটি localhost অরিজিনে চলে, যা Ollama ডিফল্টভাবে অনুমতি দেয় এবং পোর্টটি কখনোই সার্ভারের বাইরে উন্মুক্ত হয় না।

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

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 উত্তর পাওয়া মানে বিষয়টি আরও স্পষ্টভাবে নিশ্চিত হওয়া।

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

প্রথম পদ্ধতি: লুপব্যাক (loopback)-এ বাইন্ড করা এবং 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-কে লুপব্যাকেই রাখুন। এই পদ্ধতির নিরাপত্তা আপনার SSH সেটআপের ওপর নির্ভর করে, তাই এর সাথে key-only SSH এবং একটি হার্ডেনড sshd ব্যবহার করুন।

দ্বিতীয় পদ্ধতি: একটি reverse proxy যা অ্যাপের কাছে অনুরোধ পৌঁছানোর আগেই প্রমাণীকরণ সম্পন্ন করে। অ্যাপটিকে লুপব্যাকে রাখুন, পোর্ট 443-এর নিয়ন্ত্রণ প্রক্সির হাতে দিন এবং সামনে একটি single sign-on ব্যবস্থা যুক্ত করুন। Docker Compose লেবেল দ্বারা নিয়ন্ত্রিত 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 ছাড়া সাইন-আউট করলে টোকেনটি বাতিল হয় না: এটি মেয়াদ শেষ না হওয়া পর্যন্ত কার্যকর থাকে।

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

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

যদি আপনি ছাড়া অন্য কেউ এটি ব্যবহার করেন, তবে Open WebUI চালান। এতে প্রকৃত অ্যাকাউন্ট ব্যবস্থা রয়েছে, নতুন ব্যবহারকারীরা একটি অনুমোদন সারিতে (approval queue) যুক্ত হন এবং এর রক্ষণাবেক্ষণকারীরা হার্ডেনিং গাইডেন্স প্রকাশ করেন যা আপনি অনুসরণ করতে পারেন। যদি আপনার LDAP বা অ্যাডমিন প্যানেলের প্রয়োজন হয়, তবে LibreChat চালান এবং নিশ্চিত করুন যে docker stats ব্যবহার করে এর ছয়টি সার্ভিস এবং আপনার মডেলটি আসলেই আপনার সার্ভারে জায়গা করে নিতে পারবে কি না। যদি এটি একটি ছোট সার্ভারে একজন মাত্র ব্যবহারকারীর জন্য হয় এবং মডেলটি ইতিমধ্যে অধিকাংশ RAM দখল করে রাখে, তবে SSH টানেলের মাধ্যমে 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-সামঞ্জস্যপূর্ণ সার্ভারের জন্য OPENAI_API_BASE_URL ব্যবহার করুন, যার সাথে /v1 সাফিক্স এবং একটি নন-এম্পটি API কী থাকবে। 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 হয়, তবে ব্রাউজার সেটিকে mixed content হিসেবে ব্লক করে দেয়, ফলে Ollama অনুরোধটি পাওয়ার আগেই তা বাতিল হয়ে যায়। একটি systemctl edit ollama.service ওভাররাইডে উভয় ভেরিয়েবল সেট করুন, অথবা SSH-এর মাধ্যমে পোর্টটি ফরওয়ার্ড করুন, তাহলেই সমস্যার সমাধান হয়ে যাবে।