SSD Nodes Learn 🎉 VPS החל מ־$5.50/חודש
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-13

חלופות ל-Firecrawl בהתקנה עצמית על שרת VPS

השוואה בין Draco, Hound וגרסת ה-Self-hosted של Firecrawl. נבדוק צריכת RAM, דרישות דפדפן headless ותאימות API. המדריך כולל התקנה נעולה וחיבור לסוכן באמצעות פרוטוקול MCP.

מה חלופה ל-Firecrawl בהתקנה עצמית חייבת לבצע

לחלופה ל-Firecrawl בהתקנה עצמית יש תפקיד אחד: לקבל URL ולהחזיר את הדף כ-markdown נקי שסוכן (agent) יכול לקרוא. ה-APIs המנוהלים גובים תשלום לפי דף, כך שהחשבון גדל ככל שהסוכן שלכם סקרן יותר, בעוד ששרת VPS שאתם כבר משלמים עליו יכול לבצע את אותה עבודה. הפרויקטים נבדלים בשאלה אחת: האם דפדפן headless (מנוע דפדפן אמיתי שרץ ללא חלון) חייב לעלות על השרת שלכם?

התשובה לשאלה זו קובעת את צריכת הזיכרון, את העלות של כל דף, ואילו דפים יחזרו ריקים. מדריך זה משווה בין Draco, Hound והגרסה של Firecrawl להתקנה עצמית, מתקין את הקלה ביותר בגרסה נעולה, ומחבר אותה לסוכן באמצעות MCP (model context protocol).

ארבעת הפרויקטים, ומהות כל אחד מהם

Draco הוא קובץ בינארי יחיד, כתוב ב-Rust, תחת רישיון MIT או Apache-2.0. גרסה v0.20.5 פורסמה ב-16 ביולי 2026. draco scrape <url> מדפיס Markdown ל-stdout. draco serve מריץ daemon המאזין ב-127.0.0.1:3002, הפורט שבו משתמש Firecrawl. הוא אינו מופץ כ-container image ואינו מפעיל דפדפן.

Firecrawl self-hosted הוא המנוע שמאחורי המוצר המנוהל, תחת רישיון AGPL-3.0. ה-docker-compose.yaml שלו מגדיר שבעה שירותים: playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb ו-foundationdb-init. אתם מקבלים את תור הסריקה האמיתי, במחיר של הרצת מערכת מבוזרת קטנה.

Hound נמצא במאגר ה-master-fetch ומופץ ל-PyPI כ-hound-mcp, תחת רישיון MIT, גרסה 13.0.1 נכון ל-3 באוגוסט 2026. הוא דורש Python 3.11 ומעלה. הוא בראש ובראשונה שרת MCP ורק לאחר מכן כלי שליפה: הוא מנסה HTTP רגיל, ומפעיל דפדפן Patchright רק כאשר השליפה הרגילה נחסמת.

Trawl מופיע כאן כיוון שאנשים נתקלים בו בזמן חיפוש האחרים, והוא מבצע עבודה שונה. הוא פותר אתגרי JavaScript ו-CAPTCHA באמצעות דפדפן Firefox עם טביעת אצבע מותאמת, כתחליף ל-FlareSolverr ב-stack של מדיה ב-*arr. הוא אינו מחלץ Markdown. הסעיף על כללי התנהגות להלן מסביר מדוע הבחנה זו קובעת האם הוא שייך ל-stack של הסוכנים שלכם בכלל.

מדוע מאגר הדפדפנים הוא הגורם לקריסת שרתי VPS קטנים

כל לשונית דפדפן פתוחה היא תהליך רינדור נפרד המחזיק DOM (מודל אובייקטים של מסמך) משלו ו־heap של JavaScript משלו. לכן, צריכת הזיכרון גדלה בהתאם למספר הדפים הפתוחים בו-זמנית, ולא לפי מספר הדפים הנטענים ביום. שני פרויקטים אלו מציינים את העלות הזו בקובצי ה-compose שלהם.

ChartMemory ceilings each project sets in its own compose file (GB)
The data behind this chart
[
  {
    "label": "Firecrawl api",
    "memory_limit_gb": 8
  },
  {
    "label": "Firecrawl playwright",
    "memory_limit_gb": 4
  },
  {
    "label": "Hound (browser included)",
    "memory_limit_gb": 3
  }
]

קובץ ה-compose של Firecrawl מגביל את ה-container מסוג api ל-8 GB ואת ה-container מסוג Playwright ל-4 GB, עם מגבלות swap תואמות. קובץ ה-compose של Hound מגדיר 3 GB עבור container אחד המכיל Chromium ארוז. אלו הן תקרות שבחרו הפרויקטים; מדובר בנתונים מפורסמים ולא במדידות של מערכת במצב מנוחה. בנוסף, Redis, RabbitMQ, PostgreSQL ו-FoundationDB דורשים את חלקם מעבר למספרים של Firecrawl.

תקרה הגבוהה מכמות ה-RAM שברשותכם אינה מועילה. כאשר השרת אוזל מזיכרון, ה-kernel מבצע out-of-memory killer שמסיים תהליך, ולכן ה-container נעלם מ-docker compose ps ללא שגיאה שנכתבת ביומן היישום. קראו את dmesg -T | tail לאחר כל אתחול שאינכם יכולים להסביר. הקצו 8 GB עבור כל ה-stack של Firecrawl והתייחסו ל-4 GB כרף מינימלי לשרת בדיקות. הגדרת המספרים לכל שירות מוסברת ב-מגבלות זיכרון ב-Docker Compose.

פרט נוסף בנוגע לדפדפנים גוזל מאנשים ערב שלם. Docker מעניק ל-container זיכרון משותף של 64 MB ב-/dev/shm, ו-Chromium מציב שם מאגרי רינדור, לכן הוא קורס בדפים כבדים. שני ה-stacks של הדפדפנים מעלים ערך זה: קובץ ה-compose של Hound כולל את shm_size: "1gb". העתיקו שורה זו לכל image שאתם בונים סביב Playwright.

איכות החילוץ בדפים עתירי JavaScript

בדפי HTML סטטיים, בבלוגים מרונדרים בצד השרת, בדפי תיעוד או בכתבות חדשות, כל אלו מחזירים תוכן Markdown כמעט זהה והמהיר מביניהם מנצח. ההבדל מופיע בדפים מרונדרים בצד הלקוח, שבהם ה-HTML שמתקבל הוא מעטפת ריקה והטקסט מגיע באמצעות JavaScript לאחר הטעינה.

Draco מסלים את הפעולה בשלבים. שלב 0 ושלב 1 מנתחים את ה-HTML ללא JavaScript כלל. שלב 2 מריץ את ה-JavaScript של הדף בתוך V8 isolate פנימי, שהוא מנוע ה-JavaScript ללא דפדפן סביבו, וה-README מציין שקוד הדף אינו מקבל שם הרשאות גישה למארח. זה מכסה יישומי Single-page רבים בשבריר מהזיכרון שצורך דפדפן. כאשר Draco נתקל במחסום שאינו יכול לעבור, draco scrape יוצא עם קוד 3, needs_browser. בדקו זאת בסקריפטים, כיוון שקובץ ריק עם קוד יציאה אפס הוא הכשל שמרעיל את ההקשר של סוכן (agent) בשקט:

draco scrape https://example.com > page.md
echo "exit=$?"

ה-playwright-service של Firecrawl מפעיל Chromium אמיתי, ולכן הוא מרנדר את מה שדפדפן מרנדר. הגרסה בהתקנה עצמית (self-hosted) אינה המוצר בענן: התיעוד מציין שלמופעים בהתקנה עצמית אין גישה ל-Fire Engine, לכן יכולות מניעת החסימה וסבב ה-IP של שירות הענן חסרות, ונקודות הקצה /agent ו-/browser אינן נתמכות. Hound ממוקם באמצע במכוון. הוא מבצע שליפה ב-HTTP ומסלים לפי בקשה, והדפדפן החם שלו נסגר לאחר זמן המתנה (idle timeout), כך ששרת שקט נשאר קרוב לצריכת הבסיס שלו.

התקנת Draco עם גרסה נעולה

הקובץ README מתעד מתקין בשורה אחת. קראו מה הוא עושה לפני שאתם מריצים אותו ישירות לתוך shell: הוא מתקין לנתיב $HOME/.draco/bin/draco, הוא תמיד לוקח את גרסת ה-latest, והוא לא בודק חתימה או hash. בשרת, נעלו את הגרסה ואמתו את ההורדה.

cd /tmp
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/draco-linux-x86-64.tar.gz
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS

הפקודה מדפיסה draco-linux-x86-64.tar.gz: OK. שורת FAILED משמעותה שהבתים שבידיכם אינם הבתים שהפרויקט פרסם, לכן מחקו אותם והתחילו שוב.

mkdir -p draco-v0.20.5
tar -xzf draco-linux-x86-64.tar.gz -C draco-v0.20.5
sudo install -m 755 "$(find draco-v0.20.5 -type f -name draco | head -n1)" /usr/local/bin/draco
draco scrape https://example.com

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

הריצו את ה-daemon תחת חשבון משתמש ייעודי ולא תחת משתמש ה-login שלכם. כתבו את /etc/systemd/system/draco.service:

[Unit]
Description=Draco fetch daemon
After=network-online.target
Wants=network-online.target

[Service]
User=draco
ExecStart=/usr/local/bin/draco serve --host 127.0.0.1 --port 3002 --max-concurrency 4
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target
sudo useradd --system --no-create-home --shell /usr/sbin/nologin draco
sudo systemctl daemon-reload
sudo systemctl enable --now draco
curl -s http://127.0.0.1:3002/health

/health משיב ברגע שה-daemon מאזין. Connection refused משמעותו שהוא אינו מאזין, לכן קראו את journalctl -u draco -n 50. הסיבה הנפוצה היא תהליך אחר שכבר תופס את פורט 3002, כיוון שזהו גם הפורט המוגדר כברירת מחדל של Firecrawl, ו---port משנה את אחד מהם. הרחבה על קובצי unit: יחידות שירות וטיימרים של systemd.

כעת משכו את המידע כפי שהסוכן שלכם יעשה:

curl -X POST http://127.0.0.1:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

שמירה על ה-fetch daemon מחוץ לאינטרנט הציבורי

ממשק fetch API ללא אימות הוא proxy פתוח. כל מי שיכול להגיע לפורט יכול לגרום לשרת שלכם לבקש כל URL תחת כתובת ה-IP שלכם, ודוחות השימוש לרעה יגיעו לספק שלכם, לא אליהם. דגלי ה-serve המתועדים של Draco אינם כוללים מפתח API, לכן ההגנה חייבת להתבצע ברמת הרשת. השאירו את ה-bind המוגדר כברירת מחדל ב-127.0.0.1 כאשר הסוכן רץ על אותו שרת. כאשר הסוכן נמצא במקום אחר, הציבו את שני הקצוות בתוך מנהרה פרטית; VPN מסוג WireGuard שאתם מארחים בעצמכם הוא הפתרון המקובל, ובצעו bind לכתובת המנהרה במקום ל-0.0.0.0. לאחר מכן, בדקו ממכונה אחרת שה-IP הציבורי אינו מגיב לכלום. יסודות ה-firewall מסוג ufw ו-חשבונות משתמש בעלי הרשאות מינימליות מכסים את שני החלקים של משימה זו.

האם קוד הסוכן שלכם ישתנה? תאימות API בפועל

Draco תומך בנתיבי Firecrawl v1: /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape ו-/v1/search, וה-README שלו מציין ששדות לא מוכרים מתקבלים ומתעלמים מהם. סוכן שכבר מבצע POST ל-/v1/scrape זקוק רק ל-base URL חדש ותו לא. עקבו אחר השינויים בצד השני: דף ה-self-hosting של Firecrawl בודק כעת עם /v2/crawl, וה-SDKs הנוכחיים משתמשים ב-v2, לכן לקוח v2 המופנה ל-Draco יבקש נתיב ש-Draco אינו מפרסם. בדקו כל קריאה עם curl לפני עריכת קוד הסוכן, וקראו את גוף ה-JSON במקום להסתמך על קוד הסטטוס, כיוון ששמות השדות הם המקום שבו המימושים הללו מתחילים להיבדל זה מזה.

Robots.txt, הגבלות קצב, והגבולות המומלצים

Draco קורא את robots.txt כברירת מחדל, ו---ignore-robots מבטל זאת. Firecrawl מתעד את אותה ברירת מחדל. השאירו את שניהם כפי שהם. לאחר מכן, הגדירו קצב עבודה משלכם: --delay קובע את מספר המילי-שניות בין בקשות, ו---max-concurrency מגביל את מספר המשימות המקבילות, כאשר 8 הוא ערך ברירת המחדל של ה-daemon. ערך של 2 עד 4 הוא ידידותי יותר לחיבור ב-VPS משותף ולעיתים רחוקות איטי יותר בסיכום הכולל, כיוון שאתר שמתחיל להטיל עליכם הגבלות קצב (rate limiting) גורם לעיכובים ארוכים יותר מהזמן שנחסך באמצעות מקביליות. בצעו Cache למידע שאתם מושכים, כך שהרצה שנייה של ה-agent לא תעלה למקור דבר. זהו גם הסעיף הזול ביותר ב-שליטה בעלויות של סוכן AI.

חומות אתגר (Challenge walls) הן נושא נפרד, ו-Trawl נבנה בדיוק עבורן: Cloudflare Turnstile, reCAPTCHA, hCaptcha ו-GeeTest. חומת אתגר היא מצב שבו אתר מסרב במפורש לתעבורה אוטומטית. עקיפת חומות אלו מעמידה אתכם בניגוד לתנאי השימוש של האתר, ובמקומות מסוימים אף בניגוד לחוק, לכן מדריך זה עוסק בתשתית המשיכה (fetching) ועוצר שם. אותן טכניקות שמעבירות אתכם דרך חומה הן בדיוק אלו שבעלי אתרים מנטרים וחוסמים, מה שהופך כל pipeline המבוסס עליהן לשביר וגם ללא מנומס. כאשר מקור מידע הוא בעל חשיבות רבה, חפשו את ה-RSS feed שלו, את ה-API הציבורי שלו, או ייצוא נתונים מרוכז. כל אחת מאפשרויות אלו זולה יותר להפעלה ואף אחת מהן לא תפסיק לעבוד ברגע שהחומה תשתנה.

חיבור לסוכן באמצעות MCP

MCP (ראשי תיבות של Model Context Protocol) הוא הממשק שבו סוכן משתמש כדי להפעיל כלי. Draco כולל שרת MCP בתוך אותו קובץ בינארי, הפועל מעל stdio:

{ "mcpServers": { "draco": { "command": "draco", "args": ["mcp"] } } }

הכלים מופיעים לאחר מכן עבור הסוכן כ-draco_scrape, draco_search וקבוצת ה-draco_interact_*. שימוש ב-stdio עובד רק כאשר תהליך הסוכן והקובץ הבינארי נמצאים על אותה מכונה, כיוון שהתעבורה מתבצעת דרך הקלט הסטנדרטי של התהליך. עבור סוכן הנמצא במארח אחר, Hound מגיש MCP מעל HTTP במקום זאת: hound --http --host 127.0.0.1 --port 8765 מפרסם נקודת קצה ב-http://127.0.0.1:8765/mcp, אליה ניתן להגיע דרך המנהרה. בחירת שיטת התעבורה והגדרת המשאבים לחשיפה מפורטים ב-הרצת שרתי MCP על גבי VPS.

שליפת זוגות באמצעות חיפוש. סוכן שמסוגל רק לבצע שליפה ממתין שתספק לו כתובות URL. הוסף מופע SearXNG לחיפוש באירוח עצמי והוא יוכל למצוא אותן בעצמו, באותו אופן שבו פועלת יכולת חיפוש בדפדפן המבוססת על SearXNG. ברגע שה-daemon פעיל, הוא משמש כשירות משותף עבור כל אחד מ-סוכני ה-AI באירוח עצמי שתבחר להריץ.

FAQ

האם אני זקוק לדפדפן headless כדי למשוך דפים עבור סוכן AI?

עבור רוב הדפים, התשובה היא לא. תיעוד, בלוגים ומאמרי חדשות המרונדרים בצד השרת מתקבלים במלואם באמצעות שליפת HTTP פשוטה בצירוף המרה מ-HTML ל-markdown; זהו התהליך ש-Draco מבצע בשכבות הנמוכות שלו, במהירות של כ-300 מילי-שניות לדף ללא דפדפן, לפי נתוני הפרויקט. דפדפן נדרש עבור יישומים המרונדרים בצד הלקוח, שבהם ה-HTML המתקבל הוא מעטפת ריקה. ה-V8 isolate של Draco מכסה חלק ניכר מהמקרים הללו ללא תהליך דפדפן, והוא מסיים את פעולתו עם קוד 3, needs_browser, כאשר הדבר אינו מתאפשר.

כמה זיכרון RAM דורש Firecrawl בהתקנה עצמית על גבי VPS?

קובץ ה-compose שלו מגדיר תקרה של 8 GB עבור ה-container של ה-api ו-4 GB עבור ה-container של Playwright, כאשר אותו stack מפעיל גם את Redis, RabbitMQ, PostgreSQL ו-FoundationDB. תכננו עבור 8 GB. במכונה עם 2 GB, מנגנון ה-out-of-memory killer של ה-kernel יסיר containers תחת עומס; הסימן הראשון לכך הוא container שמתחיל מחדש ב-docker compose ps ללא מידע מועיל בלוג היישום, לכן יש לאמת זאת באמצעות dmesg -T | tail.

האם Draco מהווה תחליף ישיר ל-API של Firecrawl?

עבור ה-endpoints של v1, התשובה היא קרוב לכך. הוא מספק את /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape ו-/v1/search, והוא מתעלם משדות בקשה שאינו מכיר, כך שלקוח שנכתב עבור Firecrawl v1 זקוק בדרך כלל רק ל-base URL חדש. זהו אינו המוצר המנוהל: אין מאחוריו מאגר proxy מנוהל, והנתיבים החדשים של v2 ב-Firecrawl אינם חלק מהממשק. ודאו כל קריאה שהסוכן שלכם מבצע באמצעות curl תחילה.

האם אירוח עצמי של כלי סריקה (scraper) אומר שאני יכול להתעלם מ-robots.txt?

לא. המקום שבו הקוד רץ אינו משנה דבר לגבי מה שאתר פרסם או מה שהתנאים שלו מתירים. גם Draco וגם Firecrawl מכבדים את robots.txt כברירת מחדל, וקיים flag לעקיפה עבור אתרים שבבעלותכם או שיש לכם אישור כתוב לסרוק. מגבלות קצב (rate limits) נאכפות בצד המרוחק בכל מקרה, לכן --delay מנומס עם רמת מקביליות נמוכה ישמור על כתובת ה-IP שלכם פעילה. stack שמתפקד רק על ידי עקיפת חומות הגנה הוא stack שעלול להפסיק לעבוד ללא התראה.

#scraping#firecrawl#ai-agents#self-hosting#markdown