VPS-க்கு சிறந்த Open WebUI மாற்றீடுகள்: ஒப்பீடு

VPS-ல் எந்த Open WebUI மாற்றீடு பொருத்தமானது

Open WebUI மாற்றீடுகள் பெரும்பாலும் மடிக்கணினிகளில் ஒப்பிடப்படுகின்றன; அங்கு RAM விலை குறைவு மற்றும் பொது முகவரியில் (public address) எந்த சேவையும் இயங்குவதில்லை. ஒரு VPS இந்த இரண்டு உண்மைகளையும் மாற்றுகிறது, இது தரவரிசையையும் மாற்றுகிறது. இரண்டாவது நபர் உள்நுழையும் தருணத்திலேயே Open WebUI சரியான இயல்புநிலைத் தேர்வாகிறது, ஏனெனில் இது உண்மையான பயனர் கணக்குகள் மற்றும் நிர்வாகக் குழுவை (admin panel) வழங்குகிறது. RAM-ன் கடைசி gigabyte-க்காக இடைமுகம் (interface) மாதிரியுடன் (model) போட்டியிடும்போது, இலகுவான திட்டங்கள் வெற்றி பெறுகின்றன. அந்த வெற்றியின் விலை அங்கீகாரம் (authentication): அவற்றில் அது இல்லை.

கீழே உள்ள அனைத்தும் 2026 ஆகஸ்ட் மாதம் வாசிக்கப்பட்ட அந்தந்த திட்டங்களின் சொந்த ஆவணங்களிலிருந்து பெறப்பட்டவை. ஒரு server இணையத்திலிருந்து அணுகக்கூடியதாக மாறியவுடன் மட்டுமே தோன்றும் நான்கு காரணிகள் இவை.

Public IP-ல் கவனிக்க வேண்டிய நான்கு முக்கிய அம்சங்கள்

• Model-க்கு அருகிலுள்ள Memory. இந்த server-ல் model server-தான் அதிக வளங்களை நுகரும் process ஆகும். Interface பயன்படுத்தும் ஒவ்வொரு megabyte-ம் model-க்கு கிடைக்காமல் போகும்.
• Authentication. சில திட்டங்களில் பயனர் கணக்குகள் மற்றும் roles உள்ளன. மற்றவை உங்கள் laptop-ல் அவை மட்டுமே இயங்குவதாகக் கருதி, எந்தவிதமான login வசதியையும் கொண்டிருப்பதில்லை.
• Remote inference. 127.0.0.1:11434-ஐ மட்டுமே அணுகக்கூடிய UI, model-ஐ interface இருக்கும் அதே machine-ல் இருக்கக் கட்டாயப்படுத்துகிறது.
• Upkeep. ஒரு SQLite கோப்பைக் கொண்ட ஒரு container-ஐ நிர்வகிப்பதற்கும், MongoDB மற்றும் vector database-ஐப் பின்பற்றும் ஆறு container-களை நிர்வகிப்பதற்கும் பெரிய வித்தியாசம் உள்ளது.

இடைமுகத்திற்கு (interface) இந்த model எவ்வளவு RAM-ஐ விட்டுவைக்கிறது

இந்த server-ல் இடைமுகம் மிகப்பெரிய காரணி அல்ல. Model-தான் மிகப்பெரியது. Model பதிலளிக்கும்போது அதன் weights நினைவகத்தில் இருக்க வேண்டும் என்பதால், வெளியிடப்பட்ட download அளவுகள் ஒரு குறைந்தபட்ச அளவை மட்டுமே குறிக்கின்றன. Context cache ஒதுக்கப்பட்ட பிறகு, உண்மையான நினைவகப் பயன்பாடு download அளவை விட அதிகமாக இருக்கும்.

[
  {
    "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 library பக்கங்களில் அச்சிடப்பட்ட புள்ளிவிவரங்கள். இவை வெளியிடப்பட்ட அளவுகள், அளவீடுகள் அல்ல. 4 GB VPS-ல், qwen3:4b ஆனது 2.5 GB அளவில் இருக்கும்போது, operating system மற்றும் பிற பயன்பாடுகளுக்கு 1.5 GB-க்கும் குறைவான இடமே மிஞ்சுகிறது. உரையாடல் வளர வளர, context cache இந்த இடத்தையும் பயன்படுத்திக்கொள்ளும். qwen3:8b ஆனது 5.2 GB அளவில் இருப்பதால், அது அந்த server-ல் இயங்கவே இயலாது. Laptop-களை மையமாகக் கொண்ட ஆய்வுகள் இந்தச் சூழலை ஒருபோதும் கவனிப்பதில்லை. சில நூறு megabytes-ஐப் பயன்படுத்தும் chat interface, ஒரு model இயங்குமா இல்லையா என்பதைத் தீர்மானிக்கும் இடமே இதுதான். இந்த அளவீடுகளை விட அதிகமான திறன் கொண்ட server-ஐ நீங்கள் தேர்வு செய்கிறீர்கள் என்றால், CPU-மட்டும் கொண்ட VPS-ல் 27B model-க்கான கணக்கீடு எப்படி இடைமுகத்தின் அளவு ஒரு கட்டத்தில் முக்கியத்துவத்தை இழக்கிறது என்பதைக் காட்டுகிறது.

எந்தவொரு ஆய்விலும் உள்ள எண்களை அப்படியே நம்பாமல், நீங்களே அளவிடுங்கள். Container தொடங்கிய ஒரு நிமிடத்திற்குப் பிறகு பார்க்காமல், ஒரு மணிநேரம் உண்மையான பயன்பாட்டிற்குப் பிறகு docker stats --no-stream கட்டளையை இயக்கவும். ஏனெனில், முக்கியமான நினைவக ஒதுக்கீடு முதல் பயன்பாட்டின் போதே நிகழ்கிறது.

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-ல் உள்ள கட்டளை -p 3000:8080-ஐ வெளியிடுகிறது, இது அனைத்து interface-களிலும் கேட்கும் (listen). 127.0.0.1: முன்னொட்டு (prefix) அதை loopback-ல் மட்டுமே வைத்திருக்கும். ஒரு VPS-ல், வரியின் மற்ற பகுதிகளை விட இந்த முன்னொட்டு மிக முக்கியமானது, ஏனெனில் Docker அதன் சொந்த iptables விதிகளை எழுதுகிறது மற்றும் வெளியிடப்பட்ட port உங்கள் ufw deny விதிகளைப் புறக்கணிக்கும்.

கீழே விவரிக்கப்பட்டுள்ள tunnel அல்லது proxy மூலம் பக்கத்தை அணுகி, முதல் கணக்கை உருவாக்கவும். அந்த கணக்கு நிர்வாகி (administrator) கணக்காக மாறும். பிற்காலத்தில் உருவாக்கப்படும் கணக்குகள் pending என்ற பாத்திரத்தைப் (role) பெறும், இது DEFAULT_USER_ROLE-ன் ஆவணப்படுத்தப்பட்ட இயல்புநிலை ஆகும். எனவே, உங்கள் பக்கத்தை அணுகும் அந்நியர் ஒருவர், நிர்வாகி அனுமதிக்கும் வரை உங்கள் model-ஐப் பயன்படுத்த முடியாது.

Open WebUI மற்ற திட்டங்களை விட அதிக memory-ஐப் பயன்படுத்துகிறது, ஏனெனில் இது கூடுதல் செயல்பாடுகளைக் கொண்டுள்ளது. அதன் performance பக்கத்திலேயே அதிக memory-ஐ எடுத்துக்கொள்ளும் பகுதிகள் குறிப்பிடப்பட்டுள்ளன. இயல்புநிலை embedding engine, container-க்குள் ஒரு sentence-transformers model-ஐ ஏற்றுகிறது, இது ஒரு worker process-க்கு சுமார் 500 MB வரை தேவைப்படும். RAG_EMBEDDING_ENGINE=ollama-ஐ அமைப்பதன் மூலம் அந்த வேலையை நீங்கள் ஏற்கனவே இயக்கும் model server-க்கு மாற்றலாம். AUDIO_STT_ENGINE=webapi உள்ளூர் speech-to-text model-ஐ ஏற்றுவதைத் தவிர்க்கிறது. DATABASE_POOL_SIZE அமைக்கப்படாத நிலையில் SQLite-ல், pool ஒரு பெரிய internal size-க்குத் திரும்பும்; ஒவ்வொரு connection-ம் அதன் சொந்த page cache மற்றும் memory map-ஐ வளர்க்கும். எனவே, சிறிய server-களில் DATABASE_POOL_SIZE=8 மற்றும் DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 ஆகியவற்றை அமைக்கவும். பயனர் தட்டச்சு செய்து கொண்டிருக்கும்போதே model-இடம் completion கேட்கும் இடைமுகத்தின் செயல்பாட்டை ENABLE_AUTOCOMPLETE_GENERATION=False நிறுத்துகிறது.

LibreChat: பல பயனர்கள் மற்றும் அதற்கான stack அமைப்பு

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

இதன் interface 3080 port-ல் இயங்குகிறது. ஒரு எளிய login box-க்கு பதிலாக, முறையான identity system தேவைப்படும்போது LibreChat-ஐப் பயன்படுத்தலாம். இது LDAP மற்றும் OAuth2 logins-க்கான ஆவணங்களைக் கொண்டுள்ளது, மேலும் பயனர்கள் மற்றும் 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"
  }
]

இதன் default compose file 6 சேவைகளைத் தொடங்குகிறது: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. இதில் எதுவுமே model கிடையாது. MongoDB மற்றும் pgvector ஆகிய இரண்டுக்கும் தனித்தனியாக memory தேவைப்படும். 4 GB அளவுள்ள server-ல், இந்த memory-ஐ model-க்கு ஒதுக்க வேண்டியிருக்கும்.

இதன் மேம்படுத்தல்கள் (upgrades) ஒரு git operation ஆகும்; இதில் தான் பலரும் தவறு செய்கிறார்கள்.

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

நீங்கள் மாற்றியமைத்த docker-compose.yml கோப்பை git track செய்திருந்தால், git pull கட்டளையை இயக்கும்போது conflict ஏற்பட்டு, மேம்படுத்தல் பாதியிலேயே நின்றுவிடும். உங்கள் மாற்றங்களை இதற்கென வழங்கப்பட்டுள்ள docker-compose.override.yml கோப்பில் செய்யவும், ரகசியங்களை .env கோப்பில் வைக்கவும். இந்த இரண்டு கோப்புகளும் git-ஆல் track செய்யப்படுவதில்லை, எனவே git pull அவற்றை மாற்றாது.

LibreChat-ல் உங்கள் சொந்த model server-ஐ இணைக்க, librechat.yaml கோப்பில் custom endpoint-ஐக் குறிப்பிடவும்.

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 இயங்கும் server-ன் முகவரியைக் குறிப்பிடவும். Ollama அந்த மதிப்பை கவனிக்காது என்றாலும், apiKey field கட்டாயம் இருக்க வேண்டும், எனவே அங்கு ஒரு placeholder-ஐப் பயன்படுத்தலாம். LibreChat Docker-லும், Ollama அதே machine-லும் இயங்கினால், container-க்குள் localhost என்பது அந்த container-ஐயே குறிக்கும், எனவே அதற்குப் பதிலாக host.docker.internal என்பதைப் பயன்படுத்தவும்.

Hollama மற்றும் OrionChat: உலாவியே பணியைச் செய்கிறது

Hollama ஒரு சிறிய container-லிருந்து browser application-ஐ வழங்குகிறது. உரையாடல்கள் server-ல் சேமிக்கப்படாமல், உங்கள் browser-ன் சேமிப்பகத்திலேயே (storage) இருக்கும்.

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

இந்தக் கட்டளையின் README பதிப்பு --rm-ஐப் பயன்படுத்துகிறது. இது container நிறுத்தப்படும்போது அதை நீக்கிவிடும், எனவே reboot செய்த பிறகு interface மீண்டும் வராது. ஒரு reverse proxy-க்கு பின்னால் இயக்கும்போது, -e VITE_ALLOWED_HOSTS='chat.example.com'-ஐச் சேர்க்கவும். ஏனெனில், இந்த image host localhost-ஐ மட்டுமே அனுமதிக்கும்; பிற hostname-களுக்கான கோரிக்கைகளுக்கு, application-க்கு பதிலாக blocked-host பிழையை இது காட்டும்.

OrionChat இன்னும் ஒரு படி மேலே சென்று, எந்தவொரு server component-உம் இல்லாமல் இயங்குகிறது. repository-ஐ clone செய்து, நீங்கள் ஏற்கனவே இயக்கும் web server மூலம் அந்த folder-ஐ வழங்கலாம் அல்லது disk-லிருந்து index.html-ஐத் திறக்கலாம். API keys browser-ன் localStorage-ல் சேமிக்கப்படும், உரையாடல் வரலாறு browser-லேயே இருக்கும், மேலும் உரையாடல்களின் எண்ணிக்கை 512-ஐத் தாண்டினால், பழமையான உரையாடல்களை app நீக்கிவிடும்.

இந்த இரண்டு திட்டங்களிலும் login வசதி இல்லை, ஏனெனில் அவற்றைச் சரிபார்க்கும் server வசதி அவற்றில் இல்லை. ஒரு laptop-ல் இது சரியாக இருக்கும். ஒரு VPS-ல், இந்தப் பக்கம் ஒருபோதும் 0.0.0.0-ல் வெளியிடப்படக்கூடாது என்று அர்த்தம். மேலும், கவனிக்கத் தவறும் ஒரு முக்கியமான விஷயம்: browser தான் model-ஐ அழைக்கிறது, server அல்ல.

இந்த ஒரு உண்மைதான் இவை இரண்டையும் எங்கு பயன்படுத்தலாம் என்பதைத் தீர்மானிக்கிறது. உங்கள் browser நேரடியாக Ollama-வை அடைய வேண்டும், எனவே Ollama loopback-ஐத் தாண்டி மற்றவற்றிலும் கேட்க (listen) வேண்டும். Ollama-வில் எந்தவிதமான authentication-உம் இல்லை. இதிலிருந்து இரண்டு browser விதிகள் உருவாகின்றன. HTTPS மூலம் வழங்கப்படும் ஒரு பக்கம், plain HTTP endpoint-ஐ அழைக்க முடியாது; 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-லிருந்து வரும் அழைப்பும், நீங்கள் அந்த origin-ஐ அனுமதிக்கும் வரை 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 என்று காட்டியது. firewall அல்லது authentication செய்யும் proxy மூலம் port-ஐ யார் அணுகலாம் என்பது ஏற்கனவே கட்டுப்படுத்தப்பட்டிருந்தால் மட்டுமே இந்த மாற்றத்தைச் செய்யவும். ஏனெனில், திறந்த நிலையில் உள்ள 11434 என்பது ஒரு திறந்த model server ஆகும்; mass scanners புதிய public port-ஐ விரைவாகக் கண்டறிந்துவிடும். கீழே உள்ள SSH tunnel இந்தச் சிக்கலைத் தவிர்க்கிறது: அப்போது அந்தப் பக்கம் localhost origin-ல் இயங்கும், இதை Ollama இயல்பாகவே அனுமதிக்கும், மேலும் அந்த port ஒருபோதும் box-ஐ விட்டு வெளியேறாது.

ஒவ்வொன்றும் ஒரு remote Ollama அல்லது vLLM endpoint-ஐப் பயன்படுத்த முடியுமா?

Open WebUI-ஆல் முடியும், மேலும் இந்த இணைப்பு server பக்கத்திலேயே ஏற்படுத்தப்படுகிறது. OLLAMA_BASE_URL=http://model-host:11434 அதை Ollama-வை நோக்கிச் சுட்டிக்காட்டுகிறது. vLLM அல்லது OpenAI-உடன் இணக்கமான பிற server-களுக்கு, OPENAI_API_KEY காலியாக இல்லாதவாறு OPENAI_API_BASE_URL=http://model-host:8000/v1-ஐ அமைக்கவும், மேலும் அவசியமான /v1 suffix-ஐத் தக்கவைக்கவும். OPENAI_API_BASE_URLS செமிகோலன்களால் பிரிக்கப்பட்ட பல backends-களை ஏற்கும்.

LibreChat-ஆல் மேலே காட்டப்பட்டுள்ள custom endpoint-ன் baseURL வழியாக இதைச் செய்ய முடியும். அந்த கோரிக்கையும் server-லிருந்து வெளியேறுவதால், browser விதிகள் எதுவும் பொருந்தாது. அதே base URL மற்றும் அதே placeholder key ஆகியவை chat window-க்கு வெளியேயும் செயல்படும், இதுவே நீங்கள் ஏற்கனவே host செய்துள்ள model-ஐ ஒரு coding agent-க்கு சுட்டிக்காட்ட போதுமானது.

Hollama மற்றும் OrionChat ஆகியவை அவற்றின் settings-ல் நீங்கள் உள்ளிடும் எந்த endpoint-க்கும் சுட்டிக்காட்ட முடியும், ஆனால் அந்த கோரிக்கை உங்கள் browser-லிருந்து வெளியேறுகிறது. மேலே உள்ள பகுதியில் உள்ள அனைத்தும் அவற்றுக்கு மட்டுமே பொருந்தும், இங்குள்ள மற்ற எதற்கும் பொருந்தாது.

Interface-ஐ model-லிருந்து பிரிப்பது, ஒரு remote endpoint உங்களுக்கு வழங்கும் மிக பயனுள்ள வசதியாகும். Interface-ஐ ஒரு சிறிய box-லும், model-ஐ அதிக memory உள்ள இடத்திலும் வைக்கவும். பல பயனர்கள் ஒரே நேரத்தில் model-உடன் உரையாடும்போது, இரண்டுமே வெவ்வேறு விதமாகச் செயல்படுவதால், Ollama அல்லது vLLM ஆகியவற்றில் எது கோரிக்கைகளைச் செயல்படுத்த வேண்டும் என்பதைத் தீர்மானிப்பதற்கான தருணம் இதுவே. Model server இன்னும் உருவாக்கப்படவில்லை என்றால், VPS-ல் Ollama-வை இயக்குவதன் மூலம் தொடங்கவும், மேலும் CPU மட்டும் உள்ள box-ல், நீங்கள் ஒரு runner-ஐத் தேர்ந்தெடுக்கும் முன் Ollama மற்றும் llama.cpp-க்கு இடையிலான ஒப்பீட்டை வாசிக்கவும்.

Login வசதி இல்லாத chat UI-ஐ ஒருபோதும் 0.0.0.0-ல் வெளியிட வேண்டாம்

Open WebUI-ன் hardening பக்கத்தில், இந்தத் திட்டம் "databases, container registries, மற்றும் CI servers போன்ற பிற self-hosted உள்கட்டமைப்புகளைப் போலவே, தனிப்பட்ட மற்றும் நம்பகமான நெட்வொர்க்குகளுக்காக உருவாக்கப்பட்டது" என்று குறிப்பிடப்பட்டுள்ளது. இதை ஒரு VPN-க்கு பின்னால் அல்லது authentication வசதி கொண்ட reverse proxy-க்கு பின்னால் வைக்க வேண்டும் என்று அது அறிவுறுத்துகிறது. எந்தவிதமான login வசதியும் இல்லாத ஒரு திட்டத்திற்கு, குறைந்தபட்சம் அதே பாதுகாப்பையாவது வழங்க வேண்டும்.

எந்தவொரு சேவையையும் நம்புவதற்கு முன்பு, அது எதைக் கேட்கிறது (listening) என்பதைச் சரிபார்க்கவும்.

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

127.0.0.1:3000 என்று இருக்கும் வரி உங்களுக்குத் தேவையானது. 0.0.0.0:3000 என்று இருக்கும் வரி, உங்கள் chat interface பொது இணையத்தில் (public internet) இருப்பதை உணர்த்துகிறது. உங்கள் சொந்த கணினியிலிருந்து, curl -sI http://YOUR.VPS.IP:3000 கட்டளை HTTP/1.1 200 OK என்று பதிலளித்தால், அது இன்னும் தெளிவாக அதே விஷயத்தைச் சொல்கிறது.

WEBUI_AUTH=False மூலம் Open WebUI-ன் login வசதியை முடக்குவது, வேறு யாரும் அணுக முடியாத கணினிக்கான single-user அமைப்பாகும். ஏற்கனவே கணக்குகள் உள்ள ஒரு installation-ல் இதைச் செய்ய முயன்றால், You can't turn off authentication because there are existing users. என்ற செய்தியுடன் அது மறுத்துவிடும்.

முறை ஒன்று: loopback-ல் bind செய்து SSH வழியாக அணுகுதல். ஒவ்வொரு port-ஐயும் 127.0.0.1-ல் வெளியிடவும், பின்னர் உங்களுக்குத் தேவையானதை forward செய்யவும்: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, மற்றும் உங்கள் laptop-ல் http://localhost:3000-ஐத் திறக்கவும். எதுவும் பொதுவெளியில் வெளியிடப்படாததால், எதையும் ஸ்கேன் செய்ய முடியாது. Hollama அல்லது OrionChat-க்கு, அதே கட்டளையில் -L 11434:127.0.0.1:11434 மூலம் model port-ஐ forward செய்யவும், Ollama-வை loopback-லேயே விடவும். இந்த முறை உங்கள் SSH அமைப்பின் வலிமையைப் பொறுத்தது, எனவே இதை key-only SSH மற்றும் பாதுகாப்பான sshd உடன் இணைக்கவும்.

முறை இரண்டு: பயன்பாடு கோரிக்கையைப் பெறுவதற்கு முன்பே authentication செய்யும் reverse proxy. பயன்பாட்டை loopback-ல் வைத்திருக்கவும், port 443-ஐ proxy-யிடம் ஒப்படைக்கவும், அதன் முன்னால் single sign-on வசதியைச் சேர்க்கவும். Docker Compose labels மூலம் இயங்கும் Traefik மற்றும் identity provider-ஆக Authentik ஆகியவற்றைப் பயன்படுத்தினால், அந்த கணினியில் உள்ள ஒவ்வொரு பயன்பாட்டிற்கும் ஒரு login மற்றும் ஒரு certificate கிடைக்கும். Open WebUI-ஐ TLS (transport layer security)-க்கு பின்னால் வைக்கும்போது, WEBUI_SESSION_COOKIE_SECURE=true மற்றும் WEBUI_SESSION_COOKIE_SAME_SITE=strict ஆகியவற்றை அமைக்கவும். JWT_EXPIRES_IN-ன் நான்கு வார கால அளவைக் குறைக்கவும், ஏனெனில் Redis இல்லையெனில், sign-out செய்தாலும் token செல்லாததாகாது என்று Open WebUI ஆவணங்கள் குறிப்பிடுகின்றன: அது தானாகவே காலாவதியாகும் வரை பயன்பாட்டில் இருக்கும்.

முறை இரண்டு, browser-மட்டும் கொண்ட திட்டங்களைக் காப்பாற்றாது. பக்கத்திற்கு முன்னால் இருக்கும் proxy, model endpoint-ஐப் பாதுகாக்காது. அந்தப் பக்கத்திலிருந்து வேறு ஒரு hostname-க்கு செய்யப்படும் fetch, உங்கள் session cookie-ஐக் கொண்டு செல்லாது. எனவே, Ollama-வுக்கு முன்னால் இருக்கும் authenticating proxy, login படிவத்திற்கு redirect செய்யும், இதனால் chat தோல்வியடையும். model endpoint-ஐ அதே hostname-ன் கீழ் route செய்யவும் அல்லது முறை ஒன்றைப் பயன்படுத்தவும்.

எதைத் தேர்ந்தெடுக்க வேண்டும்

உங்களைத் தவிர வேறு யாராவது இதைப் பயன்படுத்தப் போகிறார்கள் என்றால், Open WebUI-ஐ இயக்கவும். இதில் முறையான கணக்குகள் (accounts) உள்ளன, புதிய பயனர்கள் ஒப்புதல் வரிசையில் (approval queue) சேர்க்கப்படுவார்கள், மேலும் நீங்கள் பின்பற்றக்கூடிய பாதுகாப்பு வழிகாட்டுதல்களை அதன் பராமரிப்பாளர்கள் வெளியிடுகிறார்கள். உங்களுக்கு LDAP அல்லது நிர்வாகக் குழு (admin panel) தேவைப்பட்டால், LibreChat-ஐ இயக்கவும். அதைச் சார்ந்திருப்பதற்கு முன்பு, அதன் ஆறு சேவைகள் மற்றும் உங்கள் model ஆகியவை உங்கள் கணினியில் சரியாகப் பொருந்துகிறதா என்பதை docker stats மூலம் உறுதிப்படுத்தவும். இது ஒரு சிறிய கணினியில் ஒரு நபர் மட்டும் பயன்படுத்தும் சூழலாக இருந்து, model ஏற்கனவே RAM-ன் பெரும்பகுதியை எடுத்துக்கொண்டிருந்தால், Hollama அல்லது OrionChat-ஐ SSH tunnel வழியாக இயக்கவும்; browser-ஐ state-ஐ வைத்திருக்க அனுமதிக்கவும். ஒரு VPS-ல், முன்னால் எந்த login-ம் இல்லாமல் 0.0.0.0-ல் எதையாவது வெளியிடுவது தவறான அணுகுமுறையாகும்.

FAQ

Open WebUI-ஐ நேரடியாக ஒரு public IP-ல் வெளியிடுவது பாதுகாப்பானதா?

இதன் சொந்த hardening பக்கத்தில், இது ஒரு database அல்லது CI server போன்ற, நம்பகமான private network-களுக்காக உருவாக்கப்பட்ட மென்பொருள் என்று குறிப்பிடப்பட்டுள்ளது. இதில் முறையான கணக்குகள் (accounts) உள்ளன; முதல் கணக்கு நிர்வாகி (administrator) உரிமையைப் பெறும், மற்றவை அங்கீகரிக்கப்படும் வரை pending நிலையிலேயே இருக்கும். எனவே, login வசதி இல்லாத UI-களை விட இது பாதுகாப்பானது. இருப்பினும், இதை TLS வசதி கொண்ட ஒரு reverse proxy-க்கு பின்னால் வைத்து, முடிந்தவரை single sign-on முறையைப் பயன்படுத்தவும். Docker-ன் சொந்த iptables விதிகள் உங்கள் அனுமதியின்றி இணையத்தில் port-ஐத் திறந்துவிடாமல் இருக்க, container port-ஐ 127.0.0.1:3000:8080 என publish செய்யவும்.

VPS-ல் குறைந்த RAM-ஐப் பயன்படுத்தும் Open WebUI-க்கு மாற்றான மென்பொருள் எது?

Hollama மற்றும் OrionChat ஆகியவை browser-ஐ அடிப்படையாகக் கொண்டவை, ஏனெனில் இவை client-ல் இயங்குகின்றன. server வெறும் static கோப்புகளை மட்டுமே அனுப்புகிறது; OrionChat-க்கு எந்தவொரு application container-ம் தேவையில்லை. Open WebUI ஒரு Python process, ஒரு database மற்றும் இயல்பாகவே ஒரு local embedding model-ஐ நினைவகத்தில் வைத்திருக்கும். embedding model-க்கு மட்டும் ஒரு worker-க்கு சுமார் 500 MB தேவைப்படும் என்று ஆவணப்படுத்தப்பட்டுள்ளது. நீங்கள் இயக்கும் அம்சங்களைப் பொறுத்து இந்த அளவு மாறுபடும் என்பதால், docker stats --no-stream மூலம் உங்கள் server-ல் உள்ள அளவை உறுதிப்படுத்திக் கொள்ளுங்கள்.

இந்த chat UI-கள் வேறொரு host-ல் உள்ள Ollama server-ஐப் பயன்படுத்த முடியுமா?

Open WebUI மற்றும் LibreChat ஆகியவற்றால் முடியும். இவற்றின் server-தான் இணைப்பை ஏற்படுத்துவதால், browser விதிகள் இதற்குப் பொருந்தாது. Open WebUI-க்கு OLLAMA_BASE_URL-ஐ அமைக்கவும், அல்லது LibreChat-ல் custom endpoint-ஆக baseURL-ஐ அமைக்கவும். vLLM அல்லது OpenAI-க்கு இணக்கமான பிற server-களுக்கு, /v1 suffix மற்றும் காலியாக இல்லாத API key-உடன் OPENAI_API_BASE_URL-ஐப் பயன்படுத்தவும். Hollama மற்றும் OrionChat ஆகியவையும் எங்கு வேண்டுமானாலும் இணைக்கப்படலாம், ஆனால் கோரிக்கை உங்கள் browser-லிருந்து வருவதால், அந்த endpoint உங்கள் browser-க்கு அணுகக்கூடியதாக இருக்க வேண்டும்.

எனது browser chat UI-ஆல் ஏன் Ollama-வை அணுக முடியவில்லை?

பெரும்பாலான சிக்கல்களுக்கு இரண்டு காரணங்களே உள்ளன. Ollama இயல்பாகவே 127.0.0.1:11434-ல் இயங்குகிறது, எனவே OLLAMA_HOST மாற்றப்படும் வரை வேறொரு கணினியில் உள்ள browser-ஆல் அதை அணுக முடியாது. மேலும், Ollama localhost-லிருந்து வரும் cross-origin கோரிக்கைகளை மட்டுமே ஏற்கும். எனவே, உங்கள் domain-லிருந்து வரும் பக்கம் OLLAMA_ORIGINS-ல் பட்டியலிடப்படும் வரை No 'Access-Control-Allow-Origin' header is present on the requested resource பிழையுடன் நிராகரிக்கப்படும். பக்கம் HTTPS-ஆகவும், endpoint HTTP-ஆகவும் இருந்தால், Ollama-விடம் செல்வதற்கு முன்பே browser அதை mixed content எனக் கருதித் தடுத்துவிடும். இரண்டு variable-களையும் ஒரு systemctl edit ollama.service override-ல் அமைக்கவும், அல்லது SSH மூலம் port-ஐ forward செய்தால் இந்தச் சிக்கல் நீங்கிவிடும்.