רוב האנשים מכניסים את Firecrawl לאותה מגירה עם ספריות סקרייפינג — משהו בסגנון pip install, כותבים סקריפט, וסיימנו. אבל ההגדרה הזו לא מדויקת, והפער חשוב עוד לפני שמקלידים פקודה אחת. Firecrawl בהפעלה עצמאית הוא לא ספרייה שמייבאים; זו מערכת שמריצים, והקמה שלה פירושה להפעיל שישה קונטיינרים של Docker שמדברים זה עם זה.
הרצתי את ה-stack העצמאי על Mac (arm64, Docker דרך colima) בלי מפתח ענן, כיוונתי את נקודת הקצה /v1/scrape לכמה אתרי דמו ידידותיים לסקרייפינג, ובדקתי מה חזר. בשורה התחתונה: ההבטחה המרכזית באמת עבדה — דף נכנס, ו-Markdown נקי שמוכן ל-LLM יצא — אבל זו הייתה ההתקנה הכי כבדה מכל הכלים שעברו דרך מסד המחקר הזה. זו בדיקה ראשונית, לא דירוג סופי, ואני אהיה חד לגבי מה כן בדקתי ומה לא.
Firecrawl הוא שירות, לא ספרייה
זו התמונה המנטלית הראשונה שכדאי לתקן. רוב כלי הסקרייפינג שמפתחים ניגשים אליהם הם ספריות: מוסיפים תלות, קוראים לפונקציה, ומקבלים HTML או נתונים מנותחים חזרה בתוך התהליך שלכם. Firecrawl בהפעלה עצמאית הוא חיה אחרת. זו פלטפורמה שרצה עם API משלה, ואתם מדברים איתה דרך HTTP.
ההגדרה הרשמית היא "ה-API לחיפוש, סקרייפינג ואינטראקציה עם הרשת בהיקף גדול", וצורת המוצר באמת מתאימה לזה — דפים נכנסים, Markdown נקי או נתונים מובנים יוצאים. כשמריצים אותו מקומית, לא מחברים את Firecrawl לקוד שלכם. מרימים stack של docker compose ופונים לנקודת קצה, בדיוק כמו מול מיקרו-שירות פנימי.
ה-stack שהרצתי כלל שישה שירותים:
- api — שכבת ה-HTTP שאליה פונים בפועל
- playwright-service — דפדפן headless לרינדור JavaScript
- redis — תור ומשטח cache
- rabbitmq — מתווך הודעות
- nuq-postgres — גרסת Postgres למצב משימות
- foundationdb — אחסון key-value מבוזר
זו תשתית אמיתית, לא סקריפט עזר. Redis, RabbitMQ, Postgres ו-FoundationDB הם כולם תשתיות תעשייתיות של ממש. היתרון הוא ש-Firecrawl מטפל בחלקים המסובכים של סקרייפינג — תורים, רינדור, ניסיונות חוזרים — מאחורי קריאת API אחת. המחיר הוא שאתם מפעילים עכשיו את ששת הקונטיינרים האלה. חשוב לזכור את פשרת העלות-תועלת הזו; היא חוט השני של כל הסקירה.
לצורך ההשוואה, בדקתי מול ה-SDKs firecrawl-py 4.32.0 ו-firecrawl-js 4.30.0, כשהורדתי את תמונת ה-ghcr.io/firecrawl/firecrawl:latest הרשמית והמוכנה מראש ב-2026-07-09. באותו יום המאגר עמד בערך על 148 אלף כוכבים (ניקח את זה כמטא-דאטה, לא כציון איכות), תחת רישיון AGPL-3.0 — פרט שאחזור אליו, כי הוא משנה את השיקול לשימוש מסחרי.
הבדיקה המרכזית: דף הופך ל-Markdown נקי
כל הרעיון מאחורי Firecrawl הוא להפוך דף אינטרנט ל-Markdown ש-LLM באמת יכול לקרוא. אז זה היה הדבר הראשון שבדקתי.
הפניתי את /v1/scrape אל books.toscrape.com, קטלוג סטטי שנבנה במיוחד לתרגול סקרייפינג. התוצאה: 9,222 תווים של Markdown נקי, מוכן ל-LLM, כשהכותרת All products | Books to Scrape נותחה נכון. לא dump של HTML גולמי לתוך מחרוזת — אלא Markdown מסודר, עם כותרות, קישורים והפניות לתמונות שנשמרו. בדיוק סוג הפלט שאפשר לשלב ישירות ב-pipeline לאחזור מידע או להזין למודל בלי שכבת ניקוי נוספת.
זו נקודת החוזק המרכזית של Firecrawl, ובהפעלה עצמאית הוא עמד במשימה בלי דרמה. אם מה שאתם צריכים הוא "תנו לי את התוכן הקריא של הדף הזה כ-Markdown", דף סטטי חזר בדיוק כמו שהובטח. זה פרימיטיב שימושי מאוד, וזו הסיבה שהכלי מקבל את תשומת הלב שלו.
חשוב לדייק לגבי ההיקף: בדקתי רק את הנתיב /v1/scrape על דף בודד. לא בדקתי את /v1/crawl, הסורק הרב-דפי שסורק אתר שלם. זו יכולת נפרדת עם מצבי כשל משלה, ואני לא מתכוון לטעון שהיא עובדת אם לא הרצתי אותה.
דפי JavaScript: הדפדפן המובנה מצדיק את הקונטיינר שלו
דף סטטי הוא המקרה הקל. השאלה הקשה יותר בכל סקרייפר היא מה קורה כשהתוכן מופיע רק אחרי ש-JavaScript רץ — מה שבאינטרנט המודרני הוא בעצם ברירת המחדל.
כאן קונטיינר ה-playwright-service מפסיק להיות תקורה ומתחיל להיות העיקר. כיוונתי את הסקרייפר אל quotes.toscrape.com/js/, גרסת הדמו שמציגה את הציטוטים בצד הלקוח. אם Firecrawl היה שולף רק HTML גולמי, הציטוטים לא היו שם — הם לא קיימים עד שהדפדפן מריץ את הסקריפט של הדף.
ה-scrape חזר עם 1,574 תווים של Markdown, ובהם גם הציטוט של איינשטיין. הציטוט הזה הוא תוכן שאחרי JavaScript: עצם הנוכחות שלו מוכיחה ש-playwright-service באמת רינדר את הדף במנוע דפדפן אמיתי לפני חילוץ הטקסט, ולא רק תפס את שלד ה-HTML הריק שלפני הרינדור.
אז אחד מששת הקונטיינרים הוא דפדפן headless, והוא עושה בדיוק את העבודה שבשבילה מחזיקים אותו. זו ההצדקה המעשית לארכיטקטורה הכבדה יותר: אתם לא משלמים רק על קונטיינרים, אלא על היכולת לרנדר דפים עתירי JS בלי לבנות לבד אוטומציית דפדפן. עבור הרבה יעדים אמיתיים, זה ההבדל בין פלט שמיש לבין div-ים ריקים.
כשהיעד גרוע: שגיאות מובנות, בלי קריסה
סקרייפרים מבלים חלק מפתיע מהזמן שלהם מול דברים שלא עובדים — מארחים מתים, URL-ים עם שגיאות כתיב, שרתים שנתקעים. הדרך שבה כלי נכשלת מספרת עליו לא פחות מהדרך שבה הוא מצליח.
הזנתי ל-API בכוונה host לא תקין. הוא החזיר HTTP 500 מובנה והמשיך לעבוד — בלי stack trace שנשפך ללקוח, בלי קונטיינר שנפל, בלי תהליך שנתקע. השגיאה חזרה כתשובה נקייה שאפשר לתפוס ולהמשיך ממנה.
זו בדיוק ההתנהגות השקטה והנכונה שרוצים ממשהו שנכנס ל-pipeline. סקרייפר שנכנס לפאניקה על יעד בעייתי הוא סקרייפר שאי אפשר לעשות לו אוטומציה. כאן חזרה שגיאה שאפשר לתפוס ולהמשיך הלאה. בדקתי רק מקרה כשל אחד, אז צריך לקרוא את זה כ"טיפל נכון במקרה הכשל היחיד שזרקתי עליו", לא כבדיקת עמידות מלאה — אבל נקודת הנתון היחידה הייתה התוצאה הנכונה.
מציאות ההתקנה: ההרמה הכבדה ביותר במסד
ועכשיו לחלק שאף אחד לא מצלם לציוץ ההשקה. Firecrawl בהפעלה עצמאית היה, בלי להגזים, הסט-אפ הכי מורכב מכל כלי במסד המחקר הזה — ואני הרמתי לא מעט כאלה.
שישה קונטיינרים הם עלות הבסיס. אבל בדרך עלו לי גם שתי תקלות, וחשוב לי לדייק מי אשם בהן — מסתבר שלא Firecrawl.
תקלה ראשונה: build מתוך קוד המקור. בניית התמונות מה-source נכשלה בתוך ה-VM של colima שלי בגלל שגיאת snapshotter של containerd. זו אינטראקציה מוכרת כבעייתית בין תהליך הבנייה לשכבת האחסון של colima — תקלה תשתיתית בסביבה שלי, לא באג ב-Firecrawl. קובץ ה-compose מתעד חלופה: להשתמש בתמונות המוכנות מראש של ghcr.io/firecrawl/* במקום לבנות מקומית. עברתי אליהן, וכל ה-stack עלה בצורה נקייה. אם אתם על daemon סטנדרטי של Docker ולא על colima, ייתכן שלעולם לא תראו את זה; אני מציין זאת כהערת סביבה, ואימות ה-build של התורם על daemon נקי נמצא ברשימת החוסרים שלי.
תקלה שנייה: הגנת SSRF. הסקרייפים הראשונים נחסמו על ידי ההגנה של Firecrawl מפני כתובות IP פרטיות / SSRF. למה? הרשת של colima ממפה hostnames ציבוריים לכתובות 198.18.x.x, שנמצאות בטווח שמור ש-Firecrawl, ובצדק, מתייחס אליו כפרטי — ולכן שכבת האבטחה שלו עשתה את שלה וסירבה להביא יעד שנראה פנימי. כדי לעקוף זאת רק לבדיקה מקומית, הגדרתי ALLOW_LOCAL_WEBHOOKS=true.
אתם לא רוצים להעתיק את הדגל הזה ל-production. לכן חשוב לדייק מה הוא: הגנת SSRF היא תכונה, לא מכשול. היא מה שמונע משירות סקרייפינג להיטרף על ידי ניסיון לפגוע ברשת הפנימית שלכם. אני כיביתי אותה כי מוזרות DNS של colima גרמה ליעדים ציבוריים לגיטימיים שלי להיראות פרטיים בתוך ה-VM. אל תכבו הגנת SSRF בפריסה אמיתית. אם אתם לוקחים רק הערת תפעול אחת מהסקירה הזו, קחו את זו.
שתי התקלות, בפשטות, היו תוצר של הרצת Docker דרך colima על מחשב נייד — לא פגמים בתוכנה. מצד שני, משקל ההתקנה עצמו אמיתי, והוא של Firecrawl לפי התכנון. זה לא הכלי שתופסים כשצריך סקריפט מקומי מהיר; זה הכלי שמרימים כשצריך שירות סקרייפינג עם יכולת רינדור, ומוכנים להפעיל עבורו תשתית.
מה לא בדקתי, ומה הכלי לא נותן לכם
הנה מה שלא כיסיתי, ומה שהכלי לא מספק.
בהפעלה עצמאית אין Fire-engine. המוצר בענן של Firecrawl כולל את Fire-engine, שכבת האנטי-חסימה הקניינית שלו לעקיפת הגנות בוטים. לפי SELF_HOST.md של הפרויקט עצמו, מופעים עצמאיים לא מקבלים אותה. לכן אם דמיינתם ש-Firecrawl בהפעלה עצמאית פורץ אוטומטית מערכות אנטי-בוט אגרסיביות, צריך לעדכן את התמונה — היכולת הזו נמצאת בשכבת הענן, והיא לא הייתה חלק ממה שהרצתי.
API הענן לא נבדק כאן. לא היה לי מפתח ענן, ולכן כל מה שמופיע למעלה הוא ה-stack העצמאי בלבד. השירות המנוהל בענן — עם Fire-engine, סקיילינג מנוהל, ותכונות AI — הוא מוצר אחר, ואני לא מתכוון לאפיין את הביצועים שלו מהצד. קחו כל טענה על הענן ככזו שאינה כלולה בסקירה הזו.
תכונות AI דורשות מפתח. פורמט הפלט המובנה json ונקודת הקצה /extract נשענים על LLM, מה שאומר שצריך להביא מפתח OpenAI או לחבר את Ollama. לא הפעלתי את הנתיבים האלה, ולכן גם /extract וגם פלט json מובנה נמצאים בעמודת ה"לא נבדק".
פרוקסיז הם הערת שוליים, לא כותרת ראשית. Firecrawl תומך בהגדרת proxy, אבל אני מציין זאת כאן בכוונה כהערת צד — זו אפשרות שאפשר להדליק, לא סיבה לבחור בכלי, ובהפעלה עצמאית עדיין אין את שכבת האנטי-חסימה של הענן.
AGPL-3.0 היא החלטת תאימות אמיתית. זה ראוי למשקל משלו.
הרישיון: קראו את AGPL-3.0 לפני שאתם משיקים
Firecrawl מופץ תחת AGPL-3.0. זו לא שורה מקרית בתחתית ה-README — זה copyleft חזק עם סעיף שימוש ברשת, והוא יכול להשפיע ישירות על היכולת שלכם לבנות מוצר מסחרי מעל מופע בהפעלה עצמאית.
בקצרה: חובות GPL רגילות מופעלות בעת הפצה. AGPL הולך רחוק יותר — סעיף השימוש ברשת אומר שאם אתם מציעים את הפונקציונליות של התוכנה למשתמשים דרך רשת, זה עשוי להיחשב לסוג שימוש שמחייב זמינות קוד מקור. אם אתם מטמיעים Firecrawl בהפעלה עצמאית בתוך שירות שלקוחותיכם ניגשים אליו דרך האינטרנט, הסעיף הזה בהחלט רלוונטי, ו"אבל לא הפצנו בינארי" הוא לא חור היציאה שאנשים מניחים שהוא.
אני לא עורך הדין שלכם, ופרשנות הרישיון תלויה בדיוק באופן הפריסה. אבל עבור כל המלצה מסחרית, AGPL-3.0 הוא שיקול מרכזי, לא אותיות קטנות. דברו עם מי שאחראי על רישיונות בחברה שלכם לפני שאתם בונים עליו. ציון העובדה הזו אינו ביקורת על Firecrawl — יש הרבה כלים מצוינים ב-AGPL — זו פשוט עובדה שצריך לשים על השולחן מוקדם.
איפה נכנס ה-Developer Stack של Thunderbit
נסו את Thunderbit לחילוץ נתוני רשת
אם המטרה האמיתית שלכם היא "דף → Markdown מוכן ל-LLM" או "דף → נתונים מובנים", והמחיר של שישה קונטיינרים יחד עם שאלת ה-AGPL הוא לא משהו שאתם רוצים לסחוב, זה בדיוק הפער שה-Developer Stack של Thunderbit נבנה עבורו. אותו מנוע AI שמאחורי 100,000+ משתמשי התוסף שלנו, זמין בשלוש דרכים לעבודה טכנית — כשהתשתית נשארת בצד שלנו של הקו.
- Open API (REST). ה-
POST /distillממיר דף ל-Markdown נקי שמוכן ל-LLM; ה-POST /extractמחזיר נתונים מובנים לפי JSON Schema שאתם מגדירים. רינדור JS, טיפול באנטי-בוט ותוכן דינמי מטופלים בצד השרת — בלי קונטיינר דפדפן שאתם צריכים להפעיל. דגלrenderMode(none/basic/full) קובע עד כמה עמוק הרינדור, ונקודות קצה batch מטפלות בעד 100 כתובות URL עבור distill. - MCP server. שרת רשמי של Model Context Protocol, כך שסוכן AI בתוך Claude או Cursor יכול לבצע סקרייפינג באמצע משימה:
thunderbit_suggest_fieldsלתכנון חילוץ (חינם),thunderbit_distillל-Markdown,thunderbit_extractלנתונים מובנים. הסוכן מחליט מתי למשוך נתונים בלי לצאת מהסביבה שלו. - CLI. ה-
npx -y @thunderbit/thunderbit-cliמריץ סקרייפים מהטרמינל, מסקריפטים, מ-CI או מ-cron — בלי דפדפן, בלי stack לטפל בו. אפשר לשרשר אותו ישר לכלים אחרים:thunderbit distill "$URL" -f markdown | claude -p "summarise".
הניגוד מול Firecrawl בהפעלה עצמאית ברור. Firecrawl בהפעלה עצמאית נותן לכם שליטה מלאה ואחריות תפעולית מלאה: שישה קונטיינרים, משקל הקמה, תנאי AGPL, וללא Fire-engine נגד חסימות. ה-API/MCP/CLI של Thunderbit מחליפים את השליטה הזו במנוע מתארח שמחזיר JSON מובנה התואם לסכמה — לא רק Markdown גולמי — בלי הקונטיינרים, בלי שכבת האנטי-בוט, ובלי חובת copyleft על הקוד שלכם. כלים שונים לתיאבון שונה לתשתיות.
כך נראית הפשרה בתמונה אחת:
| שיקול | Firecrawl בהפעלה עצמאית | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| צורת פריסה | שירות שאתם מפעילים (6 קונטיינרים) | API מתארח שאתם פונים אליו |
| כדי להתחיל | docker compose מרים stack של 6 שירותים | מפתח API ואז שליחה |
| רינדור JS | playwright-service מובנה (אתם מפעילים אותו) | בצד השרת, עם דגל renderMode |
| פלט מובנה | דורש מפתח LLM (/extract, json) | POST /extract עם JSON Schema |
| שכבת אנטי-בוט | אין בהפעלה עצמאית (Fire-engine הוא רק בענן) | מטופל בצד השרת |
| רישיון | AGPL-3.0 (copyleft לשימוש ברשת) | API מסחרי, בלי copyleft על הקוד שלכם |
| מתאים במיוחד כש... | אתם רוצים שליטה מלאה ומוכנים להפעיל תשתית | אתם רוצים Markdown/נתונים מובנים בלי תפעול |
אף אחד מהם לא "טוב יותר" באופן מוחלט. אם הפעלת הפלטפורמה היא המטרה מבחינתכם — שליטה מלאה בנתונים, בלי תלות חיצונית, ו-AGPL מתאים למקרה שלכם — Firecrawl בהפעלה עצמאית הוא בחירה חזקה ומתוחזקת באופן פעיל. אם אתם מעדיפים פשוט לקרוא ל-API ולהימנע מחיים של שישה קונטיינרים, זו בדיוק ההבטחה של ה-stack של Thunderbit.
מי באמת צריך להפעיל את Firecrawl בעצמו
אם מורידים את ההייפ, התמונה ברורה מספיק כדי למיין לפי צורך.
כדאי להפעיל את Firecrawl בעצמכם אם אתם רוצים שליטה מלאה על תשתית הסקרייפינג שלכם, נוח לכם להפעיל ב-production את Redis / RabbitMQ / Postgres / FoundationDB, צורכי הרינדור שלכם מצדיקים את קונטיינר ה-playwright-service, ו-AGPL-3.0 מתאים לאופן הפריסה שלכם. היכולת הבסיסית אמיתית: קיבלתי Markdown נקי, מובנה ומוכן ל-LLM גם מדף סטטי וגם מדף שרונדר ב-JavaScript, וכל ה-stack רץ על תמונות מוכנות מראש.
כדאי לחפש חלופה אם אתם רוצים סקריפט מקומי מהיר (זה הסטאפ הכי כבד במסד, חד משמעית), אתם צריכים אנטי-חסימה ברמת ענן בלי להפעיל אותה בעצמכם (בהפעלה עצמאית אין Fire-engine), או שסעיף השימוש ברשת של AGPL מתנגש עם התוכניות המסחריות שלכם. במקרה של "אני רק צריך Markdown או נתונים מובנים מ-URL, בלי התפעול", API מתארח כמו Thunderbit עם /distill ו-/extract מכסה את אותו אזור בלי הקונטיינרים.
הרושם הראשוני שלי: ליבה חזקה, מחויבות תפעולית כבדה, ורישיון שחייבים לאשר לפני בנייה מסחרית. הוא בהחלט מתאים לצוותים שרוצים להחזיק את כל הצינור — אבל הוא גם דורש לא מעט מכל השאר. אחזור לזה אחרי שאפעיל את /v1/crawl, אבדוק את /extract עם מפתח LLM, ואאמת את ה-build מה-source על daemon שאינו colima; אלה שאלות פתוחות בין הנקודה הזו לבין פסק דין סופי.
נסו את Thunderbit לחילוץ נתוני רשת Get Started Free
שאלות נפוצות
האם Firecrawl בהפעלה עצמאית זהה לגרסת הענן?
לא. בהפעלה עצמאית מקבלים את מנוע הסקרייפ-ל-Markdown הבסיסי ואת רינדור ה-JavaScript דרך playwright-service המובנה, אבל לא מקבלים את Fire-engine, שכבת האנטי-חסימה הקניינית של מוצר הענן. תכונות AI כמו נקודת הקצה /extract ופלט json דורשות גם מפתח LLM משלכם (OpenAI או Ollama). בסקירה הזו בדקתי רק את ה-stack העצמאי; API הענן היה מחוץ להיקף.
כמה קונטיינרים Firecrawl בהפעלה עצמאית באמת צריך?
שישה: api, playwright-service, redis, rabbitmq, nuq-postgres ו-foundationdb. זהו stack שירות מלא, לא בינארי יחיד — ולכן זו הייתה ההתקנה הכבדה ביותר מכל כלי במסד המחקר הזה. צריך להיערך ל-overhead התפעולי של הפעלת תשתית message-broker, cache ו-database, לא רק של סקריפט.
האם Firecrawl יודע להתמודד עם דפים כבדי JavaScript בהפעלה עצמאית?
כן, בבדיקות שלי. ה-playwright-service המובנה מרנדר דפים במנוע דפדפן אמיתי לפני החילוץ. אימתתי זאת על quotes.toscrape.com/js/, שם הציטוט של איינשטיין — תוכן שקיים רק אחרי ריצת JavaScript — הופיע ב-Markdown שהוחזר. יכולת הרינדור הזו היא בדיוק הסיבה לכך שאחד מששת הקונטיינרים הוא דפדפן headless.
האם רישיון AGPL-3.0 משפיע על שימוש מסחרי?
הוא יכול להשפיע, וכדאי להתייחס אליו כשאלה ראשונה במעלה. AGPL-3.0 הוא copyleft חזק עם סעיף שימוש ברשת, כלומר מתן הפונקציונליות של התוכנה למשתמשים דרך רשת יכול לבוא עם חובת זמינות קוד מקור — גם אם לעולם לא תפיצו בינארי. אם אתם מתכננים לבנות מוצר מסחרי על מופע בהפעלה עצמאית, דברו עם מי שמטפל ברישיונות בחברה שלכם לפני שאתם מתחייבים. הסקירה הזו מצביעה על הרישיון; היא לא ייעוץ משפטי.
מה ההבדל בין Firecrawl לבין כלי הפיתוח של Thunderbit?
Firecrawl בהפעלה עצמאית הוא שירות שאתם מפעילים — שישה קונטיינרים שאתם מריצים בעצמכם, עם תנאי AGPL-3.0 וללא שכבת אנטי-חסימה מובנית. ה-Developer Stack של Thunderbit (Open API, שרת MCP, CLI) הוא מנוע מתארח שאליו פונים: POST /distill ל-Markdown, POST /extract לנתונים מובנים לפי JSON Schema, עם רינדור JS וטיפול באנטי-בוט בצד השרת וללא חובת copyleft על הקוד שלכם. Firecrawl מתאים לצוותים שרוצים שליטה מלאה על התשתית; Thunderbit מתאים למי שרוצה את הפלט בלי הנטל התפעולי.
