Alternatives à Firecrawl auto-hébergées sur un VPS

Ce qu’une alternative à Firecrawl auto-hébergée doit faire

Une alternative à Firecrawl auto-hébergée a une seule fonction : recevoir une URL et renvoyer le contenu de la page sous forme de markdown propre qu’un agent peut lire. Les API hébergées facturent chaque page. La facture augmente donc avec la curiosité de votre agent. Un VPS que vous payez déjà peut effectuer le même travail. Les projets se distinguent sur un point : faut-il démarrer un navigateur headless (un véritable moteur de navigateur exécuté sans fenêtre) sur votre serveur ?

Cette réponse détermine l’empreinte mémoire, le coût de chaque page et les pages qui reviennent vides. Ce guide compare Draco, Hound et la version auto-hébergée de Firecrawl, installe la solution la plus légère à une version épinglée et la connecte à un agent via MCP (model context protocol).

Les quatre projets et ce qu’ils sont réellement

Draco est un binaire unique, écrit en Rust et distribué sous licence MIT ou Apache-2.0. La version v0.20.5 est sortie le 16 juillet 2026. draco scrape <url> écrit du markdown sur stdout. draco serve lance un daemon qui répond sur 127.0.0.1:3002, le port utilisé par Firecrawl. Il ne fournit aucune image de conteneur et ne démarre aucun navigateur.

Firecrawl self-hosted est le moteur du produit hébergé, sous licence AGPL-3.0. Son fichier docker-compose.yaml définit sept services : playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb et foundationdb-init. Vous disposez de la véritable file d’attente de crawl, au prix de l’exploitation d’un petit système distribué.

Hound se trouve dans le dépôt master-fetch et est publié sur PyPI sous le nom hound-mcp, sous licence MIT, en version 13.0.1 au 3 août 2026. Il nécessite Python 3.11 ou une version ultérieure. C’est avant tout un serveur MCP et, en second lieu, un fetcher : il essaie d’abord HTTP, puis démarre un navigateur Patchright uniquement lorsque la requête HTTP simple est bloquée.

Trawl est mentionné ici parce que les utilisateurs le rencontrent en recherchant les autres projets, mais il remplit une fonction différente. Il résout les challenges JavaScript et les CAPTCHA avec un Firefox dont l’empreinte est modifiée, en remplacement de FlareSolverr dans une stack média *arr. Ce n’est pas un extracteur de markdown. La section consacrée aux bonnes pratiques ci-dessous explique pourquoi cette distinction détermine s’il a réellement sa place dans votre stack d’agents.

Pourquoi le pool de navigateurs met à genoux les petits VPS

Chaque onglet de navigateur ouvert correspond à un processus de rendu distinct, qui conserve son propre DOM (document object model) et son propre tas JavaScript. La mémoire évolue donc selon le nombre de pages ouvertes au même moment, et non selon le nombre de pages récupérées par jour. Les fichiers compose de deux de ces projets inscrivent cette contrainte dans leur configuration.

[
  {
    "label": "Firecrawl api",
    "memory_limit_gb": 8
  },
  {
    "label": "Firecrawl playwright",
    "memory_limit_gb": 4
  },
  {
    "label": "Hound (browser included)",
    "memory_limit_gb": 3
  }
]

Le fichier compose de Firecrawl limite le conteneur api à 8 Go et le conteneur Playwright à 4 Go, avec des limites de swap correspondantes. Le fichier compose de Hound définit 3 Go pour un conteneur qui embarque Chromium. Il s’agit de plafonds choisis par les projets et publiés comme repères, pas de mesures effectuées sur un système inactif. Redis, RabbitMQ, PostgreSQL et FoundationDB ont encore besoin de leur part en plus des valeurs indiquées pour Firecrawl.

Un plafond supérieur à la quantité de RAM dont vous disposez ne sert à rien. Lorsque la machine n’a plus de mémoire, le tueur de processus out-of-memory du kernel en termine un, et le conteneur disparaît de docker compose ps sans qu’aucune erreur soit écrite dans le journal de l’application. Consultez dmesg -T | tail après tout redémarrage dont vous ne pouvez pas expliquer la cause. Prévoyez 8 Go pour la stack Firecrawl complète et considérez 4 Go comme le minimum pour une machine de test. La définition des valeurs par service est expliquée dans les limites mémoire dans Docker Compose.

Un autre détail lié au navigateur peut vous faire perdre une soirée. Docker fournit 64 Mo de mémoire partagée à un conteneur dans /dev/shm, et Chromium y place les buffers des processus de rendu. Les pages lourdes provoquent donc des crashes. Les deux stacks de navigateur augmentent cette valeur : le fichier compose de Hound contient shm_size: "1gb". Copiez cette ligne dans toute image que vous construisez autour de Playwright.

Qualité de l’extraction sur les pages riches en JavaScript

Sur du HTML statique, un blog rendu côté serveur, une page de documentation ou un article d’actualité renvoient tous un Markdown presque identique, et le plus rapide l’emporte. La différence apparaît sur les pages rendues côté client : le HTML transmis est une coquille vide et le texte arrive depuis JavaScript après le chargement.

Draco augmente progressivement le niveau d’exécution. Les niveaux 0 et 1 analysent le HTML sans exécuter JavaScript. Le niveau 2 exécute le JavaScript de la page dans un isolate V8 intégré au processus. Il s’agit du moteur JavaScript, sans navigateur autour de lui, et le README précise que le code de la page n’y dispose d’aucun binding vers les capacités de l’hôte. Cela couvre de nombreuses applications monopages pour une fraction de la mémoire utilisée par un navigateur. Lorsque Draco rencontre un obstacle qu’il ne peut pas franchir, draco scrape quitte avec le code 3, needs_browser. Vérifiez ce comportement dans vos scripts : un fichier vide avec un code de sortie égal à zéro est l’échec qui pollue discrètement le contexte d’un agent :

draco scrape https://example.com > page.md
echo "exit=$?"

Le service playwright-service de Firecrawl pilote un véritable Chromium et restitue donc ce qu’un navigateur restitue. La version auto-hébergée n’est toutefois pas le produit hébergé : la documentation précise que les instances auto-hébergées n’ont pas accès à Fire Engine. Elles ne disposent donc ni des mécanismes anti-blocage ni de la rotation d’adresses IP du service cloud, et les endpoints /agent et /browser ne sont pas pris en charge. Hound se situe volontairement entre les deux. Il récupère les pages via HTTP et augmente le niveau d’exécution selon chaque requête. Son navigateur reste actif jusqu’à l’expiration d’un délai d’inactivité, de sorte qu’une machine peu sollicitée reste proche de sa consommation de référence.

Installer Draco avec une version figée

Le README documente un installateur en une ligne. Examinez ce qu’il fait avant de l’envoyer à un shell : il installe dans $HOME/.draco/bin/draco, utilise toujours la release latest et ne vérifie ni signature ni hash. Sur un serveur, figez la version et vérifiez le téléchargement.

cd /tmp
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/draco-linux-x86-64.tar.gz
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS

Cette commande affiche draco-linux-x86-64.tar.gz: OK. Une ligne FAILED signifie que les octets que vous avez reçus ne correspondent pas à ceux publiés par le projet. Supprimez-les et recommencez.

mkdir -p draco-v0.20.5
tar -xzf draco-linux-x86-64.tar.gz -C draco-v0.20.5
sudo install -m 755 "$(find draco-v0.20.5 -type f -name draco | head -n1)" /usr/local/bin/draco
draco scrape https://example.com

La dernière commande affiche la page d’exemple au format Markdown en nettement moins d’une seconde. Le find n’est pas décoratif : la structure de l’archive ne fait pas partie du contrat public du projet, et l’installateur officiel localise le binaire de la même manière.

Exécutez le daemon avec son propre compte plutôt qu’avec votre compte de connexion. Écrivez /etc/systemd/system/draco.service :

[Unit]
Description=Draco fetch daemon
After=network-online.target
Wants=network-online.target

[Service]
User=draco
ExecStart=/usr/local/bin/draco serve --host 127.0.0.1 --port 3002 --max-concurrency 4
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo useradd --system --no-create-home --shell /usr/sbin/nologin draco
sudo systemctl daemon-reload
sudo systemctl enable --now draco
curl -s http://127.0.0.1:3002/health

/health répond dès que le daemon est en écoute. Connection refused signifie qu’il ne l’est pas ; consultez donc journalctl -u draco -n 50. La cause habituelle est qu’un autre processus utilise déjà le port 3002, qui est également le port par défaut de Firecrawl. --port modifie l’un ou l’autre. Pour aller plus loin sur les unit files : unités et timers de service systemd.

Récupérez maintenant les données comme le fera votre agent :

curl -X POST http://127.0.0.1:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

Désactivez le daemon de fetch sur Internet

Une API de fetch sans authentification est un proxy ouvert. Toute personne qui peut atteindre le port peut faire demander n’importe quelle URL à votre serveur depuis votre adresse IP. Le signalement d’abus sera envoyé à votre fournisseur, pas à cette personne. Les serve flags documentés de Draco n’incluent pas de clé d’API. La protection doit donc être assurée par le réseau. Conservez le bind 127.0.0.1 par défaut lorsque l’agent s’exécute sur le même serveur. Lorsque l’agent se trouve ailleurs, reliez les deux extrémités par un tunnel privé. Un VPN WireGuard que vous hébergez vous-même est généralement la solution retenue. Faites ensuite écouter le service sur l’adresse du tunnel plutôt que sur 0.0.0.0. Vérifiez depuis une autre machine que l’adresse IP publique ne répond à aucune requête. Les bases du firewall ufw et les comptes utilisateur avec le principe du moindre privilège couvrent les deux volets.

Le code de votre agent doit-il changer ? Compatibilité des API en pratique

Draco répond aux routes Firecrawl v1 : /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape et /v1/search, et son README précise que les champs inconnus sont acceptés et ignorés. Un agent qui envoie déjà des requêtes vers /v1/scrape a seulement besoin d’une nouvelle URL de base. Surveillez ce qui a changé de l’autre côté : la page officielle d’auto-hébergement de Firecrawl utilise désormais /v2/crawl pour ses tests, et les SDK actuels parlent v2. Un client v2 configuré pour utiliser Draco demande donc une route que Draco ne publie pas. Testez chaque appel avec curl avant de modifier le code de l’agent, et lisez le corps JSON plutôt que le code d’état, car ce sont les noms de champs qui diffèrent entre ces implémentations.

Robots.txt, limites de débit et seuil à ne pas dépasser

Draco lit robots.txt par défaut, et --ignore-robots désactive ce comportement. Firecrawl documente le même paramétrage par défaut. Ne modifiez ni l’un ni l’autre. Définissez ensuite votre propre cadence : --delay insère un délai en millisecondes entre les requêtes et --max-concurrency limite le nombre de tâches parallèles, avec 8 comme valeur par défaut du daemon. Une valeur de 2 à 4 est plus adaptée à une liaison VPS partagée et ralentit rarement l’ensemble du traitement, car un site qui commence à appliquer des limites de débit vous fait perdre plus de temps que la concurrence n’en fait gagner. Mettez en cache les données récupérées afin qu’une deuxième exécution de l’agent ne sollicite pas davantage la source. C’est aussi le poste de dépense le moins coûteux dans la maîtrise du coût d’un agent IA.

Les pages de challenge constituent un sujet distinct, et Trawl est conçu précisément pour cela : Cloudflare Turnstile, reCAPTCHA, hCaptcha et GeeTest. Une page de challenge signifie simplement qu’un site refuse le trafic automatisé. La contourner vous expose à une violation des conditions d’utilisation du site et, dans certains endroits, de la loi. Ce guide se limite donc à l’infrastructure de récupération. Les mêmes techniques qui permettent de franchir une page de challenge sont celles que les propriétaires de sites surveillent et bloquent, ce qui rend les pipelines qui en dépendent fragiles et inappropriés. Lorsqu’une source est aussi importante, recherchez son flux RSS, son API publique ou un export en volume. Ces solutions sont moins coûteuses à exploiter et aucune ne cesse de fonctionner la semaine où la page de challenge est modifiée.

Connecter l’agent via MCP

MCP (model context protocol) est l’interface qu’un agent utilise pour appeler un outil. Les outils qui peuvent atteindre le modèle, ainsi que ceux qu’il est autorisé à appeler sans vous demander confirmation, sont déterminés un niveau plus haut par le harness dans lequel le modèle s’exécute. Faire écouter le daemon n’est donc que la moitié du raccordement. Draco intègre un serveur MCP dans le même binaire, via stdio :

{ "mcpServers": { "draco": { "command": "draco", "args": ["mcp"] } } }

Les outils apparaissent alors dans l’agent sous la forme de draco_scrape, draco_search et de l’ensemble draco_interact_*. Stdio ne fonctionne que lorsque le processus de l’agent et le binaire se trouvent sur la même machine, car le transport utilise l’entrée standard de ce processus. Pour un agent exécuté sur un autre hôte, Hound sert MCP via HTTP : hound --http --host 127.0.0.1 --port 8765 publie un endpoint à l’adresse http://127.0.0.1:8765/mcp, accessible via le tunnel. Les choix de transport et les éléments à exposer sont décrits dans exécuter des serveurs MCP sur un VPS.

Récupérer des pages avec un moteur de recherche. Un agent qui peut uniquement récupérer des pages attend que vous lui fournissiez les URL. Ajoutez une instance SearXNG auto-hébergée pour qu’il puisse les trouver lui-même, selon le même principe que la compétence de recherche dans un navigateur basée sur SearXNG. Une fois le daemon démarré, il s’agit d’un service partagé par les différents agents IA auto-hébergés que vous exécutez. Si la partie agent est celle que vous maîtrisez le moins, écrire d’abord manuellement une petite boucle d’agent permet de voir clairement où un outil de récupération s’intègre et ce que le modèle fait du markdown qu’il reçoit.

FAQ

Ai-je besoin d’un navigateur headless pour récupérer des pages pour un agent IA ?

Pas pour la plupart des pages. La documentation générée côté serveur, les blogs et les articles d’actualité sont renvoyés complets avec une simple requête HTTP suivie d’une conversion HTML vers Markdown. C’est ce que fait Draco dans ses niveaux inférieurs, à environ 300 ms par page sans navigateur, selon les chiffres du projet. Un navigateur consomme davantage de mémoire pour les applications dont le rendu est effectué côté client, lorsque le HTML fourni n’est qu’une coquille vide. L’isolate V8 de Draco couvre une grande partie de ces cas sans processus de navigateur. Il se termine avec le code 3, needs_browser, lorsqu’il n’y parvient pas.

De combien de RAM Firecrawl auto-hébergé a-t-il besoin sur un VPS ?

Son fichier compose définit une limite de 8 Go pour le conteneur api et de 4 Go pour le conteneur Playwright. La même stack démarre également Redis, RabbitMQ, PostgreSQL et FoundationDB. Prévoyez 8 Go. Sur une machine de 2 Go, le tueur out-of-memory du kernel supprime des conteneurs sous charge. Le premier signe est un conteneur redémarré dans docker compose ps, sans information utile dans le journal de l’application. Confirmez-le avec dmesg -T | tail.

Draco est-il un remplacement direct de l’API Firecrawl ?

Pour les endpoints v1, il s’en approche. Il fournit /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape et /v1/search. Il ignore les champs de requête qu’il ne connaît pas. Un client écrit pour Firecrawl v1 nécessite donc généralement uniquement une nouvelle URL de base. Draco n’est pas le produit hébergé : aucun pool de proxy géré ne se trouve derrière lui, et les nouvelles routes v2 de Firecrawl n’en font pas partie. Vérifiez d’abord chaque appel effectué par votre agent avec curl.

L’auto-hébergement d’un scraper permet-il d’ignorer robots.txt ?

Non. L’endroit où le code s’exécute ne change rien à ce qu’un site a publié ni à ce que ses conditions autorisent. Draco et Firecrawl respectent tous deux robots.txt par défaut. Le flag de contournement est prévu pour les sites que vous possédez ou pour lesquels vous avez obtenu une autorisation écrite d’exploration. Les limites de débit sont appliquées par le site distant dans tous les cas. Un --delay prudent avec une faible concurrence permet donc de conserver une adresse IP fonctionnelle. Une stack qui ne fonctionne qu’en contournant une page de challenge finit par tomber en panne sans avertissement.