פורסם

SearXNG

מנוע metasearch באירוח עצמי: הוא שולח כל שאילתה לשירותי חיפוש רבים במקביל וממזג את התוצאות, בלי cookies ובלי פרופיילינג מול השירותים האלה. מתאים למשק בית או לצוות שרוצים דף חיפוש משלהם, או backend חיפוש פרטי לכלי AI.

משאבים לפי רמת עומס

מה האפליקציה עצמה צריכה בכל רמה, לצד מה שאנחנו ממליצים לשרת שמריץ רק אותה.

רמה	מה זה אומר	דרישות האפליקציה	מומלץ
קלהערכה	עד 5 משתמשים, כ-300 חיפושים ביום (אחד בכל פעם), מנועים והגדרות ברירת מחדל, favicons כבויים; למשל דף חיפוש למשק בית או חיפוש web לאפליקציית צ'אט AI אחת.	0.5 vCPU · 0.5 GiB RAM · 0.6 GiB דיסק	0.72 vCPU · 2.1 GiB RAM · 10.005 GiB דיסק
בינוניהערכה	עד 25 משתמשים או כמה כלי AI, כ-3,000 חיפושים ביום, עד 4 חיפושים במקביל (4 ה-blocking threads של Granian), מנועים ברירת מחדל, favicons כבויים.	1 vCPU · 1 GiB RAM · 0.85 GiB דיסק	1.32 vCPU · 2.7 GiB RAM · 10.293 GiB דיסק
כבדהערכה	עד 100 משתמשים או סוכני AI עמוסים, כ-15,000 חיפושים ביום, 4 חיפושים במקביל רוב היום, ‏worker אחד של Granian כפי ש-upstream ממליצים, favicons כבויים.	1.5 vCPU · 1.5 GiB RAM · 1.35 GiB דיסק	1.92 vCPU · 3.3 GiB RAM · 10.868 GiB דיסק

מומלץ = דרישות האפליקציה + baseline של המערכת + מרווח ביטחון (headroom), לפי מדיניות ה-sizing ‏2026.10.0. האפשרויות נשארות בברירת המחדל. ״הערכה״ פירושה שהמקורות לא נותנים מספר למקרה הזה, ולכן הוא מחושב מהם בשיטה שמפורטת תחת רכיבים. איך המספרים נבנים

לחישוב ב-Stack Sizer

קבצים מוכנים להפעלה

רמת תמיכה נתמך

תבנית Compose מהמקורות הרשמיים; עוד לא נבדקה בהרצה.

צור docker-compose

רכיבים

מה כל רכיב צריך בכל רמת עומס, לפני baseline ו-headroom.

vCPU / GiB RAM / GiB דיסק
רכיב	קל	בינוני	כבד	מקורות
SearXNG (app)	0.5 / 0.5 / 0.6	1 / 1 / 0.85	1.5 / 1.5 / 1.35	[5][11][13][14][18][19][23][25][26][27]

איך ההערכות מחושבות

SearXNG · קל: אין מספר רשמי. RAM: אחד המתחזקים מריץ instances על VMs של 512 MB ‏(0.477 GiB), ו-worker אחד צרך 150 MB בדיווח משתמש; עוגל ל-0.5 GiB. ‏vCPU: ל-VM הזה יש 1 vCPU לכל המערכת; חיפוש אחד בכל פעם בעיקר ממתין למנועים, ולכן חצי ליבה. Disk: ‏image דחוס 98,301,157 B ‏(0.092 GiB) ועוד 271,150,592 B פרוס (0.253 GiB), ה-containerd store שומר את שניהם = ‏0.344 GiB. הנתונים הם caches בלבד: ה-cache של favicons מוגבל ל-50 MB וכבוי כברירת מחדל, ושאר ה-caches פגים אחרי 7 ימים. ‏0.344 ועוד 0.25 GiB ל-caches ולהגדרות ← 0.6.
SearXNG · בינוני: RAM: ‏0.5 GiB של light ×2 ל-4 חיפושים פעילים (GRANIAN_BLOCKING_THREADS=4), שכל אחד מחזיק תשובות של מנועים, ועוד ה-image proxy, שלפי התיעוד צורך זיכרון ← 1 GiB. ‏vCPU: ‏worker אחד של Granian (ברירת מחדל 1) הוא תהליך Python אחד, ולכן לכל היותר כליבה אחת. Disk: ‏image דחוס 98,301,157 B ‏(0.092 GiB) ועוד 271,150,592 B פרוס (0.253 GiB), ה-containerd store שומר את שניהם = ‏0.344 GiB. הנתונים הם caches בלבד: ה-cache של favicons מוגבל ל-50 MB וכבוי כברירת מחדל, ושאר ה-caches פגים אחרי 7 ימים. ‏0.344 ועוד 0.5 GiB ← 0.85.
SearXNG · כבד: vCPU: ליבה אחת ל-worker של Python שעסוק כל הזמן, ועוד 0.5 ל-runtime הקלט/פלט של Granian ול-TLS מול המנועים ← 1.5. RAM: ‏1 GiB של medium ועוד 0.5 GiB ל-caches בזיכרון בעומס קבוע ← 1.5. התיעוד ממליץ לא להוסיף workers, ולכן זו התקרה של container אחד. Disk: ‏image דחוס 98,301,157 B ‏(0.092 GiB) ועוד 271,150,592 B פרוס (0.253 GiB), ה-containerd store שומר את שניהם = ‏0.344 GiB. הנתונים הם caches בלבד: ה-cache של favicons מוגבל ל-50 MB וכבוי כברירת מחדל, ושאר ה-caches פגים אחרי 7 ימים. ‏0.344 ועוד 1 GiB ← 1.35.

פורטים

פורטים ציבוריים נועדו לגישה מחוץ ל-stack, בדרך כלל דרך reverse proxy; פורטים פנימיים נשארים ברשת של ה-stack עצמו.

רכיב	פורט	חשיפה	שימוש	מקורות
SearXNG	8080/tcp	ציבורי, דרך proxy	Web UI and search API (Granian HTTP); serve through an HTTPS reverse proxy	[1][5]

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

משתמש והרשאות (UID/GID)

המשתמש שהתהליך של כל קונטיינר רץ תחתיו, והנתיבים שהוא כותב אליהם. ‏bind mount לאחד הנתיבים האלה חייב להיות ניתן לכתיבה על ידי ה-UID:GID הזה.

רכיב	UID:GID	משתמש	מתחיל כ-root	כותב אל	מקורות
SearXNGנגזר	0:0	`root`	לא	`/etc/searxng/var/cache/searxng`	[3][5][6]

SearXNG: ב-image אין USER, ולכן entrypoint.sh רץ כ-root: הוא מעביר את ‎/etc/searxng ו-‎/var/cache/searxng לבעלות searxng ‏(977:977) אלא אם FORCE_OWNERSHIP=false, מריץ update-ca-certificates, ואז מריץ את granian ב-exec בלי להוריד הרשאות, כך שהשרת נשאר uid 0.

צמיחת אחסון

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

GiB לחודש
רכיב	קל	בינוני	כבד	מקורות
SearXNGנגזר	0	0	0	[9][18][19]

על מה מספרי הצמיחה נשענים

SearXNG: ‏SearXNG לא שומר היסטוריית חיפושים. ה-caches שלו חסומים: ערכים פגים אחרי 7 ימים עם תחזוקה כל שעה, וה-cache של favicons (כבוי כברירת מחדל) נחתך למגבלת ה-50 MB שלו. ה-disk של ה-preset כבר כולל אותם; הפעלת favicons עם מגבלה גדולה יותר מוסיפה עד המגבלה הזו.

שדרוג וחזרה לאחור

איך עוברים לגרסה חדשה בבטחה, ואיך חוזרים אחורה אם משהו נכשל.

קודם גיבוי

להעתיק את ה-volume של ההגדרות (‎/etc/searxng: ‏settings.yml וכל limiter.toml או favicons.toml). ה-volume של הנתונים מכיל caches בלבד. [9][18]

שלבי השדרוג

‏SearXNG מתפרסם ב-rolling release עם tags של תאריך ו-sha ובלי release notes: יש לעבור על היסטוריית ה-commits בין ה-tag הנוכחי ליעד, ובמיוחד commits שמסומנים ‎[mod] container. [24][30][31]נגזר‏upstream לא מפרסמים changelog; השינויים השוברים ב-container שלמטה נמצאו ב-commits מהסוג הזה.
להגדיר בקובץ ה-Compose את ה-tag המוצמד החדש, ואז להריץ docker compose pull ו-docker compose up -d. [9]
‏settings.yml ב-‎/etc/searxng נוצר רק כשהוא חסר, ולכן עדכון לעולם לא כותב אותו מחדש; אחרי העדכון כדאי להשוות אותו לתיעוד ההגדרות הנוכחי. [3][29]

חזרה לאחור

להצמיד את ה-tag הקודם ולהריץ docker compose up -d; אם settings.yml שונה עבור הגרסה החדשה, לשחזר את גיבוי ההגדרות. [9][24]נגזר‏upstream לא מתעדים downgrade. ‏SearXNG לא שומר נתוני משתמשים, רק הגדרות ו-caches, ולכן ההסקה היא שהרצת ה-tag הקודם בטוחה.

שינויים שוברים ידועים

בגרסה 2026.6.16: תבנית ההגדרות הפכה למינימלית (use_default_settings, ‏secret_key, ‏image_proxy), ו-settings.yml קיים כבר לא נבדק מולה לשינויים. [4][29]
בגרסה 2026.3.28: ה-Compose עבר למאגר searxng (שירותים core ו-valkey, ‏mount של ‎./core-config); ‏searxng-docker הוחלף. מעבר דורש להעביר את קובצי ההגדרות הישנים ולהפנות את כתובת ה-Valkey ל-valkey. [9][10][30]
בגרסה 2025.7.4: ‏Granian החליף את uWSGI ב-image: הגדרות uWSGI כבר לא חלות (את Granian מגדירים במשתני GRANIAN_*), וה-entrypoint משנה בעלות על ה-volumes בכל הפעלה אלא אם FORCE_OWNERSHIP=false. [13][31]

מגבלות

ה-API של JSON כבוי כברירת מחדל (search.formats הוא html בלבד): כלי AI כמו Open WebUI מקבלים 403 Forbidden עד שמוסיפים json ל-search.formats ב-‎/etc/searxng/settings.yml ומפעילים מחדש את ה-container. [16][17][28]
ל-SearXNG אין אינדקס משלו: התוצאות מגיעות ממנועים חיצוניים, שרואים את כתובת ה-IP של השרת ועלולים להחזיר CAPTCHA או לחסום אותו, ולכן איכות התוצאות משתנה לאורך זמן. [12][20][21]
לא מוגדר כ-instance ציבורי: ה-limiter (הגנה מבוטים) כבוי ואין Valkey. הפעלה שלו דורשת Valkey ו-limiter.toml שבו trusted_proxies כולל את ה-proxy, כי כברירת מחדל רק 127.0.0.0/8 ו-‎::1 מהימנים. [11][12]
‏worker אחד של Granian עם 4 blocking threads; ‏upstream ממליצים לא להוסיף workers (יותר משאבים, בעיות בזיהוי בוטים), ולכן container אחד לא גדל מעבר לרמת heavy. [5][13][14]

אבטחה

אין חשבונות משתמשים: ההעדפות נשמרות ב-cookies של הדפדפן, וכל מי שמגיע לכתובת יכול לחפש דרך כתובת ה-IP של השרת. ‏instance פרטי כדאי להחזיק מאחורי VPN או אימות ב-proxy. [12][20]
‏SEARXNG_SECRET גובר על secret_key ב-settings.yml; ‏SearXNG יוצא בהפעלה אם המפתח עדיין ה-placeholder ‏ultrasecretkey. יש לשמור אותו סודי וקבוע. [7][8][11]
ה-container רץ כ-root (אין USER ב-image) ומשנה בעלות על ה-volumes שלו בכל הפעלה; יש להגדיר FORCE_OWNERSHIP=false אם ה-volumes צריכים לשמור על בעלים אחרים. [3][6][9]

גיבוי

לגבות את ה-volume של ההגדרות (‎/etc/searxng): ‏settings.yml וכל limiter.toml או favicons.toml. ‏‎/var/cache/searxng מכיל caches ש-SearXNG בונה מחדש, ואין היסטוריית חיפושים לשמור. [9][18][19]