Seven web jobs sit behind one API
Firecrawl's v2 interface covers search, scraping, interaction, agents, crawling, site mapping, and batch scraping. A caller can request markdown, HTML, structured JSON, screenshots, links, images, or metadata. That is a useful boundary when an agent must find a source, render JavaScript, click into the right state, and return cleaned content without the product team assembling a search provider, browser farm, queue, and HTML cleaner.
The hosted quick start asks for an API key and works through Python, Node.js, curl, or the CLI. The README also lists Go, Java, Elixir, Rust, Ruby, .NET, and PHP SDKs. Firecrawl supplies an MCP server and a skill that works with Claude Code. The breadth is convenient, but each extra format and interaction becomes another behavior to validate against the sites your product depends on.
What happened when we ran it
Our sandbox installed commit b5d187b from apps/api in 87 seconds. Pnpm pulled 778 packages and occupied 890 MB. The checkout contained 1,975 files, roughly 360,445 lines of source, and used 53.3 MB before dependencies. This was a fresh Debian container with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. Installation was the only step that passed.
The build exited 2 after 11 seconds. TypeScript reported several PDF-engine lines where pdfResult had type unknown. It also could not find @mendable/firecrawl-rs or its declarations in the Playwright engine and helpers for attributes, images, links, metadata, and unwanted elements. The log shows those compiler failures. It does not tell us whether another generation step, package build, or dependency arrangement would resolve them.
Vitest exited 1 after 116 seconds. It counted 2,228 passing tests, 170 failures, and 65 skipped tests out of 2,463. The file summary was 158 failed, 160 passed, and 6 skipped across 324 files. The final lines named authenticated v0 end-to-end cases around search, crawl status, cancellation, and LLM extraction. Those names identify the affected routes, but the tail does not prove why all 170 failed.
The repository has 31 CI workflow files, a Dockerfile, and monorepo workspaces. Our scan found no top-level tests directory, although the Vitest run clearly found suites under apps/api. A resolved 778-package graph is useful. It is still weaker evidence than a compiler and test suite that finish cleanly, and commit b5d187b did not meet that bar in our sandbox.
Port 3002 fronts a stateful self-hosted stack
The source-aligned guide says Compose publishes the API on port 3002. Behind it run Firecrawl API workers, Playwright, Redis, RabbitMQ, and NuQ PostgreSQL. FoundationDB is available as an optional queue backend. AI-backed features need OpenAI, an OpenAI-compatible endpoint, or Ollama. This is a platform with several failure and persistence boundaries, rather than a scraper packed into one process.
The first-run advice keeps USE_DB_AUTHENTICATION=false until the required schema and application configuration exist. Firecrawl then places authentication, TLS termination, network policy, backups, recovery tests, monitoring, limits, scaling, and rollback on the operator. The checked-in Compose file defines no persistent volumes for PostgreSQL, Redis, or RabbitMQ. That is honest documentation and a warning against treating docker compose up as a finished public deployment.
Open issue 4653 shows why JSON needs source checks
Issue 4653 reports that self-hosted JSON extraction can send a full page to a local model with an 8k to 32k token context. In the supplied reproduction, Ollama truncated the prompt and returned confident wrong fields without warning the caller. This is a user report, separate from our 2,463-test run. It still describes a serious failure mode for anyone storing extracted facts without the source text that produced them.
Issue 4773 documents another evidence gap: the self-hosted Playwright service followed a redirect and returned the destination content, but omitted the final observed URL. Issue 4348 reports an anti-bot waterfall that can repeat until timeout on a blocked page. All 3 issues were open when checked. Retain requested and returned URLs, bound job time, reject implausible empty output, and compare important structured fields with page evidence.
AGPL-3.0 covers the server, while SDK terms differ
The repository is primarily AGPL-3.0. Its README says SDKs and some interface components use MIT licenses, with directory-level license files defining the details. That split matters if you modify the server and make it available over a network. A commercial team should review the exact directories it will deploy and understand the corresponding source-sharing obligations before choosing self-hosting.
The hosted and self-hosted products are not identical. Firecrawl says the cloud edition includes additional features, while the source guide gives operators control over infrastructure and data. Hosted use shifts browsers, proxy operations, queues, availability, and upgrades to Firecrawl. Self-hosting gives you more control but returns every one of those responsibilities, plus compliance with websites' policies and the project's license.
187,301 stars accompany same-day code activity
GitHub showed 187,301 stars and a push on October 1, 2026. Its combined open counter was 505; separate searches split that into 89 issues and 416 pull requests, so 505 is not a bug count. The latest tagged release was v2.11.0 from June 19, while the October push and recent issue updates show work continued after that tag. Pin the exact source or image you test instead of reading release age as abandonment.
Firecrawl is easiest to recommend as a hosted boundary around an unpleasant engineering problem. Test it on the JavaScript-heavy, redirected, blocked, and long pages your product actually needs. The source edition deserves a platform owner, an AGPL review, and a repeat of the build and 2,463-test gate on the chosen revision. Our failed run makes that proof a requirement, not a paperwork step.