The hosted API is the Firecrawl most teams should try first
Firecrawl's v2 API puts search, scraping, site mapping, crawling, batch jobs, and browser interaction behind one service. A caller can ask for markdown, HTML, structured JSON, screenshots, links, images, or page metadata. That is useful when an agent must find a source, render its JavaScript, click into the right state, and return content without your team wiring a search provider to a browser farm and an HTML cleaner.
The quick start is short: create an API key and call the hosted endpoint from Python, JavaScript, curl, or the CLI. The README also lists Go, Java, Elixir, Rust, Ruby, .NET, and PHP SDKs. An MCP server and a Claude Code compatible skill bring the same web access into agent clients. Hosted use is the sensible evaluation path because it tests extraction on your difficult pages before you commit to running Firecrawl's infrastructure.
What happened when we ran it
Our run cloned commit 24b827e into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node.js 22, and no secrets. The repository contained 1,974 files, about 360,140 lines of source, and occupied 53.3 MB. From apps/api, pnpm installed 778 packages in 46 seconds and left 890 MB on disk.
The build failed with exit code 2 after 8 seconds. TypeScript treated pdfResult as unknown in several PDF-engine lines. It also could not resolve @mendable/firecrawl-rs in the Playwright engine and helpers that extract attributes, images, links, and metadata or remove unwanted elements. The log establishes those compiler errors. It does not say whether the Rust-backed package needed another build step, a generated artifact, or a different dependency path.
Vitest exited 1 after 135 seconds. Of 2,457 tests, 2,222 passed, 170 failed, and 65 were skipped. The file summary was 158 failed, 160 passed, and 6 skipped. The final failures came from authenticated v1 end-to-end cases for TLS verification, base64-image removal, waits, screenshots, clicks, writing, key presses, and scrolling. Those names show the affected surface, but the log tail does not prove one shared cause.
The checkout had 31 CI workflow files, a Dockerfile, and monorepo workspaces. Our scan found no top-level tests directory, although the 2,457-test run clearly exercised suites inside the project. A successful 46-second install shows the package graph can resolve in a clean container. The failed compiler step and 170 failed tests mean commit 24b827e did not clear a clean source gate on our box.
Port 3002 opens onto a stateful stack
The source-aligned guide says Compose publishes only the API on port 3002 by default. Behind it sit Firecrawl workers, Playwright, Redis, RabbitMQ, NuQ PostgreSQL, and FoundationDB for an optional queue backend. AI-backed features need OpenAI, a compatible endpoint, or Ollama. The guide recommends keeping USE_DB_AUTHENTICATION=false for the first successful scrape, which is practical for a trusted laptop network and unsafe as a public deployment design.
The checked-in Compose file gives Redis, RabbitMQ, and NuQ PostgreSQL no persistent volumes. Firecrawl tells operators to add authentication, TLS termination, network policy, backups, recovery tests, monitoring, resource limits, scaling triggers, and rollback procedures. That candor is good documentation. It also settles the buying question: the self-host option gives you source and infrastructure control, while transferring availability, job durability, upgrades, capacity, retention, and compliance to your team.
Issue 4653 makes output verification part of the job
Open issue #4653 reports that self-hosted JSON extraction can send a full page to a local model with an 8k to 32k token context, causing Ollama to truncate the instructions and return confident wrong values without a caller warning. Issue #4773 documents a separate Playwright gap: a redirected page's content can be returned without the browser's observed final URL. These are user reports, not failures from our sandbox, but both matter when provenance is part of the product.
Issue #4348 describes an anti-bot waterfall that can repeat until the job timeout on blocked URLs. A reported workaround forces one engine or excludes the URL. Together, the 3 issues argue for application-side checks: retain the requested URL, record the returned URL and source text, reject implausible empty results, bound job time, and compare extracted fields with evidence. Firecrawl reduces the browser work. It cannot decide what level of evidence your application needs.
A June release and a September push tell different parts of the health story
GitHub showed 187,053 stars, 89 open issues, and 415 open pull requests on September 30, 2026. The repository was pushed that day. Its latest tagged release was v2.11.0 from June 19, so the tag alone understates current work. Recent issue updates and same-day pushes show active maintenance, while the large pull request queue tells adopters to pin an exact revision and test it rather than assuming main and a published image move together.
Firecrawl is easiest to recommend as a hosted boundary around an ugly problem. Its API covers enough search, crawl, extraction, and interaction work to save a product team from building several services. The self-hosted edition needs a platform owner and more work than an afternoon with Docker Compose. Our 8-second build failure and 170 failed tests are the release gate to repeat on the exact tag you plan to run.