Большинство людей ставят Firecrawl в один ряд с библиотеками для скрейпинга — из серии «pip install, написать скрипт и готово». Но это неверная рамка, и разница здесь важна ещё до того, как вы введёте первую команду. Firecrawl в self-hosted — это не библиотека, которую вы подключаете, а сервис, которым вы управляете. А значит, чтобы поднять его, нужно запустить шесть Docker-контейнеров, которые общаются друг с другом.
Я запускал self-hosted-стек на Mac (arm64, Docker через colima) без облачного ключа, отправлял запросы к /v1/scrape на пару демо-сайтов, удобных для скрейпинга, и смотрел, что возвращается. Коротко: базовое обещание подтвердилось — страница заходила, на выходе получался чистый Markdown, готовый для LLM, — но по сложности это был самый тяжёлый инструмент из всех, что я тестировал в рамках этого исследования. Это предварительный взгляд, а не финальная оценка, и я честно разделю, что именно я проверил, а что — нет.
Firecrawl — это сервис, а не библиотека
Сначала нужно правильно выстроить картину в голове. Большинство инструментов для скрейпинга, к которым тянутся разработчики, — это библиотеки: вы добавляете зависимость, вызываете функцию и получаете HTML или уже разобранные данные прямо в своём процессе. Firecrawl self-hosted устроен иначе. Это работающая платформа со своим API, с которой вы общаетесь по HTTP.
Официальная формулировка — «API для поиска, скрейпинга и взаимодействия с вебом в масштабе», и продукт действительно именно такой: на входе страницы, на выходе чистый Markdown или структурированные данные. Когда вы разворачиваете self-hosted-версию, вы не подключаете Firecrawl как библиотеку. Вы поднимаете стек через docker compose и обращаетесь к endpoint, как к любому внутреннему микросервису.
В моём тесте использовались шесть сервисов:
- api — HTTP-слой, к которому вы обращаетесь
- playwright-service — headless-браузер для рендеринга JavaScript
- redis — очередь и кэш
- rabbitmq — брокер сообщений
- nuq-postgres — вариант Postgres для состояния задач
- foundationdb — распределённое key-value-хранилище
Это уже полноценный backend, а не вспомогательный скрипт. Redis, RabbitMQ, Postgres и FoundationDB — это серьёзная инфраструктура сами по себе. Плюс в том, что Firecrawl берёт на себя грязную работу скрейпинга — очереди, рендеринг, повторные попытки — через один API-запрос. Минус в том, что теперь именно вы обслуживаете эти шесть контейнеров. Держите этот обмен в голове: он проходит красной нитью через весь обзор.
Для справки: я тестировал с firecrawl-py 4.32.0 и firecrawl-js 4.30.0 SDK, используя официальный предсобранный образ ghcr.io/firecrawl/firecrawl:latest, скачанный 2026-07-09. На тот момент у репозитория было примерно 148k звёзд (это скорее метаданные, чем показатель качества), а лицензия — AGPL-3.0. К этому моменту я ещё вернусь, потому что для коммерческого использования это меняет картину.
Главный тест: страница превращается в чистый Markdown
Вся идея Firecrawl в том, чтобы превращать веб-страницу в Markdown, который действительно сможет прочитать LLM. Поэтому именно это я проверил первым.
Я отправил /v1/scrape на books.toscrape.com — статический каталог, специально созданный для практики скрейпинга. Результат: 9,222 символа чистого Markdown, готового для LLM, а заголовок страницы All products | Books to Scrape был распознан корректно. Это был не просто слепок сырого HTML в строке, а структурированный Markdown с заголовками, ссылками и ссылками на изображения. Такой результат можно хоть сразу отправлять в retrieval pipeline, хоть подать модели без дополнительной очистки.
Это и есть главная сильная сторона Firecrawl, и self-hosted-версия отработала её без лишней драмы. Если ваша задача — «дай читаемую суть этой страницы в Markdown», статическая страница вернулась именно в том виде, в каком и обещано. Это действительно полезная базовая возможность, и именно поэтому у инструмента такая аудитория.
Важно точно обозначить границы: я проверял только путь /v1/scrape для одной страницы. Я не тестировал /v1/crawl — многстраничный краулер, который обходит целый сайт. Это отдельная функция со своими сценариями отказа, и я не буду утверждать, что она работает, если сам её не запускал.
JavaScript-страницы: встроенный браузер оправдывает свой контейнер
Статическая страница — это лёгкий случай. Для любого скрейпера более сложный вопрос: что происходит, когда контент появляется только после выполнения JavaScript? А в современном вебе так бывает чаще всего.
Именно здесь контейнер playwright-service перестаёт быть «лишним» и становится ключевой частью. Я направил скрейпер на quotes.toscrape.com/js/ — версию демо-сайта, где цитаты рендерятся на стороне клиента. Если бы Firecrawl просто забрал сырой HTML, цитат там не было бы: они не существуют, пока браузер не выполнит скрипт страницы.
В ответ я получил 1,574 символа Markdown, и там была цитата Эйнштейна. Это контент, который появляется только после выполнения JavaScript; его наличие доказывает, что playwright-service действительно отрисовал страницу в полноценном браузерном движке перед извлечением текста, а не просто забрал пустую оболочку до рендера.
То есть один из шести контейнеров — это headless-браузер, и он делает именно ту работу, ради которой его и берут. В этом и заключается практическое оправдание более тяжёлой архитектуры: вы платите не только за контейнеры, но и за возможность рендерить JavaScript-страницы без собственной браузерной автоматизации. Для многих реальных целей это разница между рабочим результатом и пустыми div.
Когда цель плохая: структурированная ошибка вместо падения
Скрейперы удивительно много времени тратят на плохие цели — мёртвые хосты, ошибочно введённые URL, серверы, которые просто зависают. То, как инструмент падает, не менее важно, чем то, как он работает.
Я намеренно передал API невалидный хост. В ответ получил структурированный HTTP 500, при этом сервис продолжал работать — никакого stack trace на клиенте, никаких упавших контейнеров, никакого зависшего процесса. Ошибка вернулась в аккуратном виде, на который можно опереться в коде.
Это именно то скучное и правильное поведение, которое и нужно в пайплайне. Скрейпер, который паникует на плохой цели, невозможно нормально автоматизировать. Здесь я получил ошибку, которую можно поймать и спокойно обработать дальше. Я проверил только один сценарий отказа, так что воспринимайте это как «одна проваленная попытка была обработана корректно», а не как полный аудит устойчивости — но именно в этом одном случае результат был правильный.
Реальность установки: самый тяжёлый подъём в базе
А теперь та часть, которую никто не показывает в скриншоте к анонсу. Firecrawl self-hosted, без преувеличения, оказался самым сложным в развёртывании инструментом из всей моей базы исследований — а я поднимал немало таких решений.
Шесть контейнеров — это базовая цена входа. Но по пути я ещё натолкнулся на две проблемы, и важно точно сказать, чья это была вина — как выяснилось, не Firecrawl.
Проблема первая: сборка из исходников. Сборка образов из исходников у меня падала внутри VM colima из-за ошибки snapshotter в containerd. Это известная нестабильная связка между сборкой и слоем хранения colima — сбой инфраструктуры в моей среде, а не баг Firecrawl. В compose-файле есть альтернативный путь: использовать официальные предсобранные образы ghcr.io/firecrawl/* вместо локальной сборки. Я переключился на них, и весь стек поднялся без проблем. Если вы работаете на обычном Docker daemon, а не через colima, вы можете вообще этого не увидеть; я отмечаю это как оговорку по окружению, а проверка сборки contributors на чистом daemon остаётся в списке пробелов.
Проблема вторая: SSRF-защита. Первые запросы были заблокированы защитой Firecrawl от private IP / SSRF. Почему? Сеть colima сопоставляет публичные домены с адресами 198.18.x.x, а это зарезервированный диапазон, который Firecrawl корректно считает приватным — то есть его слой безопасности сделал именно то, что должен, и отказался обращаться к тому, что выглядело как внутренний адрес. Чтобы обойти это только для локального тестирования, я установил ALLOW_LOCAL_WEBHOOKS=true.
Этот флаг легко по ошибке перенести в продакшен, и тогда он создаст инциденты, поэтому важно понимать, что это такое: SSRF-защита — это не помеха, а функция. Она как раз и не даёт скрейпинг-сервису быть обманутым и попасть в вашу внутреннюю сеть. Я отключил её только потому, что особенность DNS в colima заставляла мои легитимные публичные цели выглядеть как приватные внутри VM. В реальном продакшене отключать SSRF-защиту нельзя. Если вынести из этого обзора только одну операционную рекомендацию, пусть это будет именно она.
Обе проблемы, если говорить прямо, были следствием запуска Docker через colima на ноутбуке — а не дефектами самого ПО. С другой стороны, тяжесть установки сама по себе реальна, и это уже сознательное решение Firecrawl. Это не инструмент для быстрого локального скрипта; это инструмент для случая, когда вам нужен сервис для скрейпинга с рендерингом, и вы готовы ради него поддерживать инфраструктуру.
Что я не тестировал — и чего инструмент не даёт
Вот что я не покрывал и чего сам инструмент не предоставляет.
Self-hosted-версия не содержит Fire-engine. Облачный продукт Firecrawl включает Fire-engine — проприетарный слой обхода блокировок для прохождения бот-защиты. Согласно собственному SELF_HOST.md проекта, self-hosted-инсталляции этого слоя не получают. Поэтому если вы представляете self-hosted Firecrawl как решение, которое само по себе пробивает агрессивные антибот-системы, картину стоит скорректировать: эта возможность относится к облачному тарифу и в моём тесте не участвовала.
Облачный API здесь не тестировался. У меня не было cloud key, поэтому всё выше — это только self-hosted-стек. Управляемый облачный сервис — с Fire-engine, хостинговым масштабированием и AI-функциями — это другой продукт, и я не собираюсь оценивать его извне. Считайте любые выводы по облаку вне рамок этого обзора.
AI-функциям нужен ключ. Формат структурированного вывода json и endpoint /extract зависят от LLM, а значит вам понадобится либо ключ OpenAI, либо интеграция через Ollama. Я эти пути не проверял, поэтому /extract и структурированный вывод json тоже остаются в графе непроверенного.
Прокси — это оговорка, а не заголовок. Firecrawl поддерживает настройку прокси, но я сознательно упоминаю это только как сноску — это ручка, которую можно повернуть, а не причина выбирать именно этот инструмент. И в self-hosted-версии всё равно нет облачного anti-block слоя.
AGPL-3.0 — это реальный вопрос комплаенса. Этому стоит уделить отдельное внимание.
Лицензия: прочитайте AGPL-3.0 до запуска в продакшен
Firecrawl распространяется под AGPL-3.0. Это не пустая строка внизу README — это сильный copyleft с условием сетевого использования, и он может напрямую повлиять на то, сможете ли вы строить на self-hosted-экземпляре коммерческий продукт.
Если коротко: стандартные обязательства GPL включаются при распространении. AGPL идёт дальше — положение о сетевом использовании означает, что предоставление функциональности программы пользователям через сеть может считаться использованием, за которым идут обязательства по предоставлению исходного кода. Если вы встраиваете self-hosted Firecrawl в сервис, к которому ваши клиенты обращаются через интернет, это положение однозначно попадает в зону внимания, и аргумент «мы же никогда не распространяли бинарник» не спасает, как многие думают.
Я не ваш юрист, и трактовка лицензии зависит от того, как именно вы разворачиваете продукт. Но для любого коммерческого решения AGPL-3.0 — это вопрос первого уровня, а не мелкий шрифт. До того как строить на нём что-либо, подключите того, кто у вас отвечает за лицензирование. Упоминание AGPL — это не упрёк Firecrawl: у многих отличных инструментов AGPL, просто этот факт нужно учитывать заранее.
Где здесь место developer-стека Thunderbit
Попробовать Thunderbit для извлечения веб-данных
Если ваша реальная цель — «страница → Markdown, готовый для LLM» или «страница → структурированные данные», а шести-контейнерный операционный налог и вопрос AGPL вам не хочется брать на себя, именно для этого и создан developer-стек Thunderbit. Тот же AI-движок, который стоит за 100,000+ пользователями расширения, доступен в трёх форматах для технических задач — при этом инфраструктура остаётся на нашей стороне.
- Open API (REST).
POST /distillпревращает страницу в чистый Markdown, готовый для LLM;POST /extractвозвращает структурированные данные по заданной вами JSON Schema. Рендеринг JS, антибот-защита и динамический контент обрабатываются на сервере — браузерный контейнер вам не нужен. ФлагrenderMode(none/basic/full) управляет глубиной рендера, а batch-endpoints позволяют обрабатывать до 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 — без браузера и без стека, за которым нужно присматривать. Можно сразу прокинуть результат в другие инструменты:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Контраст с Firecrawl self-hosted здесь вполне чёткий. Firecrawl self-hosted даёт полный контроль и полную операционную ответственность: шесть контейнеров, вес установки, условия AGPL и отсутствие Fire-engine для обхода блокировок. Thunderbit API/MCP/CLI меняет контроль на хостинговый движок, который возвращает структурированный JSON, совпадающий со схемой, а не просто сырой Markdown, — при этом контейнеры, anti-bot слой и copyleft-обязательства не ложатся на вас. Это разные инструменты для разной терпимости к инфраструктуре.
Вот обмен в одном взгляде:
| Сравнение | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Формат развёртывания | Сервис, которым вы управляете (6 контейнеров) | Хостинговый API, к которому вы обращаетесь |
| Чтобы запустить | Поднять 6-сервисный стек через docker compose | Получить API key и отправить запрос |
| Рендеринг JS | Встроенный playwright-service (вы обслуживаете его сами) | На стороне сервера, через флаг renderMode |
| Структурированный вывод | Нужен LLM key (/extract, json) | POST /extract с JSON Schema |
| Anti-bot слой | В self-hosted отсутствует (Fire-engine только в облаке) | Обрабатывается на стороне сервера |
| Лицензия | AGPL-3.0 (network-use copyleft) | Коммерческий API, без copyleft на ваш код |
| Когда лучше всего подходит | Когда нужен полный контроль и вы готовы обслуживать инфраструктуру | Когда нужен Markdown/структурированные данные без ops-нагрузки |
Ни один из вариантов не «лучше» во всех случаях. Если для вас важно именно управлять платформой — полный контроль над данными, отсутствие внешней зависимости, и AGPL вам подходит — self-hosted Firecrawl остаётся мощным и активно поддерживаемым выбором. Если же вам проще сделать API-запрос и не жить в мире шести контейнеров, то именно это и предлагает Thunderbit.
Кому действительно стоит разворачивать Firecrawl у себя
Если убрать весь шум, картина довольно чётко раскладывается по потребностям.
Разворачивайте Firecrawl у себя, если вам нужен полный контроль над инфраструктурой скрейпинга, вы готовы в продакшене обслуживать Redis / RabbitMQ / Postgres / FoundationDB, ваши задачи по рендерингу оправдывают контейнер playwright-service, а AGPL-3.0 устраивает в вашей схеме развёртывания. Базовая возможность здесь реальна: я получил чистый, структурированный Markdown, готовый для LLM, и со статической страницы, и со страницы, которая рендерится через JavaScript, а весь стек запускался на предсобранных образах.
Ищите другое решение, если вам нужен быстрый локальный скрипт (это, без вопросов, самая тяжёлая установка в базе), вам нужен антиблок уровня облака без собственного обслуживания (в self-hosted нет Fire-engine), или сетевое условие AGPL конфликтует с вашими коммерческими планами. Для сценария «мне просто нужен Markdown или структурированные данные по URL без операционной нагрузки» облачный API вроде Thunderbit /distill и /extract закрывает ту же задачу без контейнеров.
Мой предварительный вывод: сильная базовая функциональность, серьёзная операционная нагрузка и лицензия, которую нужно проверить до коммерческого использования. Это отличный вариант для команд, которые хотят владеть всем пайплайном целиком, но и требует он немало. К финальному вердикту я вернусь после того, как прогоню /v1/crawl, проверю /extract с LLM-ключом и подтвержу сборку из исходников на daemon, отличном от colima; именно это сейчас разделяет предварительную оценку и окончательный вывод.
Попробовать Thunderbit для извлечения веб-данных Get Started Free
Часто задаваемые вопросы
Self-hosted Firecrawl — это то же самое, что облачная версия?
Нет. Self-hosted даёт вам основной движок для превращения страниц в Markdown и рендеринг JavaScript через встроенный playwright-service, но не включает Fire-engine — проприетарный anti-block слой облачного продукта. AI-функции вроде endpoint /extract и вывода json тоже требуют собственного LLM-ключа (OpenAI или Ollama). В этом обзоре я тестировал только self-hosted-стек; облачный API был вне рамок.
Сколько контейнеров реально нужно Firecrawl в self-hosted? Шесть: api, playwright-service, redis, rabbitmq, nuq-postgres и foundationdb. Это полноценный сервисный стек, а не один исполняемый файл — и именно поэтому его установка оказалась самой тяжёлой во всей базе инструментов, которые я проверял. Планируйте не просто «запустить скрипт», а обслуживать очередь, кэш и инфраструктуру баз данных.
Может ли self-hosted Firecrawl работать с JavaScript-тяжёлыми страницами? Да, по моим тестам — может. Встроенный playwright-service рендерит страницу в реальном браузерном движке до извлечения данных. Я проверил это на quotes.toscrape.com/js/, где цитата Эйнштейна — контент, который появляется только после выполнения JavaScript, — действительно попала в возвращённый Markdown. Именно ради этого одного из шести контейнеров и нужен headless-браузер.
Влияет ли лицензия AGPL-3.0 на коммерческое использование? Да, может влиять, и это нужно считать вопросом первого порядка. AGPL-3.0 — это сильный copyleft с сетевым условием, а значит предоставление функциональности программы пользователям по сети может влечь обязательства по раскрытию исходного кода — даже если вы никогда не распространяли бинарный файл. Если вы собираетесь строить коммерческий продукт на self-hosted-экземпляре, поговорите с тем, кто у вас отвечает за лицензирование, прежде чем принимать решение. Этот обзор просто отмечает лицензию; это не юридическая консультация.
В чём разница между Firecrawl и developer-инструментами Thunderbit?
Firecrawl self-hosted — это сервис, которым вы управляете: шесть контейнеров, которые вы запускаете сами, условия AGPL-3.0 и отсутствие встроенного anti-block слоя. Developer-стек Thunderbit (Open API, MCP server, CLI) — это хостинговый движок, к которому вы обращаетесь: POST /distill для Markdown, POST /extract для структурированных данных по JSON Schema, с рендерингом JS и антибот-защитой на сервере и без copyleft-обязательств на ваш код. Firecrawl подходит командам, которым нужен полный контроль над инфраструктурой; Thunderbit — тем, кто хочет получить результат без операционной нагрузки.
