대부분의 사람들은 Firecrawl을 스크래핑 라이브러리, 그러니까 pip install하고 스크립트 몇 줄 짜면 끝나는 도구로 생각하는 경향이 있어요. 하지만 이런 생각은 좀 잘못된 거라, 명령어 한 줄 입력하기 전부터 이 차이를 정확히 아는 게 중요합니다. Firecrawl 자체 호스팅은 그냥 가져다 쓰는 라이브러리가 아니라, 직접 운영해야 하는 서비스거든요. 이걸 설치하려면 서로 통신하는 Docker 컨테이너 6개를 돌려야 해요.
저는 Mac(arm64, colima를 통한 Docker 환경)에서 클라우드 키 없이 자체 호스팅 스택을 돌려봤어요. 그리고 /v1/scrape 엔드포인트를 몇몇 스크래핑 친화적인 데모 사이트에 연결해서 결과를 확인해봤죠. 결론부터 말하자면, 핵심적인 약속은 잘 지켜졌습니다. 페이지를 입력하면 깔끔하게 LLM이 바로 쓸 수 있는 마크다운이 튀어나왔거든요. 그런데 이 연구 기반에 있는 어떤 도구보다도 설정이 제일 복잡했어요. 이건 최종 평가라기보다는 잠정적인 검토이고, 제가 뭘 테스트했고 뭘 테스트하지 않았는지 명확히 말씀드릴게요.
Firecrawl은 라이브러리가 아니라 서비스입니다.
가장 먼저 고쳐야 할 생각은 바로 이거예요. 대부분의 개발자들이 쓰는 스크래핑 도구는 라이브러리죠. 의존성 추가하고 함수 호출하면 자기 프로세스 안에서 HTML이나 파싱된 데이터를 얻을 수 있잖아요. Firecrawl 자체 호스팅은 좀 다른 종류의 도구예요. 자체 API를 가진 실행 플랫폼이고, HTTP를 통해 통신합니다.
공식적인 포지셔닝은 "웹을 대규모로 검색, 스크래핑 및 상호 작용하는 API"인데, 제품 형태가 딱 그래요. 페이지를 입력하면 깔끔한 마크다운이나 구조화된 데이터가 나옵니다. 자체 호스팅할 때는 Firecrawl에 연결하는 게 아니에요. docker compose 스택을 올리고 엔드포인트를 호출하는 거죠. 이건 마치 다른 내부 마이크로서비스를 호출하는 것과 같아요.
제가 돌려본 스택은 6개의 서비스로 구성되어 있었어요.
- api — 실제로 호출하는 HTTP 인터페이스
- playwright-service — JavaScript 렌더링을 위한 헤드리스 브라우저
- redis — 큐 및 캐시
- rabbitmq — 메시지 브로커
- nuq-postgres — 작업 상태를 위한 Postgres 변형
- foundationdb — 분산 키-값 스토리지
이건 단순한 헬퍼 스크립트가 아니라, 진짜 백엔드예요. Redis, RabbitMQ, Postgres, FoundationDB는 모두 그 자체로 산업 등급의 인프라입니다. Firecrawl은 스크래핑의 복잡한 부분(큐잉, 렌더링, 재시도)을 하나의 API 호출 뒤에서 처리해줘요. 그 대가로 이 6개의 컨테이너를 직접 운영해야 하는 거죠. 이런 장단점을 염두에 두세요. 이게 이 전체 리뷰의 핵심입니다.
참고로, 저는 firecrawl-py 4.32.0 및 firecrawl-js 4.30.0 SDK를 사용해서 2026년 7월 9일에 공식적으로 사전 빌드된 ghcr.io/firecrawl/firecrawl:latest 이미지를 가져와 테스트했습니다. 해당 날짜 기준으로 저장소는 약 14만 8천 개의 별을 가지고 있으며(품질 점수라기보다는 그냥 메타데이터로 봐주세요), AGPL-3.0 라이선스를 따릅니다. 이 부분은 상업적 사용에 대한 계산을 바꾸는 부분이라 다시 언급할 거예요.
핵심 테스트: 페이지가 깔끔한 마크다운이 됩니다.
Firecrawl이 존재하는 주된 이유는 웹 페이지를 LLM이 실제로 읽을 수 있는 마크다운으로 바꿔주는 거예요. 그래서 가장 먼저 확인한 게 바로 이 부분입니다.
저는 /v1/scrape를 스크래핑 연습용으로 특별히 만들어진 정적 카탈로그인 books.toscrape.com에 연결해봤어요. 결과는 9,222자의 깔끔하고 LLM이 바로 쓸 수 있는 마크다운이었고, 페이지 제목 All products | Books to Scrape도 정확하게 파싱되었어요. 그냥 문자열로 덤프된 원시 HTML이 아니라, 제목, 링크, 이미지 참조가 그대로 살아있는 구조화된 마크다운이었죠. 검색 파이프라인에 바로 넣거나, 두 번째 정리 과정 없이 모델에 바로 먹일 수 있는 그런 종류의 출력입니다.
이게 Firecrawl의 핵심 강점이고, 자체 호스팅은 아무 문제 없이 이걸 제공했어요. 만약 당신의 작업이 "이 페이지의 읽을 수 있는 내용을 마크다운으로 줘"라면, 정적 페이지는 광고된 대로 정확히 반환되었습니다. 이건 정말 유용한 기본 기능이고, 이 도구가 인기를 끄는 이유죠.
범위에 대해 정확히 말하자면, 저는 단일 페이지 /v1/scrape 경로만 사용했어요. 전체 사이트를 탐색하는 다중 페이지 크롤러인 /v1/crawl은 테스트하지 않았습니다. 이건 자체적인 실패 모드를 가진 별도의 기능이고, 제가 돌려보지 않았으니 작동한다고 주장할 수는 없겠죠.
JavaScript 페이지: 번들 브라우저가 컨테이너의 가치를 증명합니다.
정적 페이지는 쉬운 경우죠. 스크래퍼에게 더 어려운 질문은 JavaScript가 실행된 후에야 콘텐츠가 나타나는 경우예요. 현대 웹에서는 대부분의 경우가 그렇습니다.
이게 바로 playwright-service 컨테이너가 단순한 오버헤드가 아니라 핵심이 되는 지점이에요. 저는 스크래퍼를 quotes.toscrape.com/js/에 연결해봤어요. 이 데모 사이트는 클라이언트 측에서 인용문을 렌더링합니다. Firecrawl이 원시 HTML만 가져왔다면 인용문은 존재하지 않았을 거예요. 브라우저가 페이지 스크립트를 실행하기 전까지는 존재하지 않으니까요.
스크래핑 결과 1,574자의 마크다운이 반환되었고, 아인슈타인 인용문이 포함되어 있었어요. 이 인용문은 JavaScript 실행 후 콘텐츠입니다. 이 인용문의 존재는 playwright-service가 텍스트를 추출하기 전에 실제 브라우저 엔진에서 페이지를 실제로 렌더링했다는 걸 증명해요. 빈 사전 렌더링 껍데기를 가져온 게 아니라는 거죠.
그러니까 6개의 컨테이너 중 하나는 헤드리스 브라우저이고, 그 역할을 제대로 해냅니다. 이게 더 무거운 아키텍처에 대한 구체적인 정당성이에요. 컨테이너 비용만 지불하는 게 아니라, 자체 브라우저 자동화를 연결할 필요 없이 JS가 많은 페이지를 렌더링할 수 있는 기능에 대한 비용을 지불하는 거죠. 많은 실제 대상의 경우, 이건 쓸모 있는 출력과 텅 빈 div 사이의 차이를 만듭니다.
대상이 불량할 때: 구조화된 오류, 충돌 없음
스크래퍼는 작동하지 않는 대상(죽은 호스트, 오타가 있는 URL, 응답 없는 서버)을 향해 놀랍도록 많은 시간을 보냅니다. 도구가 실패하는 방식은 성공하는 방식만큼이나 중요해요.
저는 의도적으로 API에 유효하지 않은 호스트를 줘봤어요. API는 구조화된 HTTP 500을 반환하고 계속 실행되었습니다. 클라이언트에 스택 추적이 쏟아지거나, 컨테이너가 넘어지거나, 프로세스가 멈추는 일은 없었어요. 오류는 호출자가 분기할 수 있는 깔끔한 응답으로 반환되었습니다.
이건 파이프라인에 넣을 만한 도구에서 기대하는 지루하지만 올바른 동작이에요. 불량한 대상에서 패닉하는 스크래퍼는 자동화할 수 없는 스크래퍼입니다. 이 도구는 잡아서 계속 진행할 수 있는 오류를 반환했어요. 저는 단일 오류 사례만 테스트했으니, 이걸 "제가 던진 하나의 실패를 올바르게 처리했다"고 읽어야 하며, 철저한 복원력 감사로 간주해서는 안 됩니다. 하지만 하나의 데이터 포인트는 올바른 결과였어요.
설정 현실: 가장 무거운 작업
이제 출시 트윗에 스크린샷이 찍히지 않는 부분입니다. Firecrawl 자체 호스팅은 과장 없이 이 연구 기반의 어떤 도구보다도 가장 복잡한 설정이었어요. 그리고 저는 많은 도구를 설치해 봤습니다.
6개의 컨테이너는 기본 비용이에요. 하지만 설치 과정에서 두 가지 문제에 부딪혔고, 누구의 잘못인지 정확히 밝히고 싶어요. 결국 Firecrawl의 잘못은 아니었습니다.
첫 번째 문제: 소스에서 빌드. colima VM 내에서 containerd 스냅샷 오류 때문에 소스에서 이미지를 빌드하는 데 실패했어요. 이건 빌드와 colima의 스토리지 계층 간에 알려진 불안정한 상호 작용입니다. Firecrawl의 버그가 아니라 제 환경의 인프라 문제였어요. compose 파일은 대안을 문서화하고 있습니다. 로컬에서 빌드하는 대신 공식적으로 사전 빌드된 ghcr.io/firecrawl/* 이미지를 사용하라는 거죠. 저는 이 이미지로 전환했고, 전체 스택이 깔끔하게 올라왔습니다. colima가 아닌 표준 Docker 데몬을 사용한다면 이 문제를 전혀 겪지 않을 수도 있어요. 저는 이걸 환경적 주의 사항으로 표시하며, 깨끗한 데몬에서 기여자 빌드를 검증하는 건 제 미해결 목록에 있습니다.
두 번째 문제: SSRF 보호. 제 첫 스크래핑은 Firecrawl의 사설 IP / SSRF 보호에 의해 차단되었어요. 왜 그랬을까요? colima의 네트워킹은 공용 호스트 이름을 198.18.x.x 주소에 매핑합니다. 이 주소는 Firecrawl이 사설로 올바르게 처리하는 예약된 범위에 속해요. 따라서 보안 계층이 제대로 작동해서 내부 대상으로 보이는 것을 가져오기를 거부한 거죠. 로컬 테스트용으로만 이 문제를 해결하기 위해 ALLOW_LOCAL_WEBHOOKS=true를 설정했습니다.
이 플래그는 프로덕션에 복사되어 사고를 유발하므로, 이게 뭔지 정확히 알아야 해요. SSRF 보호는 장애물이 아니라 기능입니다. 스크래핑 서비스가 내부 네트워크를 공격하도록 속이는 것을 막는 거죠. colima의 DNS 특성 때문에 합법적인 공용 대상이 VM 내에서 사설로 보였기 때문에 저는 이걸 비활성화했습니다. 실제 배포에서는 SSRF 보호를 끄지 마세요. 이 리뷰에서 한 가지 운영상의 주의 사항을 얻는다면, 바로 이거예요.
두 가지 문제 모두, 솔직히 말해서, 노트북에서 colima를 통해 Docker를 실행할 때 발생하는 문제였으며 소프트웨어의 결함은 아니었습니다. 반면에, 설정 자체의 복잡성은 실제이며 Firecrawl의 설계에 따른 거예요. 이건 빠른 로컬 스크립트를 원할 때 쓰는 도구가 아닙니다. 렌더링 가능한 스크래핑 서비스를 원하고 이걸 위한 인프라를 운영할 의향이 있을 때 쓰는 도구죠.
테스트하지 않은 것과 이 도구가 제공하지 않는 것
제가 다루지 않은 내용과 이 도구가 제공하지 않는 내용은 다음과 같습니다.
자체 호스팅에는 Fire-engine이 없습니다. Firecrawl의 클라우드 제품에는 봇 방어 시스템을 우회하기 위한 독점적인 안티 블록 계층인 Fire-engine이 포함되어 있어요. 프로젝트 자체의 SELF_HOST.md에 따르면, 자체 호스팅 인스턴스에는 Fire-engine이 제공되지 않습니다. 따라서 자체 호스팅 Firecrawl이 공격적인 안티 봇 시스템을 기본적으로 뚫을 거라고 생각한다면, 그 생각을 수정해야 해요. 해당 기능은 클라우드 계층에 있으며, 제가 돌려본 부분에는 포함되지 않았습니다.
클라우드 API는 여기서 테스트되지 않았습니다. 저는 클라우드 키가 없었으므로, 위에서 언급한 모든 내용은 자체 호스팅 스택에만 해당됩니다. Fire-engine, 호스팅된 스케일링, AI 기능이 포함된 관리형 클라우드 서비스는 다른 제품이며, 외부에서 그 성능을 특징짓지 않을 거예요. 이 리뷰의 범위 밖의 클라우드 주장은 모두 무시하세요.
AI 기능에는 키가 필요합니다. json 구조화된 출력 형식과 /extract 엔드포인트는 LLM에 의존해요. 이는 OpenAI 키를 가져오거나 Ollama를 연결해야 함을 의미합니다. 이는 모델 선택을 재료 목록에 포함시킵니다. 설정을 확정하기 전에 가져올 수 있는 공급자의 현재 API 가격을 비교하세요. 저는 이러한 경로를 사용하지 않았으므로, /extract 및 구조화된 json 출력도 테스트되지 않은 열에 있습니다.
프록시는 주의 사항이지 핵심이 아닙니다. Firecrawl은 프록시 구성을 지원하지만, 의도적으로 각주로 나열합니다. 이건 조정할 수 있는 노브이지, 도구를 선택하는 이유가 아니며, 자체 호스팅은 여전히 클라우드의 안티 블록 계층이 없습니다.
AGPL-3.0은 실제 규정 준수 결정입니다. 이 부분은 자체적으로 다룰 가치가 있습니다.
라이선스: 배포하기 전에 AGPL-3.0을 읽으십시오.
Firecrawl은 AGPL-3.0 라이선스에 따라 배포됩니다. 이건 README 하단에 있는 대충 쓴 문구가 아니에요. 네트워크 사용 조항이 있는 강력한 카피레프트이며, 자체 호스팅 인스턴스 위에 상업용 제품을 구축할 수 있는지 여부에 직접적인 영향을 미칠 수 있습니다.
요약하자면, 표준 GPL 의무는 배포 시 발생합니다. AGPL은 더 나아가 네트워크 사용 조항은 네트워크를 통해 사용자에게 소프트웨어 기능을 제공하는 것이 소스 가용성 의무를 수반하는 사용으로 간주될 수 있음을 의미합니다. 고객이 인터넷을 통해 접근하는 서비스 내에 자체 호스팅 Firecrawl을 포함하는 경우, 해당 조항은 명확히 적용되며, "우리는 바이너리를 배포하지 않았다"는 사람들이 생각하는 탈출구가 아닙니다.
저는 변호사가 아니며, 라이선스 해석은 배포 방식에 따라 달라집니다. 그러나 모든 상업적 권장 사항에 대해 AGPL-3.0은 세부 사항이 아닌 최우선 고려 사항입니다. 회사 내에서 라이선스를 담당하는 사람과 상의한 후 구축하세요. 이걸 지적하는 건 Firecrawl에 대한 비난이 아닙니다. 훌륭한 도구 중 많은 것이 AGPL이지만, 이건 초기에 고려해야 할 사실입니다.
Thunderbit의 개발자 스택이 적합한 경우
실제 목표가 "페이지 → LLM 준비 마크다운" 또는 "페이지 → 구조화된 데이터"이고, 6개 컨테이너 운영 비용과 AGPL 문제가 부담스럽다면, 바로 Thunderbit의 개발자 스택이 이를 위해 만들어졌습니다. 10만 명 이상의 확장 사용자 뒤에 있는 동일한 AI 엔진이 기술 작업을 위해 세 가지 방식으로 노출됩니다. 인프라는 저희 측에서 관리합니다.
- 오픈 API (REST).
POST /distill은 페이지를 깔끔한 LLM 준비 마크다운으로 변환합니다.POST /extract는 당신이 정의한 JSON 스키마에 따라 구조화된 데이터를 반환합니다. JS 렌더링, 안티 봇 처리, 동적 콘텐츠는 서버 측에서 처리됩니다. 브라우저 컨테이너를 실행할 필요가 없어요.renderMode플래그(none/basic/full)는 렌더링 강도를 제어하며, 배치 엔드포인트는 최대 100개의 URL을 처리하여 증류합니다. - MCP 서버. 공식 모델 컨텍스트 프로토콜 서버를 통해 Claude 또는 Cursor 내의 AI 에이전트가 작업 중에 스크래핑할 수 있습니다.
thunderbit_suggest_fields는 추출 계획을 세우고(무료),thunderbit_distill은 마크다운을,thunderbit_extract는 구조화된 데이터를 제공합니다. 에이전트는 환경을 벗어나지 않고 데이터를 가져올 시점을 결정합니다. - CLI.
npx -y @thunderbit/thunderbit-cli는 터미널, 스크립트, CI 또는 cron에서 스크래핑을 실행합니다. 브라우저나 관리할 스택이 필요 없어요. 다른 도구로 바로 파이프할 수 있습니다.thunderbit distill "$URL" -f markdown | claude -p "summarise".
자체 호스팅 Firecrawl과의 대조는 명확합니다. Firecrawl 자체 호스팅은 완전한 제어와 완전한 운영 소유권을 제공합니다. 6개의 컨테이너, 설정 복잡성, AGPL 조건, 그리고 안티 블록을 위한 Fire-engine이 없죠. Thunderbit의 API/MCP/CLI는 이러한 제어를 호스팅된 엔진과 교환하여 스키마 일치 구조화된 JSON(원시 마크다운뿐만 아니라)을 반환하며, 컨테이너, 안티 봇 계층, 카피레프트 의무를 제거합니다. 인프라에 대한 욕구에 따라 다른 도구입니다.
다음은 한눈에 보는 장단점입니다.
| 고려 사항 | Firecrawl 자체 호스팅 | Thunderbit 개발자 스택 (API · MCP · CLI) |
|---|---|---|
| 배포 형태 | 운영하는 서비스 (6개 컨테이너) | 호출하는 호스팅 API |
| 실행 방법 | 6개 서비스 스택을 docker compose로 올림 | API 키, 그 다음 요청 |
| JS 렌더링 | 번들된 playwright-service (직접 실행) | 서버 측, renderMode 플래그 |
| 구조화된 출력 | LLM 키 필요 (/extract, json) | JSON 스키마와 함께 POST /extract |
| 안티 봇 계층 | 자체 호스팅 없음 (Fire-engine은 클라우드 전용) | 서버 측에서 처리 |
| 라이선스 | AGPL-3.0 (네트워크 사용 카피레프트) | 상업용 API, 코드에 카피레프트 없음 |
| 가장 적합한 경우 | 완전한 제어를 원하고 인프라를 운영할 경우 | 운영 없이 마크다운/구조화된 데이터를 원할 경우 |
어느 쪽이든 보편적으로 "더 좋다"고 할 수는 없어요. 플랫폼 운영 자체가 당신에게 중요한 경우(완전한 데이터 제어, 외부 종속성 없음, AGPL이 상황에 적합한 경우) 자체 호스팅 Firecrawl은 유능하고 활발하게 유지 관리되는 선택입니다. API 호출을 하고 6개 컨테이너 생활을 건너뛰고 싶다면, 그것이 Thunderbit 스택의 장점입니다.
누가 실제로 Firecrawl을 자체 호스팅해야 하는가
과장된 부분을 걷어내면 필요에 따라 분류하기에 충분히 명확한 그림이 나옵니다.
Firecrawl을 자체 호스팅해야 하는 경우는 스크래핑 인프라에 대한 완전한 제어를 원하고, Redis / RabbitMQ / Postgres / FoundationDB를 프로덕션에서 운영하는 데 익숙하며, 렌더링 요구 사항이 playwright-service 컨테이너를 정당화하고, AGPL-3.0이 배포 방식에 적합한 경우입니다. 핵심 기능은 진짜예요. 저는 정적 페이지와 JS 렌더링 페이지 모두에서 깔끔하고 구조화된 LLM 준비 마크다운을 얻었으며, 전체 스택은 사전 빌드된 이미지에서 실행되었습니다.
다른 대안을 찾아야 하는 경우는 빠른 로컬 스크립트를 원하거나(이건 가장 복잡한 설정입니다), 직접 운영하지 않고 클라우드 수준의 안티 블록이 필요하거나(자체 호스팅에는 Fire-engine이 없음), AGPL 네트워크 사용 조항이 상업적 계획과 충돌하는 경우입니다. "URL에서 마크다운 또는 구조화된 데이터만 필요하고 운영은 필요 없는" 경우에는 Thunderbit의 /distill 및 /extract와 같은 호스팅된 API가 컨테이너 없이 동일한 기능을 제공합니다.
제 잠정적인 판단은 다음과 같습니다. 강력한 핵심 기능, 무거운 운영 부담, 그리고 상업적으로 구축하기 전에 해결해야 할 라이선스 문제가 있습니다. 전체 파이프라인을 소유하려는 팀에게는 그 가치를 인정받지만, 다른 모든 사람에게는 많은 것을 요구합니다. /v1/crawl을 실행하고, LLM 키로 /extract를 사용하고, 비 colima 데몬에서 소스 빌드를 검증한 후에 다시 검토할 거예요. 이것들이 최종 판결까지 남은 미해결 질문들입니다.
웹 데이터 추출을 위해 Thunderbit 사용해보기 Get Started Free
자주 묻는 질문
자체 호스팅 Firecrawl은 클라우드 버전과 동일한가요?
아닙니다. 자체 호스팅은 핵심 스크래핑-마크다운 엔진과 번들된 playwright-service를 통한 JavaScript 렌더링을 제공하지만, 클라우드 제품의 독점적인 안티 블록 계층인 Fire-engine은 포함하지 않습니다. /extract 엔드포인트 및 json 출력과 같은 AI 기능도 자체 LLM 키(OpenAI 또는 Ollama)를 필요로 합니다. 이 리뷰에서는 자체 호스팅 스택만 테스트했으며, 클라우드 API는 범위 밖이었습니다.
자체 호스팅 Firecrawl은 실제로 몇 개의 컨테이너가 필요한가요? 6개입니다: api, playwright-service, redis, rabbitmq, nuq-postgres, foundationdb. 이는 단일 바이너리가 아닌 완전한 서비스 스택입니다. 이것이 이 연구 기반의 어떤 도구보다도 가장 복잡한 설정이었던 이유입니다. 스크립트뿐만 아니라 메시지 브로커, 캐시, 데이터베이스 인프라를 운영하는 데 필요한 운영 오버헤드를 계획하십시오.
Firecrawl은 자체 호스팅 시 JavaScript가 많은 페이지를 처리할 수 있나요? 네, 제 테스트에서는 가능했습니다. 번들된 playwright-service는 추출 전에 실제 브라우저 엔진에서 페이지를 렌더링합니다. 저는 quotes.toscrape.com/js/에서 이를 확인했습니다. JavaScript가 실행된 후에만 존재하는 콘텐츠인 아인슈타인 인용문이 반환된 마크다운에 나타났습니다. 이 렌더링 기능이 바로 6개의 컨테이너 중 하나가 헤드리스 브라우저인 이유입니다.
AGPL-3.0 라이선스는 상업적 사용에 영향을 미치나요? 영향을 미칠 수 있으며, 이를 최우선 질문으로 다루어야 합니다. AGPL-3.0은 네트워크 사용 조항이 있는 강력한 카피레프트이며, 네트워크를 통해 사용자에게 소프트웨어 기능을 제공하는 것이 소스 가용성 의무를 수반할 수 있음을 의미합니다. 바이너리를 배포하지 않더라도 말입니다. 자체 호스팅 인스턴스 위에 상업용 제품을 구축할 계획이라면, 약속하기 전에 회사 내에서 라이선스를 담당하는 사람과 상의하십시오. 이 리뷰는 라이선스를 지적하는 것이지 법률 자문이 아닙니다.
Firecrawl과 Thunderbit의 개발자 도구의 차이점은 무엇인가요?
Firecrawl 자체 호스팅은 직접 운영하는 서비스입니다. AGPL-3.0 조건과 내장된 안티 블록 계층이 없는 6개의 컨테이너를 직접 실행해야 합니다. Thunderbit의 개발자 스택(오픈 API, MCP 서버, CLI)은 호출하는 호스팅된 엔진입니다. 마크다운을 위한 POST /distill, JSON 스키마 구조화된 데이터를 위한 POST /extract를 제공하며, JS 렌더링 및 안티 봇 처리는 서버 측에서 이루어지고 코드에 대한 카피레프트 의무가 없습니다. Firecrawl은 완전한 인프라 제어를 원하는 팀에 적합하고, Thunderbit은 운영 부담 없이 출력을 원하는 팀에 적합합니다.
