大多数人可能会觉得 Firecrawl 就是个抓取库，那种 pip install 一下，写个脚本就能搞定的工具。但这种想法其实不太对，在你敲任何命令之前，搞清楚它到底是个啥很重要。Firecrawl 的自托管版本可不是那种你能直接导入的库；它更像一个需要你自己去运维的服务，部署它就意味着你得跑起来六个互相通信的 Docker 容器。
我在 Mac（arm64 架构，通过 colima 跑 Docker）上试了试自托管的堆栈，没用云密钥，把它的 /v1/scrape 端点指向了几个对抓取比较友好的演示网站，然后看看返回结果。简单来说：它核心的承诺确实兑现了——输入页面后，能输出干净的、LLM 就绪的 Markdown 格式内容。但它的设置，说实话，是我研究过的所有工具里最麻烦的。这只是初步观察，不是最终评判，我会明确说明我测试了哪些，没测试哪些。
Firecrawl 是个服务，不是库
首先，得把思维模式扭过来。大多数开发者用的抓取工具都是库：你加个依赖，调个函数，然后在自己的进程里拿到 HTML 或者解析好的数据。Firecrawl 的自托管版本完全不是这样。它是一个自带 API 的运行平台，你需要通过 HTTP 跟它通信。
官方把它定位成“用于大规模搜索、抓取和与网络交互的 API”，它的产品形态也确实如此——输入页面，输出干净的 Markdown 或结构化数据。当你自托管的时候，你不是在链接 Firecrawl，你是在启动一个 docker compose 堆栈，然后访问一个端点，就像你访问任何内部微服务一样。
我跑的堆栈包含了六个服务：
- api — 你实际调用的 HTTP 接口
- playwright-service — 用于 JavaScript 渲染的无头浏览器
- redis — 队列和缓存
- rabbitmq — 消息代理
- nuq-postgres — 用于作业状态的 Postgres 变体
- foundationdb — 分布式键值存储
这可是一个实打实的后端，不是什么辅助脚本。Redis、RabbitMQ、Postgres 和 FoundationDB 本身都是工业级的底层基础设施。它的好处是 Firecrawl 通过一个 API 调用，帮你搞定了抓取过程中那些麻烦事——队列、渲染、重试。代价就是你现在得运维这六个容器。记住这种权衡；这是整个评测的重点。
作为参考，我测试了 firecrawl-py 4.32.0 和 firecrawl-js 4.30.0 SDK，并在 2026 年 7 月 9 日拉取了官方预构建的 ghcr.io/firecrawl/firecrawl:latest 镜像。截至那天，这个仓库大概有 14.8 万颗星（这可以看作是元数据，不是质量评分），采用 AGPL-3.0 许可证——我后面还会提到这个细节，因为它会影响商业使用的考量。
核心测试：页面转成干净的 Markdown
Firecrawl 存在的全部意义就是把网页转换成 LLM 能读懂的 Markdown 格式。所以，我首先就测试了这个。
我把 /v1/scrape 指向了 books.toscrape.com，这是一个专门为抓取练习搭建的静态目录。结果：9,222 个字符的干净、LLM 就绪的 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 页面而付费。对于许多实际目标来说，这是能得到有用输出和只得到空 div 的区别。
当目标出问题时：结构化错误，而不是崩溃
爬虫大部分时候都会遇到不正常的目标——死主机、拼写错误的 URL、挂起的服务器。一个工具如何失败，和它如何成功一样能说明问题。
我故意给 API 提供了无效主机。它返回了一个结构化的 HTTP 500 错误，然后继续运行——没有向客户端吐出堆栈跟踪，没有容器崩溃，也没有进程挂起。错误以干净的响应返回，调用者可以根据这个进行分支处理。
这是你在管道中使用的工具应该具备的，虽然无聊但正确的行为。一个在遇到错误目标时崩溃的爬虫是无法自动化的。这个工具返回了一个你可以捕获并继续处理的错误。我只测试了一种错误情况，所以请理解为“正确处理了我抛出的一个故障”，而不是详尽的弹性审计——但这个数据点是正确的结果。
设置的真实情况：基础中最繁重的工作
现在来说说那些发推文时没人会截图的部分。Firecrawl 的自托管版本，毫不夸张地说，是我所有研究过的工具中设置最复杂的——而我已经搭过很多这样的工具了。
六个容器是基本成本。但我在安装过程中也遇到了两个障碍，我想准确说明是谁的错——事实证明，不是 Firecrawl 的错。
第一个障碍：从源代码构建。 在我的 colima 虚拟机里，从源代码构建镜像时，因为 containerd 快照器错误而失败了。这是构建和 colima 存储层之间已知的、不稳定的交互——是我环境中的基础设施问题，而不是 Firecrawl 的 bug。compose 文件里记录了一个替代方案：使用官方预构建的 ghcr.io/firecrawl/* 镜像，而不是在本地构建。我切换到这些镜像后，整个堆栈就干净地启动了。如果你用的是标准 Docker 守护进程而不是 colima，你可能根本不会遇到这种情况；我把它标记为环境注意事项，并且在干净的守护进程上验证贡献者构建是我待办事项中的一项。
第二个障碍：SSRF 防护。 我的第一次抓取被 Firecrawl 的私有 IP / SSRF 保护阻止了。为什么？colima 的网络把公共主机名映射到了 198.18.x.x 地址，这些地址在 Firecrawl 正确视为私有的保留范围内——所以它的安全层发挥了作用，拒绝抓取看起来像内部目标的内容。为了 仅在本地测试时 绕过这个限制，我设置了 ALLOW_LOCAL_WEBHOOKS=true。
这个标志会被复制粘贴到生产环境中并导致事故，所以请准确理解它是什么：SSRF 防护是一个功能，而不是障碍。它阻止了抓取服务被欺骗去访问你的内部网络。我禁用它是因为 colima DNS 的一个怪癖导致我的合法公共目标在虚拟机内部看起来是私有的。在实际部署中，请勿关闭 SSRF 防护。如果你从本次评测中只记住一个操作注意事项，请记住这一点。
这两个障碍，坦率地说，都是在笔记本电脑上通过 colima 运行 Docker 的产物——而不是软件本身的缺陷。另一方面，设置本身的重量是真实存在的，而且是 Firecrawl 设计使然。这不是你想要快速本地脚本时用的工具；它是当你想要一个具备渲染能力的抓取服务，并且愿意为此运行基础设施时才用的工具。
我没测试什么，以及它不能做什么
以下是我没涵盖的内容，以及这个工具不提供什么。
自托管版本没有 Fire-engine。 Firecrawl 的云产品包含 Fire-engine，这是它专有的反屏蔽层，用于绕过机器人防御。根据项目自己的 SELF_HOST.md 文件，自托管实例不包含此功能。所以，如果你设想自托管的 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 文件底部的一句无关紧要的话——它是一个带有网络使用条款的强 copyleft 许可证，它可能直接影响你是否可以在自托管实例之上构建商业产品。
简而言之：标准 GPL 义务在分发时触发。AGPL 更进一步——网络使用条款意味着通过网络向用户提供软件功能可以被视为需要承担源代码可用性义务的使用类型。如果你将自托管的 Firecrawl 嵌入到你的客户通过互联网访问的服务中，该条款就完全在范围内，而“我们从未发布二进制文件”并非人们想象中的逃避条款。
我不是你的律师，许可证解释取决于你的具体部署方式。但对于任何商业推荐，AGPL-3.0 都是一个首要考虑因素，而不是细则。在你基于它进行构建之前，请与你公司负责许可的人员沟通。标记这一点并非对 Firecrawl 的批评——许多优秀的工具都采用 AGPL 许可证——这只是你需要尽早了解的一个事实。
Thunderbit 的开发者堆栈如何融入
如果你的实际目标是“页面 → LLM 就绪 Markdown”或“页面 → 结构化数据”，并且你不想承担六容器的运营成本和 AGPL 问题，那么这正是 Thunderbit 开发者堆栈所填补的空白。我们拥有超过 10 万扩展用户所使用的相同 AI 引擎，以三种方式暴露给技术工作——而基础设施则由我们负责。
- 开放 API (REST)。
POST /distill将页面转换为干净的、LLM 就绪的 Markdown；POST /extract根据你定义的 JSON Schema 返回结构化数据。JS 渲染、反机器人处理和动态内容都在服务器端处理——你无需运行浏览器容器。renderMode标志（none/basic/full）控制渲染的强度，批量端点可处理多达 100 个 URL 进行蒸馏。 - MCP 服务器。 官方的 Model Context Protocol 服务器，因此 Claude 或 Cursor 中的 AI 代理可以在任务中进行抓取：
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 用于反屏蔽。Thunderbit 的 API/MCP/CLI 则以控制权换取托管引擎，该引擎返回与模式匹配的结构化 JSON——而不仅仅是原始 Markdown——同时将容器、反机器人层和 copyleft 义务从你的肩上卸下。不同的工具适用于不同基础设施需求的用户。
以下是权衡的概览：
| 考量 | Firecrawl 自托管 | Thunderbit 开发者堆栈 (API · MCP · CLI) |
|---|---|---|
| 部署形式 | 你运营的服务（6 个容器） | 你调用的托管 API |
| 启动运行 | 启动一个 6 服务堆栈的 docker compose | API 密钥，然后请求 |
| JS 渲染 | 捆绑的 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 适用于你的部署方式。核心功能是真实的：我从静态页面和 JS 渲染页面都获得了干净、结构化、LLM 就绪的 Markdown，并且整个堆栈都在预构建镜像上运行。
如果你符合以下条件，请寻找其他方案： 你想要一个快速的本地脚本（这是基础中最繁重的设置，没有之一），你需要云级别的反屏蔽功能而不想自己操作（自托管没有 Fire-engine），或者 AGPL 网络使用条款与你的商业计划冲突。对于“我只需要从 URL 获取 Markdown 或结构化数据，而无需运营”的情况，像 Thunderbit 的 /distill 和 /extract 这样的托管 API 可以在没有容器的情况下实现相同的功能。
我的初步解读是：核心功能强大，运营投入巨大，并且许可证在商业构建之前必须明确。它为那些希望拥有整个管道的团队赢得了地位——但对其他人来说，要求很高。一旦我运行了 /v1/crawl，使用 LLM 密钥测试了 /extract，并在非 colima 守护进程上验证了从源代码构建，我将重新审视这一点；这些是介于此和最终裁决之间的未决问题。
尝试 Thunderbit 进行网页数据提取 Get Started Free
常见问题
自托管的 Firecrawl 与云版本相同吗？
不。自托管版本为你提供核心的抓取到 Markdown 引擎和通过捆绑的 playwright-service 进行的 JavaScript 渲染，但它不包括 Fire-engine，即云产品的专有反屏蔽层。像 /extract 端点和 json 输出这样的 AI 功能也需要你自己的 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 的开发者堆栈（开放 API、MCP 服务器、CLI）是一个你调用的托管引擎：POST /distill 用于 Markdown，POST /extract 用于 JSON Schema 结构化数据，JS 渲染和反机器人处理都在服务器端进行，并且你的代码没有 copyleft 义务。Firecrawl 适合希望完全控制基础设施的团队；Thunderbit 适合那些希望获得输出而无需运营负担的团队。
