เปรียบเทียบทางเลือก Open WebUI สำหรับรันบน VPS

ทางเลือกของ Open WebUI ที่เหมาะสำหรับใช้งานบน VPS

ทางเลือกของ Open WebUI มักถูกเปรียบเทียบโดยอิงจากการใช้งานบนแล็ปท็อป ซึ่งมี RAM ราคาถูกและไม่มีบริการใดเปิดรับการเชื่อมต่อจากที่อยู่สาธารณะ แต่ VPS เปลี่ยนปัจจัยทั้งสองประการนี้ ซึ่งส่งผลต่อการจัดอันดับ Open WebUI ยังคงเป็นตัวเลือกเริ่มต้นที่เหมาะสมที่สุดทันทีที่มีผู้ใช้งานคนที่สองเข้ามา เนื่องจากซอฟต์แวร์มาพร้อมกับระบบบัญชีผู้ใช้จริงและแผงควบคุมผู้ดูแลระบบ โครงการที่มีขนาดเบากว่าจะเป็นฝ่ายชนะเมื่ออินเทอร์เฟซต้องแย่งชิง RAM กิกะไบต์สุดท้ายกับตัวโมเดล แต่ราคาที่ต้องจ่ายสำหรับความได้เปรียบนั้นคือระบบยืนยันตัวตน ซึ่งโครงการเหล่านั้นไม่มีให้

ข้อมูลทั้งหมดด้านล่างนี้มาจากเอกสารประกอบของแต่ละโครงการโดยตรง ซึ่งตรวจสอบเมื่อเดือนสิงหาคม 2026 โดยเกณฑ์ทั้ง 4 ด้านเป็นสิ่งที่ปรากฏขึ้นเฉพาะเมื่อเซิร์ฟเวอร์สามารถเข้าถึงได้จากอินเทอร์เน็ตเท่านั้น

สี่ปัจจัยที่สำคัญเฉพาะเมื่อใช้งานบน Public 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"
  }
]

ตัวเลขเหล่านี้คือค่าที่แสดงบนหน้าไลบรารีของ Ollama ในเดือนสิงหาคม 2026 ซึ่งเป็นขนาดที่เผยแพร่ ไม่ใช่ค่าที่วัดจากการใช้งานจริง บน VPS ขนาด 4 GB นั้น qwen3:4b ที่ขนาด 2.5 GB จะเหลือพื้นที่ไม่ถึง 1.5 GB สำหรับระบบปฏิบัติการและส่วนประกอบอื่น ๆ และ context cache จะค่อย ๆ กินพื้นที่ส่วนนี้เมื่อการสนทนาดำเนินไป นี่คือเหตุผลว่าทำไม ค่า num_ctx ที่คุณตั้งค่า จึงเป็นการตัดสินใจด้านหน่วยความจำพอ ๆ กับด้านคุณภาพ ส่วน qwen3:8b ที่ขนาด 5.2 GB นั้นไม่สามารถรันบนเซิร์ฟเวอร์นี้ได้เลย นี่คือสถานการณ์ที่บทความสรุปสำหรับแล็ปท็อปมักไม่ได้กล่าวถึง และเป็นจุดที่อินเทอร์เฟซแชทซึ่งใช้หน่วยความจำไม่กี่ร้อยเมกะไบต์จะเป็นตัวตัดสินว่าโมเดลจะรันได้หรือไม่ หากคุณกำลังจัดสเปกเซิร์ฟเวอร์สำหรับโมเดลที่ใหญ่กว่าค่าเหล่านี้ การคำนวณสำหรับโมเดล 27B บน VPS ที่ใช้ CPU เท่านั้น จะแสดงให้เห็นว่าอินเทอร์เฟซจะเลิกเป็นปัจจัยหลักในการตัดสินใจอย่างรวดเร็วเพียงใด

จงวัดค่าด้วยตนเองแทนการเชื่อตัวเลขในบทความสรุป รวมถึงบทความนี้ด้วย ให้รันคำสั่ง 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

เข้าถึงหน้าเว็บผ่านอุโมงค์ (tunnel) หรือพร็อกซี (proxy) ซึ่งอธิบายไว้ด้านล่าง จากนั้นจึงสร้างบัญชีแรก บัญชีนั้นจะกลายเป็นผู้ดูแลระบบ การลงทะเบียนในภายหลังจะถูกกำหนดบทบาทเป็น pending ซึ่งเป็นค่าเริ่มต้นตามเอกสารของ DEFAULT_USER_ROLE ดังนั้นบุคคลภายนอกที่เข้าถึงหน้าเว็บได้จะยังไม่สามารถใช้งานโมเดลของคุณได้จนกว่าผู้ดูแลระบบจะอนุมัติ

Open WebUI ใช้หน่วยความจำมากกว่าโปรเจกต์ด้านล่างเนื่องจากมีฟังก์ชันการทำงานที่มากกว่า และหน้าแสดงประสิทธิภาพของตัวมันเองได้ระบุส่วนประกอบที่ใช้ทรัพยากรสูงไว้แล้ว เอนจินการทำ embedding แบบเริ่มต้นจะโหลดโมเดล sentence-transformers ไว้ภายในคอนเทนเนอร์ ซึ่งตามเอกสารระบุว่าใช้หน่วยความจำประมาณ 500 MB ต่อหนึ่ง worker process การตั้งค่า RAG_EMBEDDING_ENGINE=ollama จะส่งงานส่วนนี้ไปให้เซิร์ฟเวอร์โมเดลที่คุณใช้งานอยู่แล้ว ส่วน AUDIO_STT_ENGINE=webapi จะช่วยหลีกเลี่ยงการโหลดโมเดลแปลงเสียงเป็นข้อความ (speech-to-text) ไว้ในเครื่อง สำหรับการใช้งานบน SQLite หากไม่ได้ตั้งค่า DATABASE_POOL_SIZE ไว้ พูลการเชื่อมต่อจะกลับไปใช้ขนาดภายในที่ใหญ่ และการเชื่อมต่อแต่ละรายการจะขยายขนาด page cache และ memory map ของตัวเอง ดังนั้นบนเครื่องที่มีทรัพยากรจำกัด ควรตั้งค่า DATABASE_POOL_SIZE=8 และ DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 ส่วน 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

อินเทอร์เฟซทำงานบนพอร์ต 3080 LibreChat เป็นตัวเลือกที่ควรพิจารณาเมื่อคุณต้องการระบบจัดการตัวตน (identity system) มากกว่าแค่กล่องล็อกอินทั่วไป โดยมีการจัดทำเอกสารสำหรับการล็อกอินผ่าน LDAP และ OAuth2 รวมถึงมีแผงควบคุมสำหรับผู้ดูแลระบบเพื่อจัดการผู้ใช้และบทบาท ซึ่งความสามารถเหล่านี้มาพร้อมกับ 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 เริ่มต้นจะเริ่มการทำงานของบริการจำนวน 6 รายการ ได้แก่ api, admin panel, MongoDB, Meilisearch, pgvector, RAG API ทั้งหมดนี้ไม่ใช่ตัวโมเดล (model) โดยทั้ง MongoDB และ pgvector ต่างต้องการหน่วยความจำของตนเอง ซึ่งบนเครื่องขนาด 4 GB นั้นเป็นหน่วยความจำที่โมเดลต้องการใช้งาน

การอัปเกรดเป็นกระบวนการที่ใช้ git ซึ่งเป็นส่วนที่ผู้ใช้มักทำผิดพลาด

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

git pull จะหยุดทำงานพร้อมแจ้งข้อขัดแย้งหากคุณแก้ไขไฟล์ docker-compose.yml ที่ถูกติดตามอยู่ (tracked) ส่งผลให้การอัปเกรดเสร็จสมบูรณ์เพียงบางส่วน ให้ใส่การตั้งค่าของคุณลงใน docker-compose.override.yml ซึ่งโปรเจกต์ได้จัดเตรียมไว้ให้สำหรับกรณีนี้ และเก็บข้อมูลลับไว้ใน .env ทั้งสองไฟล์นี้ไม่ได้ถูกติดตามโดย git ดังนั้น git pull จึงไม่ส่งผลกระทบต่อไฟล์เหล่านี้

ชี้ LibreChat ไปยังเซิร์ฟเวอร์โมเดลของคุณเองด้วย custom endpoint ใน librechat.yaml

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 จะไม่สนใจค่าของมันก็ตาม ดังนั้นการใส่ค่าตัวแทน (placeholder) จึงใช้ได้ หาก LibreChat รันใน Docker และ 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 ก้าวไปไกลกว่านั้นโดยไม่มีส่วนประกอบของเซิร์ฟเวอร์เลย ให้ทำการ clone repository และให้บริการโฟลเดอร์ดังกล่าวด้วยเว็บเซิร์ฟเวอร์ที่คุณใช้งานอยู่แล้ว หรือเปิดไฟล์ index.html จากดิสก์โดยตรง API keys จะถูกเก็บไว้ใน localStorage ของเบราว์เซอร์ ประวัติการแชทจะคงอยู่ในเบราว์เซอร์ และแอปจะลบการแชทที่เก่าที่สุดออกเมื่อจำนวนเกิน 512 รายการ

ทั้งสองโปรเจกต์ไม่มีระบบล็อกอินเนื่องจากไม่มีเซิร์ฟเวอร์สำหรับตรวจสอบสิทธิ์ หากใช้งานบนแล็ปท็อปถือว่าไม่มีปัญหา แต่หากใช้งานบน VPS หมายความว่าหน้าเว็บจะต้องไม่ถูกเผยแพร่บน 0.0.0.0 และมีประเด็นสำคัญที่มักมองข้ามไปคือ เบราว์เซอร์เป็นผู้เรียกใช้งานโมเดล ไม่ใช่เซิร์ฟเวอร์

ข้อเท็จจริงนี้เป็นตัวกำหนดว่าทั้งสองโปรเจกต์นี้จะใช้งานได้ที่ไหน เบราว์เซอร์ของคุณต้องเข้าถึง Ollama ได้โดยตรง ดังนั้น Ollama จึงต้องฟังพอร์ตที่มากกว่าแค่ loopback และ Ollama ไม่มีการตรวจสอบสิทธิ์ใดๆ ทั้งสิ้น กฎของเบราว์เซอร์สองข้อจึงเกิดขึ้นตามมา หน้าเว็บที่ให้บริการผ่าน HTTPS จะไม่สามารถเรียกใช้ endpoint แบบ 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. การเรียกไปยัง origin อื่นจะถูกปฏิเสธด้วย has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource จนกว่าคุณจะอนุญาต origin นั้น

วิธีที่ระบุไว้ในเอกสารของ 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 มาก่อน ให้ทำการเปลี่ยนแปลงนี้ก็ต่อเมื่อมีไฟร์วอลล์หรือ proxy ที่มีการตรวจสอบสิทธิ์ควบคุมผู้ที่สามารถเข้าถึงพอร์ตได้แล้วเท่านั้น เนื่องจากพอร์ต 11434 ที่เปิดทิ้งไว้คือเซิร์ฟเวอร์โมเดลที่เปิดกว้าง และเครื่องมือสแกนอัตโนมัติจะตรวจพบพอร์ตสาธารณะใหม่ได้อย่างรวดเร็ว การใช้ SSH tunnel ด้านล่างจะช่วยหลีกเลี่ยงปัญหาทั้งหมดนี้ได้ โดยหน้าเว็บจะทำงานบน origin แบบ localhost ซึ่ง Ollama อนุญาตโดยค่าเริ่มต้น และพอร์ตดังกล่าวจะไม่ถูกเปิดออกสู่ภายนอกเครื่อง

แต่ละตัวสามารถใช้ remote endpoint ของ Ollama หรือ vLLM ได้หรือไม่

Open WebUI สามารถทำได้ โดยการเชื่อมต่อจะเกิดขึ้นที่ฝั่งเซิร์ฟเวอร์ OLLAMA_BASE_URL=http://model-host:11434 ใช้สำหรับชี้ไปยัง Ollama สำหรับ vLLM หรือเซิร์ฟเวอร์อื่นที่รองรับ OpenAI ให้ตั้งค่า OPENAI_API_BASE_URL=http://model-host:8000/v1 ด้วยค่า OPENAI_API_KEY ที่ไม่เป็นค่าว่าง และต้องคง suffix /v1 เอาไว้ซึ่งเป็นสิ่งที่จำเป็น OPENAI_API_BASE_URLS รองรับ backend หลายตัวโดยคั่นด้วยเครื่องหมายอัฒภาค (semicolon)

LibreChat สามารถทำได้ผ่าน baseURL ของ custom endpoint ตามที่แสดงไว้ข้างต้น คำขอดังกล่าวจะออกจากเซิร์ฟเวอร์เช่นกัน ดังนั้นกฎของเบราว์เซอร์จึงไม่มีผล ทั้ง base URL และ placeholder key เดียวกันนี้ยังสามารถใช้งานนอกหน้าต่างแชทได้ ซึ่งเป็นสิ่งที่ต้องใช้ในการ ชี้ coding agent ไปยังโมเดลที่คุณโฮสต์ไว้แล้ว

Hollama และ OrionChat สามารถชี้ไปยัง endpoint ใดก็ได้ที่คุณพิมพ์ลงในการตั้งค่า แต่คำขอจะออกจากเบราว์เซอร์ของคุณ ทุกอย่างในส่วนก่อนหน้านี้มีผลกับแอปเหล่านี้เท่านั้นและไม่มีผลกับส่วนอื่นที่กล่าวถึงที่นี่

การแยกส่วนติดต่อผู้ใช้ (interface) ออกจากโมเดลเป็นประโยชน์สูงสุดที่ remote endpoint มอบให้คุณ คุณสามารถวางส่วนติดต่อไว้บนเครื่องขนาดเล็กและวางโมเดลไว้บนเครื่องที่มีหน่วยความจำเพียงพอ นี่เป็นจุดที่ควรตัดสินใจว่า ควรให้ Ollama หรือ vLLM เป็นตัวให้บริการคำขอ เนื่องจากทั้งสองทำงานแตกต่างกันอย่างมากเมื่อมีผู้ใช้งานหลายคนคุยกับโมเดลพร้อมกัน หากยังไม่มีเซิร์ฟเวอร์โมเดล ให้เริ่มต้นด้วยการ รัน Ollama บน VPS และสำหรับเครื่องที่ใช้ CPU เท่านั้น โปรดอ่าน การเปรียบเทียบระหว่าง Ollama กับ llama.cpp ก่อนที่คุณจะเลือกตัวรันโมเดล

ห้ามเผยแพร่ Chat UI ที่ไม่มีการล็อกอินบน 0.0.0.0 โดยเด็ดขาด

หน้าการตั้งค่าความปลอดภัยของ Open WebUI ระบุว่าโปรเจกต์นี้ "ถูกสร้างขึ้นสำหรับเครือข่ายส่วนตัวที่เชื่อถือได้ เช่นเดียวกับโครงสร้างพื้นฐานแบบ self-hosted อื่นๆ อย่างฐานข้อมูล, container registry และ CI server" และแนะนำให้คุณวางไว้หลัง VPN หรือหลัง reverse proxy ที่มีการยืนยันตัวตน โปรเจกต์ที่ไม่มีระบบล็อกอินเลยควรได้รับการดูแลในระดับเดียวกันเป็นอย่างน้อย

ตรวจสอบสิ่งที่กำลังฟังพอร์ตอยู่ก่อนที่คุณจะเชื่อใจระบบใดๆ

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 จากนั้น forward เฉพาะพอร์ตที่ต้องการด้วย ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com และเปิด http://localhost:3000 บนแล็ปท็อปของคุณ จะไม่มีพอร์ตใดถูกเผยแพร่ออกไป จึงไม่มีใครสามารถสแกนพบได้ สำหรับ Hollama หรือ OrionChat ให้ forward พอร์ตของโมเดลด้วยคำสั่งเดียวกันโดยใช้ -L 11434:127.0.0.1:11434 และปล่อยให้ Ollama ทำงานบน loopback รูปแบบนี้จะปลอดภัยเท่ากับการตั้งค่า SSH ของคุณ ดังนั้นควรใช้คู่กับ การใช้ SSH แบบ key-only และการตั้งค่า sshd ให้ปลอดภัย

รูปแบบที่สอง: reverse proxy ที่ยืนยันตัวตนก่อนที่แอปจะได้รับคำขอ ให้แอปทำงานบน loopback, ให้ proxy เป็นผู้ดูแลพอร์ต 443 และวางระบบ single sign-on ไว้ด้านหน้า Traefik ที่ควบคุมด้วย Docker Compose labels ร่วมกับ Authentik ในฐานะผู้ให้บริการยืนยันตัวตน จะทำให้ทุกแอปบนเครื่องมีระบบล็อกอินและใบรับรองชุดเดียวกัน เมื่อใช้งาน Open WebUI หลัง TLS (transport layer security) ให้ตั้งค่า WEBUI_SESSION_COOKIE_SECURE=true และ WEBUI_SESSION_COOKIE_SAME_SITE=strict นอกจากนี้ควรลดระยะเวลาของ JWT_EXPIRES_IN จากค่าเริ่มต้นสี่สัปดาห์ลงด้วย เนื่องจาก Open WebUI ระบุว่าหากไม่มี Redis การออกจากระบบจะไม่ทำให้ token เป็นโมฆะ โดย token จะยังคงใช้งานได้จนกว่าจะหมดอายุด้วยตัวเอง

รูปแบบที่สองไม่สามารถช่วยโปรเจกต์ที่เป็นเบราว์เซอร์เพียงอย่างเดียวได้ Proxy ที่อยู่หน้าหน้าเว็บไม่สามารถป้องกัน endpoint ของโมเดลได้ และการ fetch จากหน้าเว็บนั้นไปยัง hostname อื่นจะไม่ส่ง session cookie ของคุณไปด้วย ดังนั้น proxy ที่ยืนยันตัวตนหน้า Ollama จะตอบกลับด้วยการ redirect ไปยังหน้าล็อกอินและทำให้การแชทล้มเหลว คุณควรเลือกที่จะ route endpoint ของโมเดลภายใต้ hostname เดียวกับหน้าเว็บ หรือใช้รูปแบบที่หนึ่งแทน

ควรเลือกตัวไหน

หากมีผู้อื่นนอกจากคุณใช้งาน ให้รัน Open WebUI เนื่องจากมีระบบบัญชีผู้ใช้จริง ผู้ใช้ใหม่จะเข้าสู่คิวรอการอนุมัติ และผู้ดูแลโครงการมีการเผยแพร่แนวทางการเสริมความปลอดภัยที่คุณสามารถปฏิบัติตามได้ หากคุณต้องการ LDAP หรือแผงควบคุมผู้ดูแลระบบ ให้รัน LibreChat และตรวจสอบกับ docker stats ว่าบริการทั้ง 6 รายการรวมถึงโมเดลของคุณมีทรัพยากรเพียงพอจริงก่อนที่จะเริ่มใช้งาน หากเป็นการใช้งานคนเดียวบนเซิร์ฟเวอร์ขนาดเล็กที่โมเดลใช้ RAM ไปเกือบหมดแล้ว ให้ให้บริการผ่าน Hollama หรือ OrionChat โดยใช้ SSH tunnel และปล่อยให้เบราว์เซอร์เป็นตัวจัดการสถานะ คำตอบที่ผิดสำหรับการใช้งานบน VPS คือการเปิดเผยบริการเหล่านี้บน 0.0.0.0 โดยไม่มีระบบล็อกอินป้องกันด้านหน้า

FAQ

การเปิดใช้งาน Open WebUI บน Public IP โดยตรงมีความปลอดภัยหรือไม่?

หน้าเอกสารการตั้งค่าความปลอดภัยของซอฟต์แวร์ระบุว่าเป็นซอฟต์แวร์สำหรับเครือข่ายส่วนตัวที่เชื่อถือได้ เช่นเดียวกับฐานข้อมูลหรือเซิร์ฟเวอร์ CI แม้ว่าจะมีระบบบัญชีผู้ใช้จริง และบัญชีแรกที่สร้างขึ้นจะเป็นผู้ดูแลระบบ ส่วนบัญชีถัดไปจะอยู่ในสถานะ pending จนกว่าจะได้รับการอนุมัติ ซึ่งปลอดภัยกว่า UI ที่ไม่มีระบบล็อกอิน แต่ก็ยังควรวางไว้หลัง reverse proxy ที่มี TLS และใช้ single sign-on หากเป็นไปได้ ควรประกาศพอร์ตของ container เป็น 127.0.0.1:3000:8080 เพื่อป้องกันไม่ให้กฎ iptables ของ Docker เปิดพอร์ตสู่สาธารณะโดยที่คุณไม่ทราบ

ทางเลือกของ Open WebUI ตัวใดใช้ RAM น้อยที่สุดบน VPS?

ตัวเลือกที่ทำงานบนเบราว์เซอร์อย่าง Hollama และ OrionChat จะใช้ RAM น้อยที่สุดเนื่องจากแอปพลิเคชันทำงานที่ฝั่งไคลเอนต์ เซิร์ฟเวอร์ทำหน้าที่เพียงส่งไฟล์ static เท่านั้น และ OrionChat ไม่จำเป็นต้องใช้ application container เลย ในขณะที่ Open WebUI จะมีกระบวนการ Python, ฐานข้อมูล และ embedding model ในหน่วยความจำ ซึ่งตามเอกสารระบุว่าใช้ RAM ประมาณ 500 MB ต่อ worker สำหรับ embedding model เพียงอย่างเดียว คุณควรตรวจสอบตัวเลขการใช้งานจริงบนเซิร์ฟเวอร์ของคุณด้วย docker stats --no-stream เนื่องจากปริมาณการใช้จะเปลี่ยนไปตามฟีเจอร์ที่คุณเปิดใช้งาน

Chat UI เหล่านี้สามารถใช้ Ollama server บนโฮสต์อื่นได้หรือไม่?

Open WebUI และ LibreChat สามารถทำได้ โดยเซิร์ฟเวอร์จะเป็นผู้สร้างการเชื่อมต่อ จึงไม่มีข้อจำกัดของเบราว์เซอร์เข้ามาเกี่ยวข้อง ให้ตั้งค่า OLLAMA_BASE_URL สำหรับ Open WebUI หรือใช้ baseURL ใน custom endpoint สำหรับ LibreChat สำหรับ vLLM หรือเซิร์ฟเวอร์อื่นที่รองรับ OpenAI ให้ใช้ OPENAI_API_BASE_URL พร้อม suffix /v1 และระบุ API key ที่ไม่ใช่ค่าว่าง ส่วน Hollama และ OrionChat สามารถชี้ไปยังที่ใดก็ได้เช่นกัน แต่เนื่องจากคำขอมาจากเบราว์เซอร์ของคุณ endpoint นั้นจึงต้องสามารถเข้าถึงได้จากเบราว์เซอร์ของคุณด้วย

เหตุใด Chat UI บนเบราว์เซอร์ของฉันจึงเข้าถึง Ollama ไม่ได้?

สาเหตุหลักมีอยู่ 2 ประการที่พบได้บ่อยที่สุด ประการแรกคือ Ollama ผูกพอร์ต 127.0.0.1:11434 ไว้เป็นค่าเริ่มต้น ทำให้เบราว์เซอร์บนเครื่องอื่นไม่สามารถเข้าถึงได้จนกว่าจะเปลี่ยนค่า OLLAMA_HOST ประการที่สองคือ Ollama ยอมรับคำขอ cross-origin จาก localhost เท่านั้น ดังนั้นหน้าเว็บที่ให้บริการจากโดเมนของคุณจะถูกปฏิเสธด้วยข้อผิดพลาด No 'Access-Control-Allow-Origin' header is present on the requested resource จนกว่าจะระบุ origin นั้นไว้ใน OLLAMA_ORIGINS หากหน้าเว็บเป็น HTTPS แต่ endpoint เป็น HTTP เบราว์เซอร์จะบล็อกการเรียกใช้งานนั้นในฐานะ mixed content ก่อนที่ Ollama จะได้รับคำขอเสียอีก ให้ตั้งค่าตัวแปรทั้งสองใน systemctl edit ollama.service หรือใช้วิธี forward พอร์ตผ่าน SSH แล้วปัญหาจะหมดไป