La mayoría de la gente suele poner a Firecrawl en el mismo saco que las librerías de scraping: esa gente que hace un pip install, escribe un script y listo. Pero, ¡ojo!, esta forma de verlo no es del todo correcta, y entender la diferencia es clave antes de que teclees un solo comando. Firecrawl autoalojado no es una librería que importas; es un servicio que tú mismo gestionas, y para ponerlo en marcha necesitas ejecutar seis contenedores Docker que se comunican entre sí.
Yo mismo probé la pila autoalojada en una Mac (arm64, Docker a través de colima) sin ninguna clave de nube. Apunté su endpoint /v1/scrape a un par de sitios de demostración que son amigables con el scraping y me puse a observar los resultados. En resumen: la promesa principal se cumplió —una página entraba y salía un Markdown limpio listo para LLM— pero la configuración fue la más pesada de todas las herramientas que he probado en esta investigación. Esto es solo un vistazo preliminar, no una calificación definitiva, y seré muy claro sobre lo que probé y lo que no.
Firecrawl es un servicio, no una librería
Lo primero que hay que entender es esto. Las herramientas de scraping a las que la mayoría de los desarrolladores recurren son librerías: añades una dependencia, llamas a una función y obtienes HTML o datos parseados dentro de tu propio proceso. Firecrawl autoalojado es otra cosa. Es una plataforma que está funcionando con su propia API, y te comunicas con ella a través de HTTP.
La descripción oficial es "la API para buscar, raspar e interactuar con la web a escala", y el producto es exactamente eso: páginas de entrada, Markdown limpio o datos estructurados de salida. Cuando lo autoalojas, no estás enlazando con Firecrawl. Estás levantando una pila docker compose y accediendo a un endpoint, igual que accederías a cualquier microservicio interno.
La pila que yo ejecuté tenía seis servicios:
- api — la interfaz HTTP a la que realmente llamas
- playwright-service — un navegador sin interfaz gráfica para renderizar JavaScript
- redis — cola y caché
- rabbitmq — intermediario de mensajes
- nuq-postgres — una variante de Postgres para el estado de los trabajos
- foundationdb — almacenamiento distribuido de clave-valor
Esto es un backend de verdad, no un script de ayuda. Redis, RabbitMQ, Postgres y FoundationDB son infraestructuras de nivel industrial por sí mismas. La ventaja es que Firecrawl se encarga de las partes complicadas del scraping —colas, renderizado, reintentos— detrás de una sola llamada a la API. El costo es que ahora tú eres quien opera esos seis contenedores. Ten en cuenta esa compensación; es el hilo conductor de toda esta reseña.
Como referencia, hice las pruebas con los SDK firecrawl-py 4.32.0 y firecrawl-js 4.30.0, usando la imagen oficial precompilada ghcr.io/firecrawl/firecrawl:latest el 9 de julio de 2026. El repositorio tiene unas 148k estrellas a esa fecha (considera esto como metadatos, no como una puntuación de calidad), bajo una licencia AGPL-3.0 — un detalle al que volveré, porque cambia el cálculo para el uso comercial.
La prueba principal: una página se convierte en Markdown limpio
La razón principal de la existencia de Firecrawl es convertir una página web en Markdown que un LLM pueda leer. Así que eso fue lo primero que comprobé.
Apunté /v1/scrape a books.toscrape.com, un catálogo estático creado específicamente para practicar scraping. El resultado: 9.222 caracteres de Markdown limpio, listo para LLM, con el título de la página All products | Books to Scrape parseado correctamente. No era HTML en bruto volcado en una cadena, sino Markdown estructurado, con encabezados, enlaces y referencias de imágenes intactos. El tipo de salida que podrías insertar directamente en una pipeline de recuperación o alimentar a un modelo sin una segunda pasada de limpieza.
Esta es la principal fortaleza de Firecrawl, y el autoalojado la entregó sin problemas. Si tu trabajo es "dame la sustancia legible de esta página como Markdown", una página estática regresó exactamente como se anunciaba. Eso es una primitiva realmente útil, y es la razón por la que la herramienta tiene el seguimiento que tiene.
Vale la pena ser preciso sobre el alcance: solo probé la ruta /v1/scrape de una sola página. No probé /v1/crawl, el rastreador de varias páginas que recorre un sitio completo. Esa es una capacidad separada con sus propios modos de fallo, y no voy a afirmar que funciona cuando no lo ejecuté.
Páginas JavaScript: el navegador incluido se gana su contenedor
Una página estática es el caso fácil. La pregunta más difícil para cualquier raspador es qué sucede cuando el contenido solo aparece después de que se ejecuta JavaScript, lo cual, en la web moderna, es la mayor parte del tiempo.
Aquí es donde el contenedor playwright-service deja de ser una sobrecarga y empieza a ser el punto clave. Apunté el raspador a quotes.toscrape.com/js/, una versión del sitio de demostración que renderiza sus citas del lado del cliente. Si Firecrawl solo obtuviera el HTML en bruto, las citas no estarían allí, ya que no existen hasta que el navegador ejecuta el script de la página.
El raspado arrojó 1.574 caracteres de Markdown, y la cita de Einstein estaba incluida. Esa cita es contenido posterior a JavaScript: su presencia es prueba de que el playwright-service realmente renderizó la página en un motor de navegador real antes de extraer el texto, en lugar de tomar el shell vacío prerrenderizado.
Así que uno de los seis contenedores es un navegador sin interfaz gráfica, y hace el trabajo para el que lo contratarías. Esa es la justificación concreta de la arquitectura más pesada: no solo estás pagando por contenedores, estás pagando por la capacidad de renderizar páginas con mucho JS sin tener que configurar tu propia automatización del navegador. Para muchos objetivos del mundo real, esa es la diferencia entre una salida utilizable y divs vacíos.
Cuando el objetivo es malo: errores estructurados, sin fallos
Los raspadores pasan una cantidad sorprendente de su vida apuntando a cosas que no funcionan: hosts muertos, URL con errores tipográficos, servidores que se cuelgan. La forma en que una herramienta falla es tan reveladora como la forma en que tiene éxito.
Alimenté la API con un host inválido a propósito. Devolvió un HTTP 500 estructurado y siguió funcionando, sin un rastro de pila vomitado al cliente, sin que se cayera ningún contenedor, sin un proceso colgado. El error regresó como una respuesta limpia sobre la que el llamador puede bifurcar.
Ese es el comportamiento aburrido y correcto que deseas de algo que pondrías en una tubería. Un raspador que entra en pánico ante un objetivo defectuoso es un raspador que no puedes automatizar. Este devolvió un error que puedes capturar y seguir adelante. Solo probé un único caso de error, así que lee esto como "manejó correctamente el único fallo que le lancé", no como una auditoría exhaustiva de resiliencia, pero el único punto de datos fue el resultado correcto.
Realidad de la configuración: la más pesada de la base
Ahora la parte que nadie captura para el tweet de lanzamiento. Firecrawl autoalojado fue, sin exagerar, la configuración más compleja de cualquier herramienta en esta base de investigación, y he configurado muchas de ellas.
Seis contenedores es el costo base. Pero también encontré dos problemas en el camino, y quiero ser exacto sobre de quién fue la culpa, que no fue de Firecrawl, como resultó.
Primer problema: la compilación desde el código fuente. La compilación de las imágenes desde el código fuente falló dentro de mi VM de colima debido a un error de snapshotter de containerd. Esa es una interacción conocida y poco fiable entre la compilación y la capa de almacenamiento de colima, un problema de infraestructura en mi entorno, no un error en Firecrawl. El archivo compose documenta una alternativa: usar las imágenes oficiales precompiladas ghcr.io/firecrawl/* en lugar de compilar localmente. Cambié a esas, y toda la pila se levantó limpiamente. Si estás en un demonio Docker estándar en lugar de colima, es posible que nunca veas esto; lo señalo como una advertencia del entorno, y validar la compilación del colaborador en un demonio limpio está en mi lista de tareas pendientes.
Segundo problema: la protección SSRF. Mis primeros raspados fueron bloqueados por la protección de IP privada / SSRF de Firecrawl. ¿Por qué? La red de colima mapea los nombres de host públicos a direcciones 198.18.x.x, que se encuentran en un rango reservado que Firecrawl trata correctamente como privado, por lo que su capa de seguridad hizo su trabajo y se negó a obtener lo que parecía un objetivo interno. Para evitar esto solo para pruebas locales, configuré ALLOW_LOCAL_WEBHOOKS=true.
Esa bandera se copia y pega en producción y causa incidentes, así que sé exacto sobre lo que es: la protección SSRF es una característica, no un obstáculo. Es lo que evita que un servicio de scraping sea engañado para acceder a tu red interna. La deshabilité porque una peculiaridad del DNS de colima hizo que mis objetivos públicos legítimos parecieran privados dentro de la VM. No desactives la protección SSRF en un despliegue real. Si tomas una nota operativa de esta revisión, toma esa.
Ambos problemas, para decirlo claramente, fueron artefactos de ejecutar Docker a través de colima en una computadora portátil, no defectos en el software. Por otro lado, el peso de la configuración en sí es real y es de Firecrawl por diseño. Esta no es la herramienta a la que recurres cuando quieres un script local rápido; es la herramienta que configuras cuando quieres un servicio de scraping con capacidad de renderizado y estás dispuesto a ejecutar la infraestructura para ello.
Lo que no probé y lo que no hace
Aquí está lo que no cubrí y lo que la herramienta no te ofrece.
El autoalojado no tiene Fire-engine. El producto en la nube de Firecrawl incluye Fire-engine, su capa propietaria anti-bloqueo para superar las defensas de bots. Según el propio SELF_HOST.md del proyecto, las instancias autoalojadas no lo tienen. Así que si te imaginas a Firecrawl autoalojado superando sistemas anti-bot agresivos de forma predeterminada, ajusta la imagen: esa capacidad reside en el nivel de la nube, y no fue parte de lo que ejecuté.
La API en la nube no se probó aquí. No tenía clave de nube, por lo que todo lo anterior es solo la pila autoalojada. El servicio gestionado en la nube, con Fire-engine, escalado alojado y las funciones de IA, es un producto diferente, y no voy a caracterizar su rendimiento desde fuera. Considera cualquier afirmación sobre la nube fuera del alcance de esta revisión.
Las funciones de IA necesitan una clave. El formato de salida estructurada json y el endpoint /extract se basan en un LLM, lo que significa traer una clave de OpenAI o conectar Ollama. Eso pone la elección del modelo en la lista de materiales: antes de comprometerte con una configuración, compara los precios actuales de la API de los proveedores que podrías usar. No ejercí esas rutas, por lo que /extract y la salida json estructurada también se encuentran en la columna de no probados.
Los proxies son una advertencia, no un titular. Firecrawl admite la configuración de proxies, pero lo menciono como una nota al pie deliberadamente: es una opción que puedes activar, no una razón para elegir la herramienta, y el autoalojado sigue careciendo de la capa anti-bloqueo de la nube de todos modos.
AGPL-3.0 es una decisión de cumplimiento real. Esto merece su propio apartado.
La licencia: lee AGPL-3.0 antes de enviar
Firecrawl tiene licencia AGPL-3.0. Eso no es una línea desechable al final de un README, es un copyleft fuerte con una cláusula de uso en red, y puede afectar directamente si puedes construir un producto comercial sobre una instancia autoalojada.
En resumen: las obligaciones estándar de la GPL se activan con la distribución. La AGPL va más allá: la disposición de uso en red significa que ofrecer la funcionalidad del software a los usuarios a través de una red puede considerarse el tipo de uso que conlleva obligaciones de disponibilidad del código fuente. Si estás incrustando Firecrawl autoalojado dentro de un servicio al que tus clientes acceden a través de Internet, esa cláusula está directamente en el ámbito, y "nunca enviamos un binario" no es la escapatoria que la gente asume que es.
No soy tu abogado, y la interpretación de la licencia depende de cómo la implementes exactamente. Pero para cualquier recomendación comercial, AGPL-3.0 es una consideración de primera clase, no letra pequeña. Involucra a quien sea el responsable de las licencias en tu empresa antes de construir sobre ella. Señalar esto no es una crítica a Firecrawl —muchas herramientas excelentes son AGPL— es solo un hecho que debes tener en cuenta desde el principio.
Dónde encaja la pila de desarrollo de Thunderbit
Prueba Thunderbit para la extracción de datos web
Si tu objetivo real es "página → Markdown listo para LLM" o "página → datos estructurados", y el costo operativo de seis contenedores más la cuestión de la AGPL no son cosas que quieras asumir, esa es la brecha exacta para la que está construida la pila de desarrollo de Thunderbit. El mismo motor de IA detrás de nuestros más de 100.000 usuarios de extensiones, expuesto de tres maneras para el trabajo técnico, con la infraestructura mantenida de nuestro lado de la línea.
- API abierta (REST).
POST /distillconvierte una página en Markdown limpio, listo para LLM;POST /extractdevuelve datos estructurados según un esquema JSON que definas. La renderización de JS, el manejo anti-bot y el contenido dinámico se gestionan en el lado del servidor, sin que tengas que ejecutar un contenedor de navegador. Una banderarenderMode(none/basic/full) controla la intensidad de la renderización, y los endpoints por lotes manejan hasta 100 URL para la destilación. - Servidor MCP. Un servidor oficial de Model Context Protocol, para que un agente de IA dentro de Claude o Cursor pueda raspar a mitad de tarea:
thunderbit_suggest_fieldspara planificar una extracción (gratis),thunderbit_distillpara Markdown,thunderbit_extractpara datos estructurados. El agente decide cuándo extraer datos sin salir de su entorno. - CLI.
npx -y @thunderbit/thunderbit-cliejecuta raspados desde la terminal, scripts, CI o cron, sin navegador, sin pila que supervisar. Conéctalo directamente a otras herramientas:thunderbit distill "$URL" -f markdown | claude -p "summarise".
El contraste con Firecrawl autoalojado es claro. Firecrawl autoalojado te da control total y propiedad operativa total: seis contenedores, el peso de la configuración, los términos de la AGPL y sin Fire-engine para anti-bloqueo. La API/MCP/CLI de Thunderbit cambia ese control por un motor alojado que devuelve JSON estructurado que coincide con el esquema, no solo Markdown en bruto, con los contenedores, la capa anti-bot y las obligaciones de copyleft eliminadas de tu plato. Herramientas diferentes para diferentes apetitos de infraestructura.
Aquí está la compensación en una vista:
| Consideración | Firecrawl autoalojado | Pila de desarrollo de Thunderbit (API · MCP · CLI) |
|---|---|---|
| Forma de despliegue | Servicio que operas (6 contenedores) | API alojada a la que llamas |
| Para empezar a funcionar | docker compose levanta una pila de 6 servicios | Clave API, luego solicitud |
| Renderizado JS | playwright-service incluido (tú lo ejecutas) | Lado del servidor, bandera renderMode |
| Salida estructurada | Necesita clave LLM (/extract, json) | POST /extract con esquema JSON |
| Capa anti-bot | Ninguna autoalojada (Fire-engine es solo en la nube) | Gestionada en el lado del servidor |
| Licencia | AGPL-3.0 (copyleft de uso en red) | API comercial, sin copyleft en tu código |
| Mejor cuando | Quieres control total y ejecutarás infraestructura | Quieres Markdown/datos estructurados sin operaciones |
Ninguno es universalmente "mejor". Si ejecutar la plataforma es el objetivo para ti —control total de datos, sin dependencia externa, y AGPL se ajusta a tu situación— Firecrawl autoalojado es una opción capaz y activamente mantenida. Si prefieres hacer una llamada a la API y saltarte la vida de los seis contenedores, esa es la propuesta para la pila de Thunderbit.
Quién debería autoalojar Firecrawl
Elimina el bombo y platillo y la imagen es lo suficientemente clara como para clasificar por necesidad.
Autoaloja Firecrawl si quieres control total sobre tu infraestructura de scraping, te sientes cómodo operando Redis / RabbitMQ / Postgres / FoundationDB en producción, tus necesidades de renderizado justifican el contenedor de playwright-service, y AGPL-3.0 funciona para cómo lo despliegas. La capacidad central es real: obtuve Markdown limpio, estructurado y listo para LLM tanto de una página estática como de una renderizada con JS, y toda la pila se ejecutó en imágenes precompiladas.
Busca en otro lugar si quieres un script local rápido (esta es la configuración más pesada de la base, punto), necesitas anti-bloqueo de grado de nube sin operarlo tú mismo (el autoalojado no tiene Fire-engine), o la cláusula de uso en red de AGPL choca con tus planes comerciales. Para el caso de "solo necesito Markdown o datos estructurados de una URL, sin las operaciones", una API alojada como /distill y /extract de Thunderbit cubre el mismo terreno sin los contenedores.
Mi lectura provisional: núcleo fuerte, compromiso operativo pesado y una licencia que debes aclarar antes de construir comercialmente. Se gana su lugar para los equipos que quieren poseer toda la tubería, y exige mucho a todos los demás. Volveré a esto una vez que haya ejecutado /v1/crawl, ejercido /extract con una clave LLM y validado la compilación desde el código fuente en un demonio que no sea colima; esas son las preguntas abiertas entre esto y un veredicto final.
Prueba Thunderbit para la extracción de datos web Get Started Free
Preguntas frecuentes
¿Es Firecrawl autoalojado lo mismo que la versión en la nube?
No. El autoalojado te ofrece el motor principal de raspado a Markdown y la renderización de JavaScript a través del servicio playwright incluido, pero no incluye Fire-engine, la capa propietaria anti-bloqueo del producto en la nube. Las funciones de IA como el endpoint /extract y la salida json también requieren tu propia clave LLM (OpenAI u Ollama). En esta revisión solo probé la pila autoalojada; la API en la nube estaba fuera de alcance.
¿Cuántos contenedores necesita realmente Firecrawl autoalojado? Seis: api, playwright-service, redis, rabbitmq, nuq-postgres y foundationdb. Es una pila de servicios completa, no un solo binario, por lo que fue la configuración más pesada de cualquier herramienta en esta base de investigación. Planifica la sobrecarga operativa de ejecutar la infraestructura de intermediario de mensajes, caché y base de datos, no solo un script.
¿Puede Firecrawl manejar páginas con mucho JavaScript cuando está autoalojado? Sí, en mis pruebas. El servicio playwright incluido renderiza las páginas en un motor de navegador real antes de la extracción. Lo confirmé en quotes.toscrape.com/js/, donde la cita de Einstein, contenido que solo existe después de que se ejecuta JavaScript, apareció en el Markdown devuelto. Esa capacidad de renderizado es exactamente la razón por la que uno de los seis contenedores es un navegador sin interfaz gráfica.
¿La licencia AGPL-3.0 afecta el uso comercial? Puede hacerlo, y debes tratarlo como una pregunta de primer orden. AGPL-3.0 es un copyleft fuerte con una cláusula de uso en red, lo que significa que ofrecer la funcionalidad del software a los usuarios a través de una red puede conllevar obligaciones de disponibilidad del código fuente, incluso si nunca distribuyes un binario. Si planeas construir un producto comercial sobre una instancia autoalojada, habla con quien maneje las licencias en tu empresa antes de comprometerte. Esta revisión señala la licencia; no es asesoramiento legal.
¿Cuál es la diferencia entre Firecrawl y las herramientas de desarrollo de Thunderbit?
Firecrawl autoalojado es un servicio que operas: seis contenedores que ejecutas tú mismo, con términos AGPL-3.0 y sin capa anti-bloqueo incorporada. La pila de desarrollo de Thunderbit (API abierta, servidor MCP, CLI) es un motor alojado al que llamas: POST /distill para Markdown, POST /extract para datos estructurados con esquema JSON, con renderizado JS y manejo anti-bot en el lado del servidor y sin obligación de copyleft en tu propio código. Firecrawl es adecuado para equipos que desean control total de la infraestructura; Thunderbit es adecuado para aquellos que desean la salida sin la carga operativa.
