Phần lớn mọi người hay xếp Firecrawl chung mâm với mấy thư viện scraping — kiểu chỉ cần pip install, viết vài dòng script là chạy. Cách hiểu đó không đúng, và điểm khác biệt này quan trọng ngay từ trước khi bạn gõ lệnh đầu tiên. Firecrawl self-hosted không phải thư viện để import; nó là một dịch vụ bạn phải tự vận hành, và để khởi chạy nó bạn cần chạy sáu container Docker giao tiếp với nhau.
Tôi đã chạy bộ self-hosted này trên Mac (arm64, Docker qua colima) mà không dùng cloud key, trỏ endpoint /v1/scrape vào vài website demo thân thiện với scraping, rồi xem kết quả trả về. Nói ngắn gọn: lời hứa cốt lõi vẫn được giữ đúng — trang web đi vào, Markdown sạch, sẵn sàng cho LLM đi ra — nhưng đây là công cụ nặng nhất trong toàn bộ bộ thử nghiệm mà tôi dùng cho nghiên cứu này. Đây mới là góc nhìn ban đầu, chưa phải kết luận cuối cùng, và tôi sẽ nói rõ những gì mình đã và chưa thử.
Firecrawl Là Dịch Vụ, Không Phải Thư Viện
Điều đầu tiên cần chỉnh lại là cách nghĩ. Các công cụ scraping mà đa số lập trình viên hay dùng thường là thư viện: thêm dependency, gọi hàm, rồi nhận HTML hoặc dữ liệu đã parse ngay trong tiến trình của chính bạn. Firecrawl self-hosted là một “con thú” khác hẳn. Nó là một nền tảng đang chạy với API riêng, và bạn tương tác với nó qua HTTP.
Thông điệp chính thức của sản phẩm là “API để tìm kiếm, scrape và tương tác với web ở quy mô lớn”, và hình thái sản phẩm đúng như vậy — trang web đi vào, Markdown sạch hoặc dữ liệu có cấu trúc đi ra. Khi tự host, bạn không liên kết Firecrawl như một thư viện. Bạn dựng một stack docker compose rồi gọi endpoint, giống như gọi bất kỳ microservice nội bộ nào.
Bộ stack tôi chạy gồm sáu dịch vụ:
- api — lớp HTTP mà bạn thực sự gọi
- playwright-service — trình duyệt headless để render JavaScript
- redis — hàng đợi và cache
- rabbitmq — message broker
- nuq-postgres — một biến thể Postgres cho trạng thái job
- foundationdb — lưu trữ key-value phân tán
Đây là một backend đúng nghĩa, không phải script phụ trợ. Redis, RabbitMQ, Postgres và FoundationDB đều là hạ tầng cấp công nghiệp theo đúng nghĩa. Đổi lại, Firecrawl xử lý những phần rắc rối của scraping — xếp hàng, render, retry — chỉ qua một lần gọi API. Cái giá là giờ đây bạn phải vận hành cả sáu container đó. Hãy giữ trade-off này trong đầu; nó xuyên suốt toàn bộ bài đánh giá này.
Để bạn tham khảo, tôi đã thử với firecrawl-py 4.32.0 và firecrawl-js 4.30.0 SDK, đồng thời kéo image dựng sẵn chính thức ghcr.io/firecrawl/firecrawl:latest vào ngày 2026-07-09. Tính đến ngày đó, repo có khoảng 148k stars (coi như metadata, không phải thước đo chất lượng), và dùng AGPL-3.0 license — chi tiết này tôi sẽ quay lại sau, vì nó ảnh hưởng trực tiếp đến bài toán dùng trong thương mại.
Bài Kiểm Tra Cốt Lõi: Một Trang Web Biến Thành Markdown Sạch
Lý do Firecrawl tồn tại là để biến một trang web thành Markdown mà LLM có thể đọc được. Vì vậy, đó là thứ đầu tiên tôi kiểm tra.
Tôi trỏ /v1/scrape vào books.toscrape.com, một danh mục tĩnh được tạo riêng để thực hành scraping. Kết quả: 9.222 ký tự Markdown sạch, sẵn sàng cho LLM, với tiêu đề trang All products | Books to Scrape được parse chính xác. Không phải HTML thô bị đổ thành chuỗi — mà là Markdown có cấu trúc, giữ nguyên heading, link và tham chiếu ảnh. Loại đầu ra này có thể đưa thẳng vào retrieval pipeline hoặc nạp cho model mà không cần thêm một vòng làm sạch nữa.
Đây là điểm mạnh nổi bật nhất của Firecrawl, và bản self-hosted đã làm được điều đó khá mượt. Nếu nhiệm vụ của bạn là “cho tôi phần nội dung dễ đọc của trang này dưới dạng Markdown”, thì một trang tĩnh đã được trả về đúng như quảng cáo. Đó là một primitive rất hữu ích, và cũng là lý do công cụ này có cộng đồng người dùng như hiện nay.
Cần nói rõ phạm vi: tôi chỉ thử đường dẫn /v1/scrape cho một trang đơn. Tôi không thử /v1/crawl, trình crawler đa trang đi khắp cả site. Đó là một năng lực khác, có những kiểu lỗi riêng, và tôi sẽ không khẳng định nó chạy ổn nếu mình chưa trực tiếp test.
Trang JavaScript: Trình Duyệt Đi Kèm Xứng Đáng Với Container Riêng
Trang tĩnh là case dễ. Câu hỏi khó hơn với bất kỳ scraper nào là: điều gì xảy ra khi nội dung chỉ xuất hiện sau khi JavaScript chạy — mà trên web hiện đại, đó là phần lớn các trang.
Đây là lúc container playwright-service thôi không còn là “gánh nặng” nữa mà trở thành lý do tồn tại. Tôi trỏ scraper vào quotes.toscrape.com/js/, phiên bản demo render quote ở phía client. Nếu Firecrawl chỉ lấy HTML thô, các câu quote sẽ không có ở đó — vì chúng chỉ xuất hiện sau khi trình duyệt thực thi script của trang.
Kết quả scrape trả về 1.574 ký tự Markdown, và trong đó có câu quote của Einstein. Quote này là nội dung xuất hiện sau JavaScript: sự xuất hiện của nó cho thấy playwright-service thực sự render trang trong một engine trình duyệt đầy đủ trước khi trích xuất text, chứ không chỉ lấy cái khung rỗng trước khi render.
Vậy là một trong sáu container chính là trình duyệt headless, và nó làm đúng việc nó được sinh ra để làm. Đó là một lý do rất cụ thể cho kiến trúc nặng hơn: bạn không chỉ trả tiền cho container, mà đang trả tiền cho khả năng render các trang nhiều JavaScript mà không phải tự dựng browser automation. Với rất nhiều mục tiêu thực tế, đây chính là ranh giới giữa đầu ra hữu dụng và một đống div trống.
Khi Mục Tiêu Có Vấn Đề: Lỗi Có Cấu Trúc, Không Sập
Scraper dành rất nhiều thời gian để trỏ vào những thứ không hoạt động — host chết, URL gõ sai, server treo giữa chừng. Cách một công cụ thất bại nói lên nhiều điều không kém gì cách nó thành công.
Tôi cố tình đưa vào API một host không hợp lệ. Nó trả về HTTP 500 có cấu trúc và vẫn tiếp tục chạy — không có stack trace bị nôn ra client, không container nào ngã, không tiến trình treo. Lỗi được trả về gọn gàng để bên gọi có thể rẽ nhánh xử lý.
Đó là kiểu hành vi khá “chán” nhưng đúng, và chính là thứ bạn muốn ở một công cụ sẽ được đưa vào pipeline. Một scraper hoảng loạn khi gặp target lỗi là scraper bạn không thể tự động hóa ổn định. Công cụ này trả lại một lỗi mà bạn có thể bắt và đi tiếp. Tôi chỉ thử một trường hợp lỗi, nên hãy hiểu đây là “xử lý đúng một lỗi tôi ném vào”, chứ không phải bài test độ bền toàn diện — nhưng kết quả của điểm dữ liệu đó là ổn.
Thực Tế Cài Đặt: Mức Độ Nặng Nhất Trong Bộ Thử Nghiệm
Giờ là phần không ai chụp màn hình để đăng tweet ra mắt. Firecrawl self-hosted, nói không ngoa, là bộ cài phức tạp nhất trong toàn bộ nền tảng thử nghiệm này — và tôi đã dựng rất nhiều công cụ như thế.
Sáu container là cái giá nền tảng. Nhưng tôi còn gặp thêm hai vướng mắc trong quá trình khởi chạy, và tôi muốn nói rõ lỗi đó thuộc về ai — hóa ra không phải Firecrawl.
Vướng mắc thứ nhất: build từ source. Việc build image từ source thất bại trong VM colima của tôi do lỗi snapshotter của containerd. Đây là một tương tác bất ổn đã biết giữa quá trình build và lớp lưu trữ của colima — trục trặc hạ tầng trong môi trường của tôi, không phải lỗi của Firecrawl. File compose có ghi một phương án thay thế: dùng các image dựng sẵn chính thức ghcr.io/firecrawl/* thay vì build cục bộ. Tôi chuyển sang cách đó, và toàn bộ stack khởi chạy sạch sẽ. Nếu bạn dùng Docker daemon chuẩn thay vì colima, có thể bạn sẽ không bao giờ gặp lỗi này; tôi ghi nó như một lưu ý môi trường, và việc xác minh build cho contributor trên một daemon sạch vẫn nằm trong danh sách phần chưa kiểm tra của tôi.
Vướng mắc thứ hai: lớp chặn SSRF. Lần scrape đầu tiên của tôi bị Firecrawl chặn bởi cơ chế bảo vệ private-IP / SSRF protection. Tại sao? Vì mạng của colima ánh xạ hostname public sang địa chỉ 198.18.x.x, vốn nằm trong dải dự trữ mà Firecrawl đúng ra xem là private — nên lớp bảo mật của nó làm đúng việc và từ chối lấy một target trông giống nội bộ. Để vượt qua việc này chỉ cho mục đích test local, tôi đặt ALLOW_LOCAL_WEBHOOKS=true.
Flag đó mà bị copy-paste vào production là sẽ gây rối, nên cần nói thật rõ nó là gì: SSRF guard là một tính năng, không phải vật cản. Chính nó giúp dịch vụ scraping không bị lừa đi chạm vào mạng nội bộ của bạn. Tôi tắt nó đi vì một đặc thù DNS của colima khiến các target public hợp lệ của tôi lại trông như private bên trong VM. Đừng tắt SSRF protection trong môi trường triển khai thật. Nếu bạn chỉ nhớ một lưu ý vận hành từ bài này, hãy nhớ lưu ý đó.
Nói thẳng ra, cả hai vướng mắc đều là hệ quả của việc chạy Docker qua colima trên laptop — không phải lỗi của phần mềm. Ngược lại, độ nặng của bộ setup là có thật và nó là chủ ý thiết kế của Firecrawl. Đây không phải công cụ để bạn lôi ra khi muốn một script local thật nhanh; đây là công cụ bạn dựng lên khi muốn một dịch vụ scraping có khả năng render và bạn chấp nhận vận hành hạ tầng cho nó.
Những Gì Tôi Chưa Thử, Và Những Gì Nó Không Làm Được
Đây là những gì tôi chưa bao quát, và cũng là những gì công cụ này không cung cấp.
Self-hosted không có Fire-engine. Sản phẩm cloud của Firecrawl có Fire-engine, lớp chống chặn độc quyền giúp vượt qua phòng thủ bot. Theo chính SELF_HOST.md của dự án, bản self-hosted không có thành phần này. Vì vậy nếu bạn đang nghĩ Firecrawl tự host có thể xuyên qua các hệ thống anti-bot mạnh ngay khi cài xong, hãy chỉnh lại kỳ vọng — tính năng ấy thuộc tier cloud, và không nằm trong phần tôi đã chạy.
API cloud trong bài này chưa được kiểm tra. Tôi không có cloud key, nên toàn bộ nội dung bên trên chỉ là stack self-hosted. Dịch vụ cloud được quản lý — với Fire-engine, hạ tầng scale do họ vận hành và các tính năng AI — là một sản phẩm khác, và tôi sẽ không đánh giá hiệu năng của nó từ bên ngoài. Hãy xem mọi nhận định về cloud là ngoài phạm vi bài đánh giá này.
Tính năng AI cần key. Định dạng đầu ra có cấu trúc json và endpoint /extract dựa vào LLM, nghĩa là bạn phải có OpenAI key hoặc nối với Ollama. Tôi không thử các đường dẫn này, nên /extract và đầu ra json có cấu trúc cũng nằm trong cột chưa kiểm tra.
Proxy là một lưu ý thêm, không phải điểm nổi bật. Firecrawl có hỗ trợ cấu hình proxy, nhưng tôi cố ý chỉ xem nó như một ghi chú cuối trang — đó là một nút bạn có thể chỉnh, chứ không phải lý do để chọn công cụ, và bản self-hosted vẫn không có lớp chống chặn như cloud.
AGPL-3.0 là một quyết định tuân thủ thực sự. Điểm này xứng đáng có một đoạn riêng.
Giấy Phép: Hãy Đọc AGPL-3.0 Trước Khi Triển Khai
Firecrawl được cấp phép theo AGPL-3.0. Đây không phải là câu chữ cho có ở cuối README — đó là copyleft mạnh kèm điều khoản sử dụng qua mạng, và nó có thể ảnh hưởng trực tiếp đến việc bạn có thể xây dựng sản phẩm thương mại dựa trên một instance self-hosted hay không.
Tóm gọn lại: nghĩa vụ của GPL thông thường được kích hoạt khi có phân phối. AGPL đi xa hơn — điều khoản sử dụng qua mạng có nghĩa là việc cung cấp chức năng của phần mềm cho người dùng qua mạng có thể bị tính là dạng sử dụng kéo theo nghĩa vụ cung cấp mã nguồn. Nếu bạn nhúng Firecrawl self-hosted vào một dịch vụ mà khách hàng truy cập qua internet, điều khoản này chắc chắn nằm trong phạm vi, và câu “chúng tôi đâu có phát hành binary” không phải lối thoát như nhiều người tưởng.
Tôi không phải luật sư của bạn, và cách diễn giải giấy phép còn phụ thuộc đúng vào cách bạn triển khai. Nhưng với mọi khuyến nghị thương mại, AGPL-3.0 là vấn đề cần xem xét đầu tiên, không phải phần chữ nhỏ. Hãy trao đổi với người phụ trách license trong công ty trước khi xây dựng trên nó. Nêu ra điều này không phải là chê Firecrawl — rất nhiều công cụ xuất sắc dùng AGPL — mà chỉ là một факт cần đặt lên bàn sớm.
Thunderbit Developer Stack Phù Hợp Ở Đâu
Thử Thunderbit để trích xuất dữ liệu web
Nếu mục tiêu thực sự của bạn là “trang web → Markdown sẵn sàng cho LLM” hoặc “trang web → dữ liệu có cấu trúc”, và bạn không muốn ôm theo chi phí vận hành sáu container cùng câu hỏi về AGPL, thì đó chính là khoảng trống mà Thunderbit developer stack được tạo ra để lấp. Cùng một engine AI đứng sau hơn 100.000 người dùng extension của chúng tôi, được mở ra theo ba cách cho công việc kỹ thuật — trong khi phần hạ tầng được giữ ở phía chúng tôi.
- Open API (REST).
POST /distillbiến một trang thành Markdown sạch, sẵn sàng cho LLM;POST /extracttrả về dữ liệu có cấu trúc dựa trên JSON Schema do bạn định nghĩa. Render JavaScript, xử lý anti-bot và nội dung động đều được xử lý phía server — bạn không phải vận hành browser container nào cả. CờrenderMode(none/basic/full) quyết định mức render, và các endpoint batch xử lý tối đa 100 URL cho distill. - MCP server. Một Model Context Protocol server chính thức, để một AI agent trong Claude hoặc Cursor có thể scrape ngay trong lúc làm việc:
thunderbit_suggest_fieldsđể lên kế hoạch trích xuất (miễn phí),thunderbit_distillđể lấy Markdown,thunderbit_extractđể lấy dữ liệu có cấu trúc. Agent tự quyết định khi nào cần lấy dữ liệu mà không rời khỏi môi trường của nó. - CLI.
npx -y @thunderbit/thunderbit-clichạy scrape từ terminal, script, CI hoặc cron — không cần browser, không cần chăm stack. Bạn có thể pipe thẳng sang công cụ khác:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Sự khác biệt với Firecrawl self-hosted rất rõ ràng. Firecrawl self-hosted cho bạn toàn quyền kiểm soát nhưng cũng trao cho bạn toàn bộ trách nhiệm vận hành: sáu container, gánh nặng thiết lập, điều khoản AGPL, và không có Fire-engine chống chặn. API/MCP/CLI của Thunderbit đánh đổi quyền kiểm soát đó để lấy một engine hosted trả về JSON có cấu trúc khớp schema — không chỉ Markdown thô — trong khi container, lớp chống bot và nghĩa vụ copyleft đều được gỡ khỏi vai bạn. Mỗi công cụ hợp với một mức độ “chịu gánh hạ tầng” khác nhau.
Đây là bức tranh so sánh trong một nhìn:
| Tiêu chí | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Hình thức triển khai | Dịch vụ bạn vận hành (6 containers) | API hosted bạn gọi |
| Để chạy được | docker compose dựng 6 dịch vụ | Có API key rồi gửi request |
| Render JavaScript | playwright-service đi kèm (bạn tự chạy) | Xử lý phía server, qua cờ renderMode |
| Đầu ra có cấu trúc | Cần LLM key (/extract, json) | POST /extract với JSON Schema |
| Lớp chống bot | Không có ở bản self-hosted (Fire-engine chỉ có trên cloud) | Xử lý phía server |
| Giấy phép | AGPL-3.0 (copyleft khi dùng qua mạng) | API thương mại, code của bạn không chịu copyleft |
| Phù hợp nhất khi | Bạn muốn toàn quyền kiểm soát và sẵn sàng vận hành hạ tầng | Bạn muốn Markdown/dữ liệu có cấu trúc mà không phải lo ops |
Không cái nào “tốt hơn” tuyệt đối. Nếu việc vận hành nền tảng chính là mục tiêu của bạn — toàn quyền dữ liệu, không phụ thuộc bên ngoài, và AGPL phù hợp với hoàn cảnh của bạn — thì Firecrawl self-hosted là một lựa chọn mạnh và đang được duy trì tích cực. Nếu bạn chỉ muốn gọi API và bỏ qua cuộc sống sáu container, thì đó là lời hứa của Thunderbit stack.
Ai Thực Sự Nên Tự Host Firecrawl
Bỏ qua mọi lời thổi phồng, bức tranh sẽ khá rõ nếu chia theo nhu cầu.
Nên tự host Firecrawl nếu bạn muốn toàn quyền kiểm soát hạ tầng scraping của mình, bạn thoải mái vận hành Redis / RabbitMQ / Postgres / FoundationDB trong môi trường production, nhu cầu render của bạn đủ lớn để biện minh cho container playwright-service, và AGPL-3.0 phù hợp với cách bạn triển khai. Năng lực cốt lõi là có thật: tôi lấy được Markdown sạch, có cấu trúc, sẵn sàng cho LLM từ cả một trang tĩnh lẫn một trang render bằng JS, và toàn bộ stack chạy được trên image dựng sẵn.
Nên cân nhắc lựa chọn khác nếu bạn muốn một script local thật nhanh (nói thẳng là đây là bộ setup nặng nhất trong toàn bộ base), bạn cần anti-block kiểu cloud mà không muốn tự vận hành nó (self-host không có Fire-engine), hoặc điều khoản network-use của AGPL đụng vào kế hoạch thương mại của bạn. Với trường hợp “tôi chỉ cần Markdown hoặc dữ liệu có cấu trúc từ một URL, không muốn lo ops”, một API hosted như /distill và /extract của Thunderbit sẽ giải quyết cùng bài toán mà không cần container.
Đánh giá tạm thời của tôi: lõi mạnh, gánh vận hành nặng, và một giấy phép bạn phải xử lý xong trước khi xây sản phẩm thương mại. Nó xứng đáng với những team muốn làm chủ toàn bộ pipeline — và cũng đòi hỏi rất nhiều từ những người còn lại. Tôi sẽ xem lại bài này sau khi thử /v1/crawl, dùng /extract với LLM key, và xác minh build từ source trên một daemon không phải colima; đó là những câu hỏi còn mở giữa bài đánh giá này và kết luận cuối cùng.
Thử Thunderbit để trích xuất dữ liệu web Get Started Free
Câu hỏi thường gặp
Firecrawl self-hosted có giống bản cloud không?
Không. Bản self-hosted cung cấp engine cốt lõi để chuyển trang thành Markdown và render JavaScript qua playwright-service đi kèm, nhưng không có Fire-engine — lớp chống chặn độc quyền của sản phẩm cloud. Các tính năng AI như endpoint /extract và đầu ra json cũng cần key LLM riêng của bạn (OpenAI hoặc Ollama). Trong bài đánh giá này, tôi chỉ kiểm tra stack self-hosted; API cloud nằm ngoài phạm vi.
Firecrawl self-hosted thực sự cần bao nhiêu container? Sáu: api, playwright-service, redis, rabbitmq, nuq-postgres và foundationdb. Đây là một stack dịch vụ hoàn chỉnh, không phải một binary đơn lẻ — đó là lý do nó là bộ setup nặng nhất trong toàn bộ nghiên cứu này. Hãy tính đến chi phí vận hành của message broker, cache và cơ sở dữ liệu, chứ không chỉ một script.
Firecrawl có xử lý được các trang phụ thuộc nhiều vào JavaScript khi self-host không? Có, trong thử nghiệm của tôi là như vậy. playwright-service đi kèm render trang trong một engine trình duyệt thật trước khi trích xuất. Tôi đã xác nhận điều này trên quotes.toscrape.com/js/, nơi câu quote của Einstein — nội dung chỉ xuất hiện sau khi JavaScript chạy — hiện ra trong Markdown trả về. Chính khả năng render này là lý do một trong sáu container là trình duyệt headless.
Giấy phép AGPL-3.0 có ảnh hưởng đến việc dùng cho thương mại không? Có thể có, và bạn nên xem đây là câu hỏi hàng đầu. AGPL-3.0 là copyleft mạnh với điều khoản sử dụng qua mạng, nghĩa là việc cung cấp chức năng phần mềm cho người dùng qua mạng có thể kéo theo nghĩa vụ công bố mã nguồn — ngay cả khi bạn không hề phát hành binary. Nếu bạn định xây sản phẩm thương mại trên một instance self-hosted, hãy trao đổi với người phụ trách license trong công ty trước khi chốt. Bài viết này chỉ nêu cảnh báo về giấy phép; không phải tư vấn pháp lý.
Khác biệt giữa Firecrawl và developer tools của Thunderbit là gì?
Firecrawl self-hosted là một dịch vụ bạn vận hành — sáu container do bạn tự chạy, đi kèm điều khoản AGPL-3.0 và không có lớp chống chặn sẵn có. Thunderbit developer stack (Open API, MCP server, CLI) là một engine hosted mà bạn gọi: POST /distill để lấy Markdown, POST /extract để lấy dữ liệu có cấu trúc theo JSON Schema, với render JavaScript và xử lý anti-bot ở phía server, và không có nghĩa vụ copyleft với chính code của bạn. Firecrawl phù hợp với team muốn kiểm soát toàn bộ hạ tầng; Thunderbit phù hợp với người muốn đầu ra mà không phải gánh phần vận hành.
