VPS साठी Open WebUI चे योग्य पर्याय कोणते?

VPS वर कोणता Open WebUI पर्याय योग्य आहे

Open WebUI च्या पर्यायांची तुलना जवळजवळ नेहमी laptop वर केली जाते. तिथे RAM स्वस्त असते आणि कोणतीही सेवा public address वर listening करत नसते. VPS मध्ये ही दोन्ही परिस्थिती बदलतात. त्यामुळे क्रमवारीही बदलते. दुसरी व्यक्ती login करताच Open WebUI हा योग्य default पर्याय ठरतो, कारण त्यात प्रत्यक्ष user accounts आणि admin panel उपलब्ध असतात. Interface ला model सोबत RAM मधील शेवटच्या gigabyte साठी स्पर्धा करावी लागत असेल, तर हलके projects अधिक योग्य ठरतात. मात्र त्यासाठी authentication सोडावे लागते. त्यांच्यात authentication नसते.

खालील सर्व माहिती प्रत्येक project च्या स्वतःच्या documentation मधून घेतली आहे. ती August 2026 मध्ये वाचली होती. हे चार निकष server इंटरनेटवरून reachable झाल्यानंतरच महत्त्वाचे ठरतात.

सार्वजनिक IP वरच महत्त्वाचे ठरणारे चार पैलू

• मॉडेलच्या शेजारी असलेली मेमरी. या मशीनवरील सर्वाधिक संसाधने वापरणारी प्रक्रिया म्हणजे model server. Interface ने वापरलेला प्रत्येक megabyte म्हणजे मॉडेलला उपलब्ध नसलेला एक megabyte.
• प्रमाणीकरण. यापैकी काही प्रकल्पांमध्ये user accounts आणि roles असतात. इतर प्रकल्प असे गृहीत धरतात की तुमच्या laptop वर त्यांच्याशिवाय दुसरे काहीही चालत नाही; त्यामुळे त्यांमध्ये login ची सुविधाच नसते.
• Remote inference. फक्त 127.0.0.1:11434 पर्यंत पोहोचू शकणारा UI मॉडेलला interface असलेल्या त्याच मशीनवर चालवण्यास भाग पाडतो.
• देखभाल. SQLite file असलेला एक container आणि त्यामागे MongoDB तसेच vector database असलेले सहा containers यांची देखभालीची जबाबदारी वेगळी असते.

मॉडेल interface साठी किती RAM उरवतो

या मशीनवरील सर्वांत मोठा घटक interface नाही. तो मॉडेल आहे. प्रकाशित download size हा किमान अंदाज देतो, कारण मॉडेल उत्तर देत असताना weights memory मध्ये उपलब्ध असणे आवश्यक असते. Context cache allocate झाल्यानंतर प्रत्यक्ष memory वापर download size पेक्षा जास्त असतो.

[
  {
    "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"
  }
]

ही आकडेवारी Ollama library pages वर August 2026 मध्ये प्रदर्शित झाली होती. हे प्रकाशित sizes आहेत, मोजमाप नाहीत. 4 GB VPS वर qwen3:4b साठी 2.5 GB लागतात. त्यामुळे operating system आणि इतर सर्व घटकांसाठी 1.5 GB पेक्षा कमी RAM उरते. Conversation वाढत असताना context cache ही RAM वापरते. म्हणून तुम्ही सेट केलेला num_ctx हा quality इतकाच memory चा निर्णयही असतो. qwen3:8b साठी 5.2 GB लागतात, त्यामुळे ते त्या मशीनवर अजिबात चालत नाही. Laptop roundups मध्ये ही परिस्थिती सहसा दिसत नाही. काहीशे megabytes memory वापरणारा chat interface मॉडेल चालेल की नाही हे ठरवू शकतो. या tags पेक्षा बरेच मोठे मॉडेल चालवण्यासाठी मशीनची क्षमता ठरवत असाल, तर CPU-only VPS वर 27B मॉडेलसाठीचे गणित interface हा निर्णायक आकडा किती लवकर राहत नाही हे दाखवते.

Roundup मधील कोणत्याही आकड्यावर, यासह, विश्वास ठेवण्याऐवजी प्रत्यक्ष मोजमाप करा. प्रत्यक्ष वापर सुरू झाल्यानंतर एक तासाने docker stats --no-stream चालवा. Container सुरू झाल्यानंतर एक मिनिटाने मोजमाप करू नका, कारण महत्त्वाची memory पहिल्यांदा वापर होताना allocate केली जाते. Ollama पाच मिनिटे idle राहिल्यानंतर weights release करते. त्यामुळे conversations मधील अंतरात घेतलेले मोजमाप peak memory कमी दाखवते. keep_alive वापरून मॉडेल resident ठेवले नसेल, तर पुढील message वेळी संपूर्ण model load पुन्हा करावा लागतो.

Open WebUI: एकापेक्षा जास्त वापरकर्त्यांसाठी अजूनही मूलभूत पर्याय

Open WebUI एका image मधून चालते आणि तिचा डेटा एका volume मध्ये ठेवते.

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 मधील command -p 3000:8080 प्रकाशित करते. त्यामुळे ते प्रत्येक interface वर listen करते. 127.0.0.1: prefix वापरल्यास ते loopback पुरते मर्यादित राहते. VPS वर या ओळीतील इतर कोणत्याही घटकापेक्षा हा prefix अधिक महत्त्वाचा आहे, कारण Docker स्वतःचे iptables rules लिहिते आणि प्रकाशित केलेला port तुमचे ufw deny rules दुर्लक्षित करतो.

खाली वर्णन केलेल्या tunnel किंवा proxy द्वारे page उघडा आणि नंतर पहिले account तयार करा. हे account administrator बनते. त्यानंतरची signups pending role सह तयार होतात. DEFAULT_USER_ROLE हा documented default आहे. त्यामुळे page पर्यंत पोहोचलेला अनोळखी वापरकर्ता administrator ने मंजुरी देईपर्यंत तुमचे model वापरू शकत नाही.

खालील प्रकल्पांपेक्षा Open WebUI अधिक memory वापरते, कारण ती अधिक कामे करते. तिच्या performance page मध्ये memory वापर वाढवणारे घटक नमूद केले आहेत. Default embedding engine container मध्ये sentence-transformers model load करते. प्रत्येक worker process साठी साधारण 500 MB memory लागते, असे documentation मध्ये नमूद आहे. RAG_EMBEDDING_ENGINE=ollama सेट केल्यास हे काम तुम्ही आधीच चालवत असलेल्या model server कडे सोपवले जाते. AUDIO_STT_ENGINE=webapi सेट केल्यास स्थानिक speech-to-text model load होत नाही. SQLite वापरताना DATABASE_POOL_SIZE unset असल्यास pool मोठ्या internal size वर fallback होतो. प्रत्येक connection स्वतःचा page cache आणि memory map वाढवते. त्यामुळे लहान server वर DATABASE_POOL_SIZE=8 आणि DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 सेट करा. ENABLE_AUTOCOMPLETE_GENERATION=False सेट केल्यास वापरकर्ता अजून typing करत असताना interface model कडे completion मागत नाही.

LibreChat: अनेक वापरकर्त्यांसाठी, त्यामागे stack

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

इंटरफेस port 3080 वर प्रतिसाद देतो. login box ऐवजी identity system आवश्यक असेल, तेव्हा LibreChat वापरा. यामध्ये LDAP आणि OAuth2 login ची माहिती दिली आहे. तसेच users आणि roles साठी admin panel समाविष्ट आहे. ही सुविधा एका stack सोबत येते.

[
  {
    "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 file 6 services सुरू करते: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. यापैकी एकही service model नाही. MongoDB आणि pgvector या दोन्हींना स्वतंत्र memory आवश्यक असते. 4 GB मशीनवर ही memory model साठी उपलब्ध राहात नाही.

Upgrades ही git operation असते. याच ठिकाणी अनेकदा चूक होते.

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

git pull मध्ये tracked docker-compose.yml संपादित केले असल्यास conflict मुळे प्रक्रिया थांबते आणि upgrade अर्धवट लागू होते. तुमचे बदल docker-compose.override.yml मध्ये ठेवा. यासाठी project ही file उपलब्ध करून देतो. Secrets .env मध्ये ठेवा. दोन्ही files untracked आहेत. त्यामुळे git pull त्यांना बदलत नाही.

librechat.yaml मध्ये custom endpoint देऊन LibreChat ला तुमच्या model server कडे निर्देशित करा.

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 चालणाऱ्या मशीनचा address द्या. apiKey field असणे आवश्यक आहे, जरी Ollama त्याची value दुर्लक्षित करत असले तरी. त्यामुळे placeholder वापरू शकता. LibreChat Docker मध्ये आणि Ollama त्याच मशीनवर चालत असल्यास, container मधील localhost चा अर्थ तो container स्वतः असा होतो. त्यामुळे तेथे host.docker.internal वापरा.

Hollama आणि OrionChat: काम browser करतो

Hollama एका छोट्या container मधून browser application उपलब्ध करून देतो. Chats server वर नाही, तर तुमच्या browser च्या storage मध्ये साठवले जातात.

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

या command च्या README आवृत्तीत --rm वापरले आहे. Container थांबल्यावर ते container delete करते. त्यामुळे reboot नंतर interface पुन्हा उपलब्ध होत नाही. Reverse proxy मागे चालवताना -e VITE_ALLOWED_HOSTS='chat.example.com' जोडा. Image मध्ये फक्त host localhost अनुमत आहे. त्यामुळे इतर कोणत्याही hostname साठी आलेल्या request ला app ऐवजी blocked-host error मिळतो.

OrionChat यापेक्षा पुढे जाते आणि त्यात server component अजिबात नाही. Repository clone करा आणि आधीपासून चालू असलेल्या web server ने तो folder serve करा. किंवा disk वरील index.html उघडा. API keys browser च्या localStorage मध्ये साठवल्या जातात. Chat history browser मध्येच राहते. Chats ची संख्या 512 पेक्षा जास्त झाल्यावर app सर्वांत जुने chats delete करते.

दोन्ही project मध्ये login नाही. कारण login तपासू शकेल असा server त्यांच्याकडे नाही. Laptop वर ही बाब ठीक आहे. VPS वर याचा अर्थ असा की page कधीही 0.0.0.0 वर publish करू नये. आणखी एक सहज दुर्लक्षित होणारी बाब अशी आहे: model ला call server नाही, तर browser करतो.

हीच बाब ठरवते की हे दोन्ही project कुठे वापरता येतील. तुमच्या browser ला Ollama पर्यंत थेट पोहोचावे लागते. त्यामुळे Ollama ने loopback व्यतिरिक्त इतर interface वरही listen केले पाहिजे. Ollama मध्ये कोणत्याही प्रकारचे authentication नाही. यावरून browser संबंधी दोन नियम लागू होतात. HTTPS वर serve केलेले page plain HTTP endpoint ला call करू शकत नाही. तसेच console मध्ये 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. दिसते. इतर कोणत्याही origin ला केलेली call has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource सह नाकारली जाते, जोपर्यंत तो origin तुम्ही अनुमत करत नाही.

यापैकी कोणतीही setting बदलण्यासाठी Ollama ची documented पद्धत म्हणजे 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

पूर्वी 127.0.0.1:11434 दाखवत असलेल्या ठिकाणी आता ss ने 0.0.0.0:11434 दाखवले पाहिजे. Firewall किंवा authentication करणारा proxy port पर्यंत कोण पोहोचू शकतो हे आधीच नियंत्रित करत असेल, तेव्हाच हा बदल करा. Open 11434 म्हणजे open model server. Mass scanners नवीन public port पर्यंत लवकर पोहोचतात. खालील SSH tunnel हा संपूर्ण प्रश्न टाळतो. त्यानंतर page localhost origin वर चालते, जो Ollama default ने अनुमत करतो. तसेच port box च्या बाहेर जात नाही.

प्रत्येक अॅप remote Ollama किंवा vLLM endpoint वापरू शकते का

Open WebUI हे करू शकते आणि connection server side वरून केली जाते. OLLAMA_BASE_URL=http://model-host:11434 द्वारे ते Ollama कडे निर्देशित करता येते. vLLM किंवा इतर कोणत्याही OpenAI-compatible server साठी, non-empty OPENAI_API_KEY सह OPENAI_API_BASE_URL=http://model-host:8000/v1 सेट करा आणि /v1 suffix कायम ठेवा; तो आवश्यक आहे. OPENAI_API_BASE_URLS मध्ये semicolon ने विभक्त केलेले अनेक backends स्वीकारले जातात.

LibreChat हे वरील custom endpoint च्या baseURL द्वारे वापरता येते. ती request देखील server बाहेरून पाठवली जाते, त्यामुळे browser rule लागू होत नाही. Chat window च्या बाहेरही तोच base URL आणि तोच placeholder key कार्य करतात. त्यामुळे तुम्ही आधीपासून host केलेल्या model कडे coding agent निर्देशित करू शकता.

Hollama आणि OrionChat मध्ये settings मध्ये टाइप केलेल्या कोणत्याही endpoint कडे निर्देश करता येतो; मात्र request तुमच्या browser मधून बाहेर जाते. वरील section मधील सर्व बाबी त्यांनाही लागू होतात; या section मधील इतर कोणत्याही अॅपला त्या लागू होत नाहीत.

Interface आणि model वेगळे ठेवणे हा remote endpoint चा सर्वात उपयुक्त फायदा आहे. Interface एका छोट्या box वर ठेवा आणि memory उपलब्ध असलेल्या ठिकाणी model ठेवा. अनेक लोक एकाच वेळी model शी संवाद साधतात तेव्हा Ollama आणि vLLM यांचे वर्तन लक्षणीयरीत्या वेगळे असते. त्यामुळे requests serve करण्यासाठी Ollama किंवा vLLM यापैकी कोणते वापरायचे ते ठरवण्याची हीच योग्य वेळ आहे. Model server अद्याप उपलब्ध नसेल, तर प्रथम VPS वर Ollama चालवा. CPU-only box असल्यास runner निवडण्यापूर्वी Ollama ची llama.cpp शी तुलना कशी होते ते वाचा.

0.0.0.0 वर login नसलेला chat UI कधीही प्रकाशित करू नका

Open WebUI च्या hardening पृष्ठावर हा प्रकल्प “databases, container registries आणि CI servers सारख्या इतर self-hosted infrastructure प्रमाणे private, trusted networks साठी तयार केलेला आहे” असे नमूद केले आहे. तसेच तो VPN मागे किंवा authentication असलेल्या reverse proxy मागे ठेवण्यास सांगतो. पूर्णपणे login नसलेल्या प्रकल्पाला किमान तेवढेच संरक्षण द्यावे.

यापैकी कोणत्याही गोष्टीवर विश्वास ठेवण्यापूर्वी कोणते ports listening आहेत ते तपासा.

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

127.0.0.1:3000 असलेली line अपेक्षित आहे. 0.0.0.0:3000 असलेली line म्हणजे तुमचा chat interface public internet वर आहे. तुमच्या स्वतःच्या machine वरून curl -sI http://YOUR.VPS.IP:3000 ला HTTP/1.1 200 OK उत्तर मिळणे हेच अधिक स्पष्टपणे दर्शवते.

WEBUI_AUTH=False वापरून Open WebUI चे login बंद करणे ही अशा machine साठी single-user setting आहे, जिच्यापर्यंत इतर कोणीही पोहोचू शकत नाही. ज्या installation मध्ये आधीपासून accounts आहेत, त्यावर ही setting लागू होत नाही. त्यावेळी You can't turn off authentication because there are existing users. हा message दिसतो.

Pattern one: loopback ला bind करा आणि SSH द्वारे त्याच्यापर्यंत पोहोचा. प्रत्येक port 127.0.0.1 वर प्रकाशित करा. त्यानंतर आवश्यक port forward करा: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, आणि तुमच्या laptop वर http://localhost:3000 उघडा. काहीही प्रकाशित होत नसल्यामुळे कोणतेही port scan करता येत नाही. Hollama किंवा OrionChat साठी त्याच command मध्ये -L 11434:127.0.0.1:11434 वापरून model port forward करा आणि Ollama ला loopback वरच ठेवा. ही रचना तुमच्या SSH setup इतकीच सुरक्षित आहे. त्यामुळे key-only SSH आणि hardened sshd वापरा.

Pattern two: app ला request मिळण्यापूर्वी authentication करणारा reverse proxy. App loopback वर ठेवा, proxy कडे port 443 ची जबाबदारी द्या आणि त्याच्या पुढे single sign-on ठेवा. Docker Compose labels द्वारे चालवलेला Traefik आणि identity provider म्हणून Authentik वापरल्यास त्या machine वरील प्रत्येक app साठी एक login आणि एक certificate मिळते. Open WebUI ला TLS (transport layer security) मागे ठेवल्यावर WEBUI_SESSION_COOKIE_SECURE=true आणि WEBUI_SESSION_COOKIE_SAME_SITE=strict सेट करा. JWT_EXPIRES_IN ची मुदतही त्याच्या चार आठवड्यांच्या default पेक्षा कमी करा. Open WebUI च्या दस्तऐवजानुसार Redis नसल्यास sign-out केल्यावर token invalidate होत नाही. तो स्वतःहून expire होईपर्यंत वापरता येतो.

Pattern two मुळे browser-only projects सुरक्षित होत नाहीत. Page च्या पुढे proxy असला तरी model endpoint सुरक्षित होत नाही. त्या page वरून वेगळ्या hostname कडे केलेल्या fetch मध्ये तुमचा session cookie पाठवला जात नाही. त्यामुळे Ollama च्या पुढे असलेला authenticating proxy login form कडे redirect देतो आणि chat अपयशी ठरतो. Model endpoint page प्रमाणेच hostname वापरेल अशा प्रकारे route करा किंवा pattern one वापरा.

कोणते निवडावे

तुमच्याशिवाय इतर कोणीही ते वापरणार असेल, तर Open WebUI चालवा. त्यामध्ये प्रत्यक्ष user accounts असतात, नवीन users approval queue मध्ये जातात आणि त्याचे maintainers तुम्ही अनुसरू शकता असे hardening guidance प्रकाशित करतात. LDAP किंवा admin panel आवश्यक असल्यास LibreChat चालवा आणि त्यावर अवलंबून राहण्यापूर्वी docker stats वापरून त्याच्या सहा services आणि तुमचे model उपलब्ध संसाधनांमध्ये योग्यरीत्या चालतात का ते तपासा. लहान box वर एकच व्यक्ती ते वापरणार असेल आणि model ने RAM चा बहुतांश भाग आधीच व्यापला असेल, तर Hollama किंवा OrionChat SSH tunnel द्वारे उपलब्ध करा आणि state browser कडे ठेवू द्या. VPS वर कोणतेही login नसताना त्यापैकी एखादे 0.0.0.0 वर प्रकाशित करणे हा चुकीचा पर्याय आहे.

FAQ

Open WebUI थेट सार्वजनिक IP वर उघड करणे सुरक्षित आहे का?

त्याच्या hardening पृष्ठावर Open WebUI चे वर्णन private, trusted networks साठी असलेले software असे केले आहे. ते database किंवा CI server सारख्याच श्रेणीत येते. त्यात प्रत्यक्ष user accounts असतात. पहिला account administrator बनतो, तर नंतरचे accounts मंजुरी मिळेपर्यंत pending राहतात. त्यामुळे login नसलेल्या UI पेक्षा ते अधिक सुरक्षित आहे. तरीही ते TLS असलेल्या reverse proxy मागे ठेवा. शक्य असल्यास single sign-on वापरा. Container port 127.0.0.1:3000:8080 म्हणून publish करा, जेणेकरून Docker चे स्वतःचे iptables नियम तुमच्या नकळत ते इंटरनेटसाठी उघडू शकणार नाहीत.

VPS वर कोणता Open WebUI पर्याय सर्वात कमी RAM वापरतो?

Browser-based पर्याय, Hollama आणि OrionChat, कारण application client वर चालते. Server फक्त static files पाठवतो. OrionChat ला application container चीही आवश्यकता नसते. Open WebUI memory मध्ये Python process, database आणि default नुसार local embedding model ठेवते. Documentation नुसार embedding model साठीच प्रत्येक worker सुमारे 500 MB वापरतो. तुमच्या स्वतःच्या box वर docker stats --no-stream वापरून आकडे तपासा, कारण तुम्ही सुरू केलेल्या features नुसार ते बदलतात.

हे chat UIs दुसऱ्या host वरील Ollama server वापरू शकतात का?

Open WebUI आणि LibreChat हे करू शकतात. Connection त्यांचा server करतो, त्यामुळे browser चे कोणतेही नियम लागू होत नाहीत. Open WebUI साठी OLLAMA_BASE_URL सेट करा. LibreChat साठी custom endpoint मध्ये baseURL सेट करा. vLLM किंवा अन्य OpenAI-compatible server साठी /v1 suffix असलेले OPENAI_API_BASE_URL वापरा आणि रिकामी नसलेली API key द्या. Hollama आणि OrionChat देखील कोणत्याही ठिकाणी point करता येतात. मात्र request तुमच्या browser कडून येते. त्यामुळे endpoint तुमच्या browser वरूनही reachable असणे आवश्यक आहे.

माझी browser chat UI Ollama पर्यंत का पोहोचू शकत नाही?

जवळपास प्रत्येक प्रकरणासाठी दोन कारणे लागू होतात. Ollama default नुसार 127.0.0.1:11434 वर bind होते. त्यामुळे दुसऱ्या machine वरील browser OLLAMA_HOST बदलेपर्यंत त्यापर्यंत पोहोचू शकत नाही. तसेच Ollama localhost कडूनच cross-origin requests स्वीकारते. त्यामुळे तुमच्या स्वतःच्या domain वरून serve केलेले page OLLAMA_ORIGINS मध्ये तो origin सूचीबद्ध होईपर्यंत No 'Access-Control-Allow-Origin' header is present on the requested resource सह नाकारले जाते. Page HTTPS वर आणि endpoint HTTP वर असल्यास, Ollama ला request मिळण्यापूर्वीच browser mixed content म्हणून call block करतो. systemctl edit ollama.service override मध्ये दोन्ही variables सेट करा. किंवा SSH द्वारे port forward करा; त्यामुळे ही समस्या दूर होते.