חלופות ל-Open WebUI עבור שרת VPS: השוואה טכנית

איזו חלופה ל-Open WebUI מתאימה ל-VPS

חלופות ל-Open WebUI מושוות כמעט תמיד בסביבת מחשב נייד, שבה ה-RAM זול ושום שירות אינו מאזין לכתובת ציבורית. שרת VPS משנה את שני הנתונים הללו, ושינוי זה משפיע על הדירוג. Open WebUI נשארת ברירת המחדל הנכונה ברגע שאדם נוסף מתחבר למערכת, כיוון שהיא כוללת חשבונות משתמש אמיתיים ולוח ניהול. הפרויקטים הקלים יותר מנצחים כאשר הממשק מתחרה עם המודל על הגיגה-בייט האחרון של ה-RAM. המחיר של ניצחון זה הוא אימות: אין להם מנגנון כזה כלל.

כל המידע להלן מבוסס על התיעוד הרשמי של כל פרויקט, כפי שנקרא באוגוסט 2026. ארבעת הצירים המוצגים הם אלו שבאים לידי ביטוי רק כאשר השרת נגיש מהאינטרנט.

ארבעה צירים שרלוונטיים רק עבור IP ציבורי

• זיכרון לצד המודל. שרת המודל הוא התהליך היקר ביותר במכונה. כל מגה-בייט שתופס הממשק הוא מגה-בייט שאינו זמין למודל.
• אימות. בחלק מהפרויקטים הללו קיימים חשבונות משתמש ותפקידים. אחרים מניחים שהם התהליך היחיד שרץ על המחשב שלכם, ולכן אין להם מנגנון התחברות כלל.
• הסקה מרחוק (Remote inference). ממשק משתמש שיכול לגשת רק ל-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 נגס בזיכרון הזה ככל שהשיחה מתארכת. qwen3:8b בנפח 5.2 GB כלל לא ייכנס לשרת כזה. זהו המצב שסקירות מחשבים ניידים לעולם אינן מכסות, וזהו המקום שבו ממשק צ'אט שתופס כמה מאות מגה-בייטים קובע אם המודל ירוץ או לא. אם אתם מתכננים שרת עבור מודלים גדולים משמעותית מהתגים הללו, החישוב עבור מודל 27B בשרת VPS מבוסס CPU בלבד מראה עד כמה מהר הממשק מפסיק להיות המספר הקובע.

מדדו בעצמכם במקום לסמוך על מספר כלשהו בסקירה, כולל זו. הריצו את docker stats --no-stream לאחר שעה של שימוש אמיתי, לא דקה אחת לאחר הפעלת ה-container, כיוון שהזיכרון הקריטי מוקצה בעת השימוש הראשון.

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, המאזין בכל ממשק. הקידומת 127.0.0.1: מגבילה אותו ל-loopback. בשרת VPS, לקידומת הזו יש חשיבות עליונה, כיוון ש-Docker כותב חוקי iptables משלו ופורט מפורסם מתעלם מחוקי ה-ufw deny שלכם.

גשו לדף דרך מנהרה (tunnel) או proxy, שניהם מתוארים בהמשך, ולאחר מכן צרו את החשבון הראשון. חשבון זה הופך למנהל המערכת (administrator). הרשמות מאוחרות יותר נוצרות עם התפקיד pending, ברירת המחדל המתועדת של DEFAULT_USER_ROLE, כך שזר שמגיע לדף עדיין לא יוכל להשתמש במודל שלכם עד שמנהל יאשר אותו.

Open WebUI צורך יותר זיכרון מהפרויקטים הבאים כיוון שהוא מבצע פעולות רבות יותר, ודף הביצועים שלו מציין את הרכיבים שצורכים משאבים. מנוע ה-embedding המוגדר כברירת מחדל טוען מודל sentence-transformers בתוך ה-container, דבר שמתועד כצריכה של כ-500 MB לכל תהליך worker. הגדרת RAG_EMBEDDING_ENGINE=ollama מעבירה את המשימה הזו לשרת המודלים שאתם כבר מריצים. AUDIO_STT_ENGINE=webapi מונע טעינה של מודל speech-to-text מקומי. ב-SQLite, כאשר DATABASE_POOL_SIZE אינו מוגדר, ה-pool חוזר לגודל פנימי גדול וכל חיבור מגדיל את ה-page cache ומיפוי הזיכרון שלו; לכן, בשרת קטן, הגדירו את 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 הוא הפתרון המתאים כאשר נדרשת מערכת ניהול זהויות ולא רק תיבת התחברות: הוא מתעד תמיכה בחיבורי LDAP ו-OAuth2, וכולל לוח בקרה (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 המוגדר כברירת מחדל מפעיל 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

git pull נעצר עם התנגשות אם ערכת את הקובץ המנוהל docker-compose.yml, ואז השדרוג מוחל באופן חלקי בלבד. הכנס את השינויים שלך ל-docker-compose.override.yml, שהפרויקט מספק למטרה זו, ושמור סודות ב-.env. שני הקבצים אינם במעקב (untracked), לכן git pull אינו משנה אותם.

הפנה את LibreChat לשרת המודלים שלך באמצעות 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', כיוון שה-image מאפשרת רק את ה-host המוגדר ב-localhost ועונה לבקשות עבור כל hostname אחר בשגיאת blocked-host במקום להציג את היישום.

OrionChat מרחיקה לכת עוד יותר ואין לה כלל רכיב שרת. יש לשכפל (clone) את ה-repository ולהגיש את התיקייה באמצעות שרת ה-web שכבר מותקן אצלכם, או לפתוח את index.html ישירות מהדיסק. מפתחות API נשמרים ב-localStorage של הדפדפן, היסטוריית הצ'אט נשארת בדפדפן, והיישום מוחק את הצ'אטים הישנים ביותר ברגע שהכמות עוברת את 512.

באף אחד מהפרויקטים אין מנגנון התחברות, כיוון שאין להם שרת שיכול לאמת משתמש. במחשב נייד זה תקין. ב-VPS המשמעות היא שהדף לעולם לא צריך להתפרסם ב-0.0.0.0, ויש נקודה שקל לפספס: הדפדפן הוא זה שקורא למודל, לא השרת.

עובדה זו קובעת היכן ניתן להשתמש בשני הכלים הללו. הדפדפן שלכם חייב להגיע ל-Ollama ישירות, לכן Ollama חייב להאזין לכתובת שאינה רק loopback, ול-Ollama אין שום מנגנון אימות. מכאן נובעים שני כללים של הדפדפן. דף המוגש ב-HTTPS אינו יכול לקרוא ל-endpoint ב-HTTP רגיל, וה-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 אחר תסורב עם 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 כפי שהדפיס קודם לכן. בצעו שינוי זה רק כאשר firewall או proxy עם אימות כבר שולטים על הגישה לפורט, כיוון שפורט 11434 פתוח הוא שרת מודל חשוף, וסורקים המוניים מגיעים לפורט ציבורי חדש במהירות. ה-SSH tunnel להלן פותר את הבעיה כולה: הדף רץ אז על origin מסוג localhost, ש-Ollama מאפשר כברירת מחדל, והפורט לעולם לא יוצא אל מחוץ לשרת.

האם כל אחד מהם יכול להשתמש בנקודת קצה מרוחקת של 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-ים המופרדים בנקודה-פסיק.

LibreChat יכול לעשות זאת דרך ה-baseURL של נקודת הקצה המותאמת שהוצגה לעיל. בקשה זו גם היא יוצאת מהשרת, לכן שום חוק דפדפן אינו חל עליה. אותו base URL ואותו מפתח placeholder עובדים גם מחוץ לחלון הצ'אט, וזה כל מה שנדרש כדי להפנות סוכן קידוד למודל שאתם כבר מארחים.

Hollama ו-OrionChat יכולים להפנות לכל נקודת קצה שתקלידו בהגדרות שלהם, אך הבקשה יוצאת מהדפדפן שלכם. כל מה שנכתב בסעיף הקודם חל עליהם ולא על שום דבר אחר כאן.

הפרדת הממשק מהמודל היא התועלת המשמעותית ביותר שנקודת קצה מרוחקת מעניקה לכם. הציבו את הממשק על מכונה קטנה ואת המודל במקום שבו נמצא הזיכרון. זהו גם השלב להחליט האם Ollama או vLLM צריכים לשרת את הבקשות, כיוון ששניהם מתנהגים בצורה שונה מאוד ברגע שכמה אנשים מדברים עם המודל בו-זמנית. אם שרת המודל עדיין לא קיים, התחילו ב-הרצת Ollama על גבי VPS, ועבור מכונה מבוססת CPU בלבד, קראו כיצד Ollama משתווה ל-llama.cpp לפני שתבחרו מריץ.

לעולם אל תפרסמו ממשק צ'אט ללא אימות גישה בכתובת 0.0.0.0

דף אבטחת המידע של Open WebUI מציין כי הפרויקט "נבנה עבור רשתות פרטיות ומהימנות, בדומה לתשתיות אחרות באירוח עצמי כגון מסדי נתונים, מאגרי מכולות ושרתי CI", וממליץ להציב אותו מאחורי 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, לאחר מכן בצעו העברה (forwarding) למה שדרוש: 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 על ה-loopback. הדפוס חזק רק כפי שהגדרת ה-SSH שלכם חזקה, לכן שלבו זאת עם SSH מבוסס מפתחות בלבד ו-sshd מוקשח.

דפוס שני: reverse proxy המבצע אימות לפני שהבקשה מגיעה ליישום. השאירו את היישום על ה-loopback, תנו ל-proxy לנהל את פורט 443, והציבו מנגנון single sign-on בחזית. Traefik המנוהל על ידי Docker Compose labels עם Authentik כספק זהות מעניק לכל יישום בשרת התחברות אחת ותעודה אחת. כאשר Open WebUI נמצא מאחורי TLS (אבטחת שכבת תעבורה), הגדירו את WEBUI_SESSION_COOKIE_SECURE=true ואת WEBUI_SESSION_COOKIE_SAME_SITE=strict. קצרו גם את JWT_EXPIRES_IN מברירת המחדל של ארבעה שבועות, כיוון ש-Open WebUI מתעד כי ללא Redis, התנתקות אינה מבטלת את ה-token: הוא נשאר שמיש עד לפקיעתו העצמית.

דפוס שני אינו מציל פרויקטים מבוססי דפדפן בלבד. proxy בחזית הדף אינו מגן על ה-endpoint של המודל, ופנייה (fetch) מאותו דף לשם מתחם אחר אינה נושאת את ה-session cookie שלכם, לכן ה-proxy המאמת בחזית Ollama משיב בהפניה לטופס התחברות והצ'אט נכשל. או שתנתבו את ה-endpoint של המודל תחת אותו שם מתחם של הדף, או שתשתמשו בדפוס הראשון.

במה לבחור

אם מישהו מלבדך עומד להשתמש במערכת, הרץ את Open WebUI. יש לה מערכת חשבונות אמיתית, משתמשים חדשים מגיעים לתור אישור, והמפתחים שלה מפרסמים הנחיות אבטחה שניתן ליישם. אם דרוש לך LDAP או לוח בקרה למנהל מערכת, הרץ את LibreChat, וודא באמצעות docker stats שששת השירותים שלה יחד עם המודל שלך אכן נכנסים במשאבי המערכת לפני שאתה מסתמך עליה. אם מדובר באדם אחד על שרת קטן שבו המודל כבר תפס את רוב ה-RAM, הגש את Hollama או את OrionChat דרך SSH tunnel ותן לדפדפן לנהל את ה-state. התשובה השגויה בשרת VPS היא חשיפת כל אחד מהם ב-0.0.0.0 ללא מנגנון הזדהות לפניו.

FAQ

Is Open WebUI safe to expose directly on a public IP?

Its own hardening page describes it as software for private, trusted networks, in the same category as a database or a CI server. It does have real accounts, and the first account becomes an administrator while later ones stay pending until approved, so it is far safer than a UI with no login. Still put it behind a reverse proxy with TLS and, where you can, single sign-on. Publish the container port as 127.0.0.1:3000:8080 so Docker's own iptables rules cannot open it to the internet behind your back.

Which Open WebUI alternative uses the least RAM on a VPS?

The browser-based ones, Hollama and OrionChat, because the application runs on the client. The server only sends static files, and OrionChat needs no application container at all. Open WebUI keeps a Python process, a database and, by default, a local embedding model in memory, documented at around 500 MB per worker for the embedding model alone. Confirm the numbers on your own box with docker stats --no-stream, because they move with the features you turn on.

Can these chat UIs use an Ollama server on another host?

Open WebUI and LibreChat can, and their server makes the connection, so no browser rule applies. Set OLLAMA_BASE_URL for Open WebUI, or baseURL in a custom endpoint for LibreChat. For vLLM or another OpenAI-compatible server, use OPENAI_API_BASE_URL with the /v1 suffix and a non-empty API key. Hollama and OrionChat can also point anywhere, but the request comes from your browser, so the endpoint must be reachable from your browser as well.

Why can my browser chat UI not reach Ollama?

Two causes cover nearly every case. Ollama binds 127.0.0.1:11434 by default, so a browser on another machine never reaches it until OLLAMA_HOST changes. And Ollama accepts cross-origin requests from localhost only, so a page served from your own domain is refused with No 'Access-Control-Allow-Origin' header is present on the requested resource until that origin is listed in OLLAMA_ORIGINS. If the page is HTTPS and the endpoint is HTTP, the browser blocks the call as mixed content before Ollama ever sees it. Set both variables in a systemctl edit ollama.service override, or forward the port over SSH and the problem disappears.