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

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

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

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

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

• זיכרון לצד המודל. שרת המודל הוא התהליך היקר ביותר על השרת. כל מגה-בייט שתופס הממשק הוא מגה-בייט שאינו זמין למודל.
• אימות. בחלק מהפרויקטים הללו קיימים חשבונות משתמש ותפקידים. אחרים מניחים שהם התהליך היחיד שרץ על המחשב שלכם, ולכן אין להם מנגנון התחברות כלל.
• הסקה מרחוק (Remote inference). ממשק משתמש שיכול לגשת רק ל-127.0.0.1:11434 מחייב שהמודל ירוץ על אותו שרת שבו נמצא הממשק.
• תחזוקה. מכולה (container) אחת עם קובץ 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 מופעל מתוך 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 משלו ופורט מפורסם מתעלם מחוקי ה-deny של ufw.

גשו לדף דרך מנהרה (tunnel) או proxy, שניהם מתוארים בהמשך, ולאחר מכן צרו את החשבון הראשון. חשבון זה הופך למנהל המערכת. הרשמות מאוחרות יותר נוצרות עם התפקיד 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 וה-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 הוא הפתרון המתאים כאשר נדרשת מערכת ניהול זהויות ולא רק תיבת התחברות: הוא מתעד תמיכה בהתחברות דרך 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, אשר מוחקת את המכולה בעת עצירה, ולכן הממשק לא יחזור לאחר reboot. מאחורי reverse proxy, יש להוסיף את -e VITE_ALLOWED_HOSTS='chat.example.com', כיוון שה-image מאפשרת רק את ה-host localhost ועונה לבקשות עבור כל hostname אחר בשגיאת blocked-host במקום להציג את היישום.

OrionChat מרחיקה לכת עוד יותר ואין לה רכיב שרת כלל. שכפלו את ה-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 מאפשר כברירת מחדל, והפורט לעולם לא יוצא אל מחוץ לשרת.

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

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

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

הפרדת הממשק מהמודל היא התועלת המשמעותית ביותר ש-endpoint מרוחק מעניק לכם. הציבו את הממשק על שרת קטן ואת המודל במקום שבו נמצא הזיכרון. זהו גם השלב להחליט האם 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 יחד עם Authentik כספק זהות מעניק לכל יישום בשרת התחברות אחת ותעודה אחת. כאשר Open WebUI נמצא מאחורי TLS (אבטחת שכבת תעבורה), הגדירו את WEBUI_SESSION_COOKIE_SECURE=true ו-WEBUI_SESSION_COOKIE_SAME_SITE=strict. קצרו גם את JWT_EXPIRES_IN מברירת המחדל של ארבעה שבועות, כיוון ש-Open WebUI מתעד כי ללא Redis, יציאה מהמערכת (sign-out) אינה מבטלת את ה-token: הוא נשאר שמיש עד לפקיעתו העצמית.

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

במה לבחור

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

FAQ

האם בטוח לחשוף את Open WebUI ישירות לכתובת IP ציבורית?

דף התיעוד של התוכנה מגדיר אותה ככלי לרשתות פרטיות ומהימנות, באותה קטגוריה של מסד נתונים או שרת CI. קיימת בה מערכת חשבונות, והחשבון הראשון הופך למנהל מערכת בעוד החשבונות הבאים נשארים pending עד לאישורם, לכן היא בטוחה משמעותית מממשק ללא אימות. עם זאת, יש להציב אותה מאחורי reverse proxy עם TLS, ובמידת האפשר, להשתמש ב-single sign-on. פרסמו את הפורט של ה-container כ-127.0.0.1:3000:8080 כדי שחוקי ה-iptables של Docker לא יפתחו אותו לאינטרנט ללא ידיעתכם.

איזו חלופה ל-Open WebUI צורכת הכי פחות RAM ב-VPS?

החלופות מבוססות הדפדפן, Hollama ו-OrionChat, כיוון שהיישום רץ בצד הלקוח. השרת שולח רק קבצים סטטיים, ו-OrionChat אינה דורשת container כלל. Open WebUI מחזיקה תהליך Python, מסד נתונים ומודל embedding מקומי בזיכרון, שצריכתם מוערכת בכ-500 MB לעובד עבור המודל בלבד. אשרו את הנתונים בשרת שלכם באמצעות docker stats --no-stream, כיוון שהם משתנים בהתאם לפיצ'רים המופעלים.

האם ממשקי צ'אט אלו יכולים להשתמש בשרת Ollama במארח אחר?

Open WebUI ו-LibreChat מסוגלות לכך, והחיבור מתבצע מהשרת שלהן, לכן אין מגבלות דפדפן. הגדירו OLLAMA_BASE_URL עבור Open WebUI, או baseURL בתוך endpoint מותאם אישית עבור LibreChat. עבור vLLM או שרת אחר התואם ל-OpenAI, השתמשו ב-OPENAI_API_BASE_URL עם הסיומת /v1 ומפתח API שאינו ריק. Hollama ו-OrionChat יכולות גם הן להצביע לכל יעד, אך הבקשה מגיעה מהדפדפן שלכם, לכן ה-endpoint חייב להיות נגיש מהדפדפן עצמו.

מדוע ממשק הצ'אט בדפדפן שלי לא מצליח להגיע ל-Ollama?

שתי סיבות מכסות כמעט את כל המקרים. Ollama מאזינה כברירת מחדל ל-127.0.0.1:11434, לכן דפדפן במכונה אחרת לא יגיע אליה עד לשינוי OLLAMA_HOST. בנוסף, Ollama מקבלת בקשות cross-origin מ-localhost בלבד, לכן דף המוגש מהדומיין שלכם יידחה עם No 'Access-Control-Allow-Origin' header is present on the requested resource עד שהמקור יירשם ב-OLLAMA_ORIGINS. אם הדף משתמש ב-HTTPS וה-endpoint ב-HTTP, הדפדפן יחסום את הקריאה כתוכן מעורב (mixed content) עוד לפני ש-Ollama תראה אותה. הגדירו את שני המשתנים בתוך override של systemctl edit ollama.service, או בצעו port forwarding דרך SSH והבעיה תיפתר.