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

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

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

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

สี่ประเด็นสำคัญเมื่อใช้งานบน Public IP

• หน่วยความจำที่ใช้ร่วมกับโมเดล: เซิร์ฟเวอร์โมเดลเป็นกระบวนการที่ใช้ทรัพยากรสูงที่สุดบนเครื่อง ทุกเมกะไบต์ที่อินเทอร์เฟซใช้งาน คือเมกะไบต์ที่โมเดลไม่สามารถเข้าถึงได้
• การยืนยันตัวตน: บางโปรเจกต์มีระบบบัญชีผู้ใช้และบทบาทการเข้าถึง ในขณะที่บางโปรเจกต์ถูกออกแบบมาให้รันบนเครื่องส่วนตัวเพียงเครื่องเดียว จึงไม่มีระบบล็อกอินใดๆ เลย
• การอนุมานผลจากระยะไกล: UI ที่เข้าถึงได้เฉพาะ 127.0.0.1:11434 จะบังคับให้โมเดลต้องรันอยู่บนเครื่องเดียวกับอินเทอร์เฟซเสมอ
• การดูแลรักษา: คอนเทนเนอร์เดียวที่ใช้ไฟล์ SQLite มีภาระงานต่างจากการจัดการคอนเทนเนอร์ 6 ตัวที่ต้องรันร่วมกับ 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 จะค่อยๆ กินพื้นที่ส่วนนี้ไปเมื่อการสนทนาดำเนินไป ส่วน qwen3:8b ที่ขนาด 5.2 GB นั้นไม่สามารถรันบนเซิร์ฟเวอร์ขนาดนี้ได้เลย นี่คือสถานการณ์ที่บทความรีวิวแล็ปท็อปมักไม่กล่าวถึง และเป็นจุดที่อินเทอร์เฟซแชทซึ่งใช้หน่วยความจำไม่กี่ร้อยเมกะไบต์จะเป็นตัวตัดสินว่าโมเดลจะทำงานได้หรือไม่ หากคุณกำลังประเมินขนาดเซิร์ฟเวอร์สำหรับโมเดลที่ใหญ่กว่าค่าเหล่านี้ การคำนวณสำหรับโมเดล 27B บน VPS ที่ใช้ CPU เท่านั้น จะแสดงให้เห็นว่าอินเทอร์เฟซจะเลิกเป็นปัจจัยตัดสินความสำเร็จได้รวดเร็วเพียงใด

จงวัดค่าด้วยตนเองแทนการเชื่อตัวเลขในบทความรีวิวใดๆ รวมถึงบทความนี้ด้วย ให้รันคำสั่ง 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: จะจำกัดให้รับฟังเฉพาะบน loopback เท่านั้น บน VPS คำนำหน้านี้มีความสำคัญยิ่งกว่าส่วนอื่นใดในบรรทัดนั้น เพราะ Docker จะเขียนกฎ iptables ของตนเอง และพอร์ตที่ถูกเผยแพร่จะเพิกเฉยต่อกฎการปฏิเสธของ ufw

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

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

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

แต่ละตัวสามารถใช้ 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 ที่ไม่ว่างเปล่า และคงส่วนต่อท้าย /v1 เอาไว้ซึ่งเป็นสิ่งที่จำเป็น OPENAI_API_BASE_URLS รองรับ backend หลายรายการโดยคั่นด้วยเครื่องหมายอัฒภาค (semicolon)

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

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

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

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

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

ตรวจสอบสิ่งที่กำลังเปิดฟัง (listening) อยู่ก่อนที่คุณจะเชื่อใจสิ่งใดก็ตาม

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 จากนั้นทำ port forwarding เฉพาะสิ่งที่จำเป็น: 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 ด้วยคีย์เท่านั้นและการตั้งค่า 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 การออกจากระบบ (sign-out) จะไม่ทำให้ token เป็นโมฆะ โดย token จะยังคงใช้งานได้จนกว่าจะหมดอายุด้วยตัวเอง

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

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

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

FAQ

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

หน้าเอกสารการตั้งค่าความปลอดภัยของตัวซอฟต์แวร์ระบุว่า Open WebUI ออกแบบมาสำหรับเครือข่ายส่วนตัวที่เชื่อถือได้ เช่นเดียวกับฐานข้อมูลหรือเซิร์ฟเวอร์ CI แม้ว่าจะมีระบบบัญชีผู้ใช้จริง และบัญชีแรกที่สมัครจะเป็นผู้ดูแลระบบ ส่วนบัญชีถัดมาจะถูกตั้งค่าเป็น pending จนกว่าจะได้รับการอนุมัติ ซึ่งปลอดภัยกว่า UI ที่ไม่มีระบบล็อกอิน แต่คุณควรวางไว้หลัง reverse proxy ที่ใช้ TLS และใช้ single sign-on หากเป็นไปได้ นอกจากนี้ควร publish พอร์ตของคอนเทนเนอร์ไว้ที่ 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 บนโฮสต์อื่นได้หรือไม่?

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 ใดก็ได้เช่นกัน แต่เนื่องจากคำขอถูกส่งมาจากเบราว์เซอร์ของคุณ 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 เพื่อแก้ปัญหานี้