كثيرون يضعون Firecrawl في نفس خانة أدوات الاستخراج البرمجي — فئة "ثبّت الحزمة بـ pip، اكتب سكربتًا، وانتهى الأمر". لكن هذا التصور غير دقيق، والفرق هنا مهم قبل أن تكتب أول أمر. Firecrawl المستضاف ذاتيًا ليس مكتبة تستوردها داخل مشروعك؛ إنه خدمة تديرها بنفسك، وتشغيله يعني تشغيل ست حاويات Docker تتواصل فيما بينها.
اختبرت الحزمة المستضافة ذاتيًا على جهاز Mac بمعمارية arm64 باستخدام Docker عبر colima، من دون مفتاح سحابي، ووجّهت نقطة النهاية /v1/scrape إلى عدد من المواقع التجريبية المناسبة للاستخراج، ثم راقبت ما الذي سيعود. الخلاصة السريعة: الوعد الأساسي صمد — صفحة دخلت، وخرجت منها Markdown نظيفة جاهزة لنماذج اللغة الكبيرة — لكن الإعداد كان الأثقل بين كل الأدوات التي مرّت على هذه القاعدة البحثية. هذه نظرة أولية لا حكم نهائي، وسأكون واضحًا بشأن ما اختبرته وما لم أختبره.
Firecrawl خدمة، وليس مكتبة
هذه هي الصورة الذهنية الأولى التي تحتاج إلى تصحيح. معظم أدوات الاستخراج التي يلجأ إليها المطورون تكون مكتبات: تضيف اعتمادًا برمجيًا، تستدعي دالة، وتحصل على HTML أو بيانات محللة داخل العملية نفسها. أما Firecrawl المستضاف ذاتيًا فهو شيء مختلف. إنه منصة تعمل كخدمة لها API خاص بها، وتتواصل معها عبر HTTP.
الطرح الرسمي له هو أنه "API للبحث والاستخراج والتفاعل مع الويب على نطاق واسع"، وشكل المنتج يطابق ذلك تمامًا — صفحات تدخل، وMarkdown نظيفة أو بيانات منظمة تخرج. عند الاستضافة الذاتية، أنت لا تربط Firecrawl داخل تطبيقك. بل تشغّل حزمة docker compose وتستدعي نقطة نهاية، تمامًا كما تفعل مع أي خدمة داخلية صغيرة.
الحزمة التي شغلتها تضمنت ست خدمات:
- api — الواجهة HTTP التي تستدعيها فعليًا
- playwright-service — متصفح بلا واجهة لتصيير JavaScript
- redis — للطابور والتخزين المؤقت
- rabbitmq — وسيط رسائل
- nuq-postgres — نسخة Postgres لحالة المهام
- foundationdb — تخزين موزع من نوع key-value
هذه بنية خلفية حقيقية، وليست مجرد سكربت مساعد. Redis وRabbitMQ وPostgres وFoundationDB كلها بنى تحتية احترافية بحد ذاتها. مقابل ذلك تحصل Firecrawl على معالجة الأجزاء المزعجة في الاستخراج — إدارة الطوابير، التصيير، وإعادة المحاولة — عبر استدعاء API واحد. لكن الثمن هو أنك ستدير الآن تلك الحاويات الست. احتفظ بهذه المقايضة في ذهنك؛ فهي الخيط الذي يربط هذه المراجعة كلها.
وللإشارة، اختبرت الحزمة باستخدام 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 يمكن لنموذج اللغة الكبير قراءتها فعلًا. لذلك كان هذا أول ما تحققت منه.
وجّهت /v1/scrape إلى books.toscrape.com، وهو موقع ثابت صُمم أصلًا للتدريب على الاستخراج. النتيجة: 9,222 حرفًا من Markdown نظيفة وجاهزة لنماذج اللغة الكبيرة، مع تحليل صحيح لعنوان الصفحة All products | Books to Scrape. لم يكن مجرد HTML خام داخل نص، بل Markdown منظمة مع العناوين والروابط ومراجع الصور كما ينبغي. هذا نوع من المخرجات يمكنك وضعه مباشرة في خط أنابيب استرجاع أو تمريره إلى نموذج دون تنظيف إضافي.
هذه هي قوة Firecrawl الأساسية، والاستضافة الذاتية قدّمتها بلا مشاكل. إذا كانت مهمتك هي "أعطني المحتوى المقروء لهذه الصفحة بصيغة Markdown"، فقد عاد موقع ثابت بالضبط كما وُعد. وهذه قدرة مفيدة جدًا بالفعل، وهي سبب انتشار الأداة.
ومن المهم أن نكون دقيقين في النطاق: جرّبت مسار الصفحة الواحدة /v1/scrape. لم أختبر /v1/crawl، أي الزاحف متعدد الصفحات الذي يتجول في موقع كامل. هذه قدرة منفصلة لها نقاط فشلها الخاصة، ولن أدّعي أنها تعمل إذا لم أشغّلها فعلًا.
صفحات JavaScript: المتصفح المدمج يثبت قيمته
الصفحات الثابتة هي الحالة الأسهل. السؤال الأصعب في أي أداة استخراج هو: ماذا يحدث عندما لا يظهر المحتوى إلا بعد تشغيل JavaScript — وهو الوضع الغالب في الويب الحديث؟
وهنا تتحول حاوية playwright-service من عبء إضافي إلى لبّ الفكرة. وجّهت الأداة إلى quotes.toscrape.com/js/، وهي نسخة من الموقع التجريبي تعرض الاقتباسات من جهة العميل. لو كان Firecrawl يجلب HTML الخام فقط، لما ظهرت الاقتباسات — فهي لا توجد قبل أن ينفذ المتصفح سكربت الصفحة.
عادت عملية الاستخراج بـ 1,574 حرفًا من Markdown، وكانت فيها اقتباسة أينشتاين. هذه الاقتباسة محتوى لا يظهر إلا بعد JavaScript؛ ووجودها دليل على أن playwright-service فعّل الصفحة داخل محرك متصفح حقيقي قبل استخراج النص، بدلًا من التقاط الغلاف الفارغ قبل التصيير.
إذًا إحدى الحاويات الست هي متصفح بلا واجهة، وهي تؤدي المهمة التي استُدعيت من أجلها. وهذا يبرر البنية الأثقل بشكل عملي: أنت لا تدفع ثمن الحاويات فقط، بل تدفع ثمن القدرة على تصيير الصفحات الثقيلة بـ JS من دون إعداد أتمتة متصفح بنفسك. وفي كثير من الحالات الواقعية، هذا هو الفارق بين مخرجات مفيدة وdivs فارغة.
عندما تكون الوجهة سيئة: أخطاء منظمة بلا انهيار
قضت أدوات الاستخراج وقتًا كبيرًا وهي تشير إلى أشياء لا تعمل: مضيف ميت، رابط خاطئ، أو خادم يتوقف عن الاستجابة. وطريقة الفشل لا تقل دلالة عن طريقة النجاح.
أرسلت إلى الـ API مضيفًا غير صالح عمدًا. فعاد HTTP 500 بشكل منظم وبقيت الخدمة تعمل — لا stack trace انفجر على العميل، ولا حاوية انهارت، ولا عملية علقت. عاد الخطأ كاستجابة نظيفة يمكن للمتصل أن يتفرع بناءً عليها.
هذه هي السلوكيات المملة والصحيحة التي تريدها في شيء سيعمل داخل خط أنابيب. أداة استخراج تنهار بسبب هدف سيئ هي أداة لا يمكنك أتمتتها بثقة. هذه الأداة أعادت خطأ يمكن التقاطه ثم المتابعة. اختبرت حالة خطأ واحدة فقط، لذا اقرأ هذا على أنه "تعاملت مع الفشل الوحيد الذي جرّبته بشكل صحيح" لا على أنه تدقيق شامل في المتانة — لكن النقطة الوحيدة التي حصلت عليها كانت النتيجة الصحيحة.
واقع الإعداد: أثقل خطوة في القاعدة
وهنا الجزء الذي لا يلتقطه أحد في صور الإطلاق. Firecrawl المستضاف ذاتيًا كان، من دون مبالغة، أكثر إعداد تعقيدًا بين كل الأدوات في هذه القاعدة البحثية — وقد شغّلت الكثير منها.
ست حاويات هو الحد الأدنى. لكنني واجهت أيضًا تعثّرين أثناء الإعداد، وأريد أن أكون دقيقًا في نسبة السبب، لأنها في النهاية لم تكن Firecrawl نفسها.
التعثّر الأول: البناء من المصدر. فشل بناء الصور من المصدر داخل VM الخاصة بـ colima بسبب خطأ في snapshotter الخاص بـ containerd. هذه مشكلة تفاعل معروفة وغير مستقرة أحيانًا بين عملية البناء وطبقة التخزين في colima — عثرة بنية تحتية في بيئتي، وليست خللًا في Firecrawl. ملف compose يذكر بديلًا: استخدام الصور الرسمية الجاهزة ghcr.io/firecrawl/* بدل البناء المحلي. انتقلت إلى تلك الصور، واشتغلت الحزمة كلها بسلاسة. إذا كنت تستخدم Docker daemon عاديًا بدل colima، فقد لا ترى هذا أصلًا؛ أذكره كتقييد بيئي، والتحقق من بناء المساهمين على daemon نظيف ما يزال ضمن قائمة النواقص لدي.
التعثّر الثاني: حارس SSRF. أولى عمليات الاستخراج تم حظرها بواسطة حماية Firecrawl من العناوين الخاصة وSSRF. لماذا؟ لأن شبكة colima تعيّن للمضيفات العامة عناوين 198.18.x.x، وهي ضمن نطاق محجوز يتعامل معه Firecrawl بشكل صحيح على أنه خاص — لذلك قام طبقة الأمان بدورها ورفضت جلب ما بدا وكأنه هدف داخلي. وللتجاوز للاختبار المحلي فقط، ضبطت ALLOW_LOCAL_WEBHOOKS=true.
هذه الراية إذا نُسخت إلى الإنتاج قد تسبب حوادث فعلية، لذا كن دقيقًا بشأن معناها: حارس SSRF ميزة وليس عائقًا. هو ما يمنع خدمة استخراج من أن تُخدع فتضرب شبكتك الداخلية. أنا عطّلته فقط لأن غرابة DNS في colima جعلت أهدافي العامة الشرعية تبدو خاصة داخل الـ VM. لا تُوقف حماية SSRF في أي نشر حقيقي. إذا أخذت ملاحظة تشغيلية واحدة من هذه المراجعة، فلتكن هذه.
وبصراحة، كان التعثران نتيجة تشغيل Docker عبر colima على لابتوب — لا عيوبًا في البرنامج. ومن ناحية أخرى، ثقل الإعداد نفسه حقيقي وهو قرار تصميمي في Firecrawl. هذه ليست الأداة التي تختارها عندما تريد سكربتًا محليًا سريعًا؛ إنها الأداة التي تنشرها عندما تريد خدمة استخراج قادرة على التصيير ومستعدًا لتشغيل البنية التحتية التي تتطلبها.
ما الذي لم أختبره، وما الذي لا يقدمه
إليك ما لم أغطّه، وما الذي لا تمنحه الأداة.
الاستضافة الذاتية لا تتضمن Fire-engine. المنتج السحابي من Firecrawl يتضمن Fire-engine، وهي طبقة مملوكة لتجاوز الحظر وآليات الحماية من الروبوتات. ووفقًا لملف المشروع SELF_HOST.md، فإن النسخ المستضافة ذاتيًا لا تحصل عليها. لذلك إذا كنت تتخيل Firecrawl المستضاف ذاتيًا وهو يخترق أنظمة الحماية العدوانية ضد الروبوتات افتراضيًا، فصحح هذه الصورة — هذه القدرة موجودة في الطبقة السحابية، ولم تكن ضمن ما شغلته.
واجهة الـ API السحابية لم تُختبر هنا. لم يكن لدي مفتاح سحابي، لذا كل ما سبق يخص الحزمة المستضافة ذاتيًا فقط. الخدمة السحابية المُدارة — مع Fire-engine والتوسّع المستضاف والميزات المعتمدة على الذكاء الاصطناعي — منتج مختلف، ولن أصف أداءه من الخارج. اعتبر أي ادعاء يتعلق بالسحابة خارج نطاق هذه المراجعة.
ميزات الذكاء الاصطناعي تحتاج مفتاحًا. صيغة المخرجات المنظمة json ونقطة النهاية /extract تعتمدان على LLM، ما يعني أنك ستحتاج إما إلى مفتاح OpenAI أو ربط Ollama. لم أختبر هذه المسارات، لذا تبقى /extract ومخرجات json المنظمة ضمن العمود غير المختبر أيضًا.
البروكسيات ملاحظة جانبية لا عنوان رئيسي. يدعم Firecrawl إعدادات البروكسي، لكنني أذكرها هنا كحاشية عمدًا — فهي خيار يمكنك ضبطه، لكنها ليست سبب اختيار الأداة، كما أن الاستضافة الذاتية ما تزال تفتقر إلى طبقة الحماية من الحظر الموجودة في السحابة.
AGPL-3.0 قرار امتثال حقيقي. وهذه تستحق وقفة خاصة بها.
الترخيص: اقرأ AGPL-3.0 قبل أن تطلق المنتج
Firecrawl مرخّص تحت AGPL-3.0. هذه ليست عبارة تُرمى في أسفل ملف README — بل هو ترخيص copyleft قوي مع بند لاستخدام الشبكة، ويمكن أن يؤثر مباشرة في قدرتك على بناء منتج تجاري فوق نسخة مستضافة ذاتيًا.
باختصار: التزامات GPL التقليدية تبدأ عند التوزيع. أما AGPL فيتجاوز ذلك — فبند استخدام الشبكة يعني أن إتاحة وظائف البرنامج للمستخدمين عبر الشبكة قد تُعد نوعًا من الاستخدام الذي يفرض التزامات بإتاحة المصدر. إذا كنت تدمج Firecrawl المستضاف ذاتيًا داخل خدمة يصل إليها عملاؤك عبر الإنترنت، فهذا البند يقع في قلب المشهد، وعبارة "لم نوزّع binary أبدًا" ليست مخرجًا كما يظن البعض.
لستُ محاميًا، وتفسير الترخيص يعتمد على طريقة النشر بالتحديد. لكن بالنسبة لأي توصية تجارية، فإن AGPL-3.0 اعتبار من الدرجة الأولى، لا سطرًا صغيرًا في الهامش. راجع الجهة المسؤولة عن الترخيص في شركتك قبل أن تبني عليه. وذكر هذا ليس انتقاصًا من Firecrawl — فالكثير من الأدوات الممتازة مرخّصة بـ AGPL — لكنه مجرد واقع يجب أن يكون على الطاولة مبكرًا.
أين يناسب ذلك ضمن حزمة Thunderbit للمطورين
جرّب Thunderbit لاستخراج بيانات الويب
إذا كان هدفك الفعلي هو "صفحة → Markdown جاهزة لنماذج اللغة الكبيرة" أو "صفحة → بيانات منظمة"، ولم تكن كلفة التشغيل المكوّنة من ست حاويات وسؤال AGPL شيئًا تريد تحمّله، فهذه بالضبط الفجوة التي صُممت لها حزمة المطورين في Thunderbit. نفس محرك الذكاء الاصطناعي الذي يقف خلف أكثر من 100,000 مستخدم للإضافة، لكنه متاح بثلاث طرق للاستخدام التقني — مع بقاء البنية التحتية على جانبنا.
- API مفتوح (REST).
POST /distillيحوّل الصفحة إلى Markdown نظيفة جاهزة لنماذج اللغة الكبيرة؛ وPOST /extractيعيد بيانات منظمة وفق JSON Schema التي تحددها. يتم التعامل مع تصيير JavaScript، ومكافحة الحظر، والمحتوى الديناميكي من جهة الخادم — من دون متصفح أو حاوية عليك تشغيلها. وتتحكم رايةrenderMode(none/basic/full) في عمق التصيير، كما تدعم نقاط الدفعات حتى 100 رابط في عملية distill. - خادم MCP. خادم رسمي لـ Model Context Protocol، بحيث يمكن لوكيل ذكاء اصطناعي داخل Claude أو Cursor أن يجري الاستخراج أثناء المهمة نفسها:
thunderbit_suggest_fieldsلتخطيط الاستخراج (مجانًا)، وthunderbit_distillلـ Markdown، وthunderbit_extractللبيانات المنظمة. الوكيل يقرر متى يجلب البيانات من دون مغادرة بيئته. - CLI.
npx -y @thunderbit/thunderbit-cliيشغّل عمليات الاستخراج من الطرفية أو السكربتات أو CI أو cron — من دون متصفح ومن دون بنية تحتاج إلى رعاية. ويمكنك تمريره مباشرة إلى أدوات أخرى:thunderbit distill "$URL" -f markdown | claude -p "summarise".
المقارنة مع Firecrawl المستضاف ذاتيًا واضحة: Firecrawl يمنحك تحكمًا كاملًا ومسؤولية تشغيل كاملة: ست حاويات، وثقل الإعداد، وشروط AGPL، ومن دون Fire-engine للحظر. أما API/MCP/CLI في Thunderbit فيستبدل هذا التحكم بمحرك مستضاف يعيد JSON منظمًا مطابقًا للمخطط — وليس مجرد Markdown خام — مع إعفائك من الحاويات وطبقة مكافحة الحظر والتزامات copyleft. أدوات مختلفة لأذواق مختلفة في تحمّل البنية التحتية.
وهذا هو الفرق في صورة واحدة:
| الاعتبار | Firecrawl المستضاف ذاتيًا | حزمة Thunderbit للمطورين (API · MCP · CLI) |
|---|---|---|
| شكل النشر | خدمة تديرها بنفسك (6 حاويات) | API مستضاف تستدعيه |
| بدء التشغيل | تشغيل حزمة من 6 خدمات عبر docker compose | مفتاح API ثم طلب |
| تصيير JavaScript | playwright-service مدمج (تشغّله أنت) | من جهة الخادم، عبر راية renderMode |
| المخرجات المنظمة | تحتاج مفتاح LLM (/extract، json) | POST /extract مع JSON Schema |
| طبقة مكافحة الحظر | غير موجودة في الاستضافة الذاتية (Fire-engine سحابي فقط) | تُدار من جهة الخادم |
| الترخيص | AGPL-3.0 (copyleft لاستخدام الشبكة) | API تجاري، بلا copyleft على شيفرتك |
| الأنسب عندما | تريد تحكمًا كاملًا ومستعدًا لتشغيل البنية | تريد Markdown/بيانات منظمة من دون تشغيل البنية |
لا أحد منهما "أفضل" على الإطلاق. إذا كان تشغيل المنصة بحد ذاته هو الهدف — تحكم كامل بالبيانات، من دون تبعية خارجية، وAGPL مناسب لحالتك — فإن Firecrawl المستضاف ذاتيًا خيار قوي ومُدار بنشاط. أما إذا كنت تفضّل مجرد استدعاء API وتجاوز حياة الحاويات الست، فهذه هي رسالة Thunderbit.
من يجب أن يستضيف Firecrawl ذاتيًا فعليًا؟
إذا أزلنا الضجيج، تصبح الصورة واضحة بما يكفي للتفريق حسب الحاجة.
استضف Firecrawl ذاتيًا إذا كنت تريد تحكمًا كاملًا في بنية الاستخراج، وتشعر بالارتياح لتشغيل Redis وRabbitMQ وPostgres وFoundationDB في الإنتاج، وتحتاج فعلًا إلى قدرات التصيير التي تبرر حاوية playwright-service، وAGPL-3.0 يتوافق مع طريقة نشرّك. القدرة الأساسية حقيقية: حصلت على Markdown نظيفة ومنظمة وجاهزة لنماذج اللغة الكبيرة من صفحة ثابتة وأخرى تُصيَّر بـ JS، وكانت الحزمة كلها تعمل عبر صور جاهزة.
ابحث عن بديل إذا كنت تريد سكربتًا محليًا سريعًا (فهذه أثقل عملية إعداد في هذه القاعدة، بلا جدال)، أو تحتاج إلى مكافحة حظر بمستوى سحابي من دون تشغيلها بنفسك (الاستضافة الذاتية لا تتضمن Fire-engine)، أو كان بند استخدام الشبكة في AGPL يتعارض مع خططك التجارية. ولحالة "أريد فقط Markdown أو بيانات منظمة من رابط، من دون البنية التشغيلية"، فإن API مستضافًا مثل /distill و/extract في Thunderbit يغطي نفس الغرض من دون الحاويات.
قراءتي الأولية: نواة قوية، التزام تشغيلي ثقيل، وترخيص يجب أن تحسمه قبل أي بناء تجاري. إنه يستحق مكانه لدى الفرق التي تريد امتلاك خط الأنابيب كاملًا — لكنه يطلب الكثير من بقية المستخدمين. سأعود إليه بعد أن أشغّل /v1/crawl، وأجرّب /extract بمفتاح LLM، وأتحقق من البناء من المصدر على daemon غير colima؛ فهذه هي الأسئلة المفتوحة بين هذه المراجعة والحكم النهائي.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
هل Firecrawl المستضاف ذاتيًا هو نفسه النسخة السحابية؟
لا. الاستضافة الذاتية تمنحك نواة الاستخراج إلى Markdown مع تصيير JavaScript عبر playwright-service المدمج، لكنها لا تتضمن Fire-engine، أي طبقة الحظر المملوكة في المنتج السحابي. كما أن ميزات الذكاء الاصطناعي مثل نقطة النهاية /extract ومخرجات json تحتاج إلى مفتاح LLM خاص بك (OpenAI أو Ollama). في هذه المراجعة اختبرت الحزمة المستضافة ذاتيًا فقط؛ أما الـ API السحابي فكان خارج النطاق.
كم حاوية يحتاج Firecrawl المستضاف ذاتيًا فعلًا؟ ست: api وplaywright-service وredis وrabbitmq وnuq-postgres وfoundationdb. إنها حزمة خدمة كاملة، وليست ملفًا تنفيذيًا واحدًا — ولهذا كانت أثقل إعداد بين كل الأدوات في هذه القاعدة البحثية. خطّط لعبء تشغيل البنية الخاصة بوسيط الرسائل والتخزين المؤقت وقواعد البيانات، لا مجرد سكربت.
هل يستطيع Firecrawl التعامل مع صفحات كثيفة JavaScript عند الاستضافة الذاتية؟
نعم، بحسب اختباري. حاوية playwright-service المدمجة تصيّر الصفحات داخل محرك متصفح حقيقي قبل الاستخراج. تأكدت من ذلك على quotes.toscrape.com/js/، حيث ظهرت اقتباسة أينشتاين — وهي محتوى لا يوجد إلا بعد تشغيل JavaScript — داخل Markdown الناتجة. وهذه القدرة التصييرية هي بالضبط سبب وجود متصفح بلا واجهة ضمن الحاويات الست.
هل يؤثر ترخيص AGPL-3.0 في الاستخدام التجاري؟ نعم، وقد ينبغي أن تتعامل معه كسؤال أساسي. AGPL-3.0 هو copyleft قوي مع بند لاستخدام الشبكة، ما يعني أن إتاحة وظائف البرنامج للمستخدمين عبر الشبكة قد تفرض التزامات بإتاحة المصدر — حتى لو لم توزّع ملفًا تنفيذيًا أبدًا. إذا كنت تنوي بناء منتج تجاري على نسخة مستضافة ذاتيًا، تحدث مع الجهة المسؤولة عن الترخيص في شركتك قبل الالتزام. هذه المراجعة تشير إلى الترخيص؛ وليست نصيحة قانونية.
ما الفرق بين Firecrawl وأدوات Thunderbit للمطورين؟
Firecrawl المستضاف ذاتيًا هو خدمة تديرها بنفسك — ست حاويات تشغّلها أنت، مع شروط AGPL-3.0 ومن دون طبقة مدمجة لمكافحة الحظر. أما حزمة Thunderbit للمطورين (Open API وMCP server وCLI) فهي محرك مستضاف تستدعيه: POST /distill للـ Markdown، وPOST /extract للبيانات المنظمة وفق JSON Schema، مع تصيير JavaScript ومعالجة مكافحة الحظر من جهة الخادم ومن دون التزام copyleft على شيفرتك. Firecrawl يناسب الفرق التي تريد تحكمًا كاملًا بالبنية؛ بينما يناسب Thunderbit من يريد المخرجات من دون عبء التشغيل.
