Firecrawl-Alternativen selbst hosten: Draco und Hound

Was eine selbst gehostete Firecrawl-Alternative leisten muss

Eine selbst gehostete Firecrawl-Alternative hat eine Aufgabe: Sie nimmt eine URL entgegen und gibt die Seite als sauberes Markdown zurück, das ein Agent lesen kann. Die gehosteten APIs rechnen pro Seite ab. Die Kosten steigen daher mit der Anzahl der Seiten, die Ihr Agent abruft. Ein VPS, für den Sie bereits bezahlen, kann dieselbe Arbeit übernehmen. Die Projekte unterscheiden sich vor allem in einer Frage: Muss auf Ihrem System ein Headless Browser (eine echte Browser-Engine ohne Fenster) gestartet werden?

Diese Entscheidung bestimmt den Speicherbedarf, die Kosten pro Seite und welche Seiten leer zurückgegeben werden. Dieser Leitfaden vergleicht Draco, Hound und die selbst gehostete Firecrawl-Version, installiert die ressourcenschonendste Variante in einer festgelegten Version und bindet sie über MCP (model context protocol) an einen Agenten an.

Die vier Projekte und was sie tatsächlich sind

Draco ist eine einzelne, in Rust geschriebene Binärdatei unter der MIT- oder Apache-2.0-Lizenz. Release v0.20.5 wurde am 16. Juli 2026 veröffentlicht. draco scrape <url> gibt Markdown nach stdout aus. draco serve startet einen Daemon, der auf 127.0.0.1:3002 antwortet, dem von Firecrawl verwendeten Port. Das Projekt stellt kein Container-Image bereit und startet keinen Browser.

Firecrawl self-hosted ist die Engine hinter dem gehosteten Produkt und steht unter der AGPL-3.0. Die Datei docker-compose.yaml definiert sieben Services: playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb und foundationdb-init. Damit erhalten Sie die echte Crawl-Warteschlange, müssen dafür aber ein kleines verteiltes System betreiben.

Hound befindet sich im Repository master-fetch und wird als hound-mcp auf PyPI veröffentlicht. Es steht unter der MIT-Lizenz und hatte am 3. August 2026 die Version 13.0.1. Es benötigt Python 3.11 oder neuer. Es ist in erster Linie ein MCP-Server und erst in zweiter Linie ein Fetcher: Zunächst versucht es plain HTTP. Erst wenn dieser Abruf blockiert wird, startet es einen Patchright-Browser.

Trawl wird hier erwähnt, weil es bei der Suche nach den anderen Projekten auftaucht und eine andere Aufgabe erfüllt. Es löst JavaScript-Herausforderungen und CAPTCHAs mit einem Firefox mit angepasstem Fingerprint und dient als Ersatz für FlareSolverr in einem *arr-Medienstack. Es ist kein Markdown-Extractor. Der folgende Abschnitt zur angemessenen Nutzung erklärt, warum diese Unterscheidung darüber entscheidet, ob Trawl überhaupt in Ihren Agent-Stack gehört.

Warum der Browser-Pool kleine VPS-Systeme zum Absturz bringt

Jeder geöffnete Browser-Tab ist ein eigener Renderer-Prozess mit einem eigenen DOM (Document Object Model) und einem eigenen JavaScript-Heap. Der Speicherbedarf steigt daher mit der Anzahl der Seiten, die gleichzeitig geöffnet sind, nicht mit der Anzahl der Seiten, die pro Tag abgerufen werden. Zwei dieser Projekte tragen diese Kosten in ihren eigenen Compose-Dateien ein.

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

Die Firecrawl-Compose-Datei begrenzt den api-Container auf 8 GB und den Playwright-Container auf 4 GB, jeweils mit passenden Swap-Limits. Die Compose-Datei von Hound setzt 3 GB für einen Container fest, der ein gebündeltes Chromium enthält. Das sind von den Projekten gewählte Obergrenzen und veröffentlichte Werte, keine Messungen eines unbelasteten Systems. Redis, RabbitMQ, PostgreSQL und FoundationDB benötigen zusätzlich ihren Anteil über die Firecrawl-Werte hinaus.

Eine Obergrenze, die über dem verfügbaren RAM liegt, bewirkt nichts. Wenn der Arbeitsspeicher des Systems erschöpft ist, beendet der Out-of-Memory-Killer des Kernels einen Prozess. Dadurch verschwindet ein Container aus docker compose ps, ohne dass ein Fehler im Anwendungslog protokolliert wird. Lesen Sie dmesg -T | tail nach jedem Neustart, dessen Ursache Sie nicht erklären können. Planen Sie 8 GB für den vollständigen Firecrawl-Stack ein und betrachten Sie 4 GB als Mindestgröße für ein Testsystem. Das Festlegen der Werte pro Dienst wird unter Speicherlimits in Docker Compose beschrieben.

Ein weiteres Browserdetail kostet häufig einen ganzen Abend. Docker stellt einem Container unter /dev/shm 64 MB Shared Memory bereit. Chromium legt dort Renderer-Puffer ab und stürzt deshalb bei umfangreichen Seiten ab. Beide Browser-Stacks erhöhen diesen Wert: Die Compose-Datei von Hound enthält shm_size: "1gb". Übernehmen Sie diese Zeile in jedes Image, das Sie für Playwright erstellen.

Extraktionsqualität auf JavaScript-lastigen Seiten

Bei statischem HTML, einem serverseitig gerenderten Blog, einer Dokumentationsseite oder einem Nachrichtenartikel liefern alle Tools nahezu identisches Markdown. Dann gewinnt das schnellste Tool. Der Unterschied zeigt sich bei clientseitig gerenderten Seiten. Das ausgelieferte HTML ist dort nur eine leere Hülle. Der Text wird nach dem Laden durch JavaScript eingefügt.

Draco eskaliert stufenweise. Tier 0 und Tier 1 analysieren das HTML vollständig ohne JavaScript. Tier 2 führt das JavaScript der Seite in einem V8-Isolate innerhalb des Prozesses aus. Dabei handelt es sich um die JavaScript-Engine ohne Browserumgebung. Laut README erhält der Seitencode dort keine Bindings für Host-Funktionen. Damit lassen sich viele Single-Page-Anwendungen mit einem Bruchteil des Speicherbedarfs eines Browsers verarbeiten. Wenn Draco auf ein unüberwindbares Hindernis trifft, beendet sich draco scrape mit Exit-Code 3, needs_browser. Prüfen Sie diesen Fall in Skripten. Eine leere Datei mit Exit-Code 0 ist ein Fehler, der den Kontext eines Agents unbemerkt unbrauchbar macht:

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

Der playwright-service von Firecrawl steuert ein echtes Chromium und rendert daher das, was ein Browser rendert. Die selbst gehostete Version ist trotzdem nicht mit dem gehosteten Produkt gleichwertig: Laut Dokumentation haben selbst gehostete Instanzen keinen Zugriff auf Fire Engine. Damit fehlen die Funktionen des Cloud-Dienstes zur Blockierungsvermeidung und IP-Rotation. Außerdem werden die Endpunkte /agent und /browser nicht unterstützt. Hound liegt absichtlich zwischen diesen Ansätzen. Es ruft Inhalte über HTTP ab und eskaliert pro Anfrage. Der aufgewärmte Browser wird nach einem Leerlauf-Timeout beendet, sodass ein wenig ausgelasteter Server nahe an seiner Grundlast bleibt.

Draco mit einer festgelegten Version installieren

Die README dokumentiert ein Installationsskript in einer Zeile. Lesen Sie, was es tut, bevor Sie es an eine Shell weiterleiten: Es installiert nach $HOME/.draco/bin/draco, verwendet immer das Release latest und prüft weder eine Signatur noch einen Hash. Auf einem Server sollten Sie die Version festlegen und den Download verifizieren.

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

Das gibt draco-linux-x86-64.tar.gz: OK aus. Eine Zeile mit FAILED bedeutet, dass die vorliegenden Bytes nicht den vom Projekt veröffentlichten Bytes entsprechen. Löschen Sie sie und beginnen Sie erneut.

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

Der letzte Befehl gibt die Beispielseite als Markdown in deutlich unter einer Sekunde aus. find ist keine Dekoration: Die Struktur des Archivs gehört nicht zum öffentlichen Vertrag des Projekts, und das offizielle Installationsprogramm ermittelt die Binärdatei auf dieselbe Weise.

Führen Sie den Daemon unter einem eigenen Konto aus, nicht unter Ihrem Anmeldekonto. Schreiben Sie /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 antwortet, sobald der Daemon Verbindungen annimmt. Connection refused bedeutet, dass dies nicht der Fall ist. Lesen Sie dann journalctl -u draco -n 50. Die häufigste Ursache ist ein anderer Prozess, der bereits Port 3002 verwendet, da dies auch der Standardport von Firecrawl ist. --port ändert den Port eines der beiden Prozesse. Weitere Informationen zu Unit-Dateien finden Sie unter: systemd-Service-Units und Timer.

Rufen Sie nun die Ressource so ab, wie es Ihr Agent tun wird:

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

Den Fetch-Daemon aus dem öffentlichen Internet heraushalten

Eine Fetch-API ohne Authentifizierung ist ein offener Proxy. Jeder, der den Port erreichen kann, lässt Ihren Server beliebige URLs über Ihre IP-Adresse anfordern. Die Missbrauchsmeldung geht dann an Ihren Provider und nicht an diese Person. Dracos dokumentierte serve-Flags enthalten keinen API-Schlüssel. Der Schutz muss daher über das Netzwerk erfolgen. Verwenden Sie die standardmäßige 127.0.0.1-Bind-Adresse, wenn der Agent auf demselben Rechner läuft. Wenn der Agent auf einem anderen Rechner läuft, verbinden Sie beide Seiten über einen privaten Tunnel. Ein selbst gehostetes WireGuard-VPN ist dafür die übliche Lösung. Binden Sie den Dienst an die Tunneladresse und nicht an 0.0.0.0. Prüfen Sie anschließend von einem anderen Rechner aus, dass die öffentliche IP-Adresse keine Antworten liefert. Grundlagen der ufw-Firewall und Benutzerkonten mit geringsten Berechtigungen behandeln die beiden erforderlichen Aspekte.

Ändert sich der Code Ihres Agenten? API-Kompatibilität in der Praxis

Draco beantwortet die Firecrawl-v1-Routen: /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape und /v1/search. In der README steht außerdem, dass unbekannte Felder akzeptiert und ignoriert werden. Ein Agent, der bereits Anfragen an /v1/scrape sendet, benötigt eine neue Basis-URL und sonst keine Änderungen. Prüfen Sie, was sich auf der anderen Seite geändert hat: Die Self-Hosting-Seite von Firecrawl testet jetzt mit /v2/crawl, und aktuelle SDKs verwenden v2. Ein v2-Client, der auf Draco zeigt, fragt daher eine Route an, die Draco nicht bereitstellt. Testen Sie jeden Aufruf mit curl, bevor Sie den Agent-Code ändern. Lesen Sie außerdem den JSON-Body statt nur den Statuscode, weil sich die Implementierungen vor allem bei den Feldnamen unterscheiden.

Robots.txt, Rate Limits und die Grenze, die Sie einhalten sollten

Draco liest robots.txt standardmäßig aus, und --ignore-robots deaktiviert dieses Verhalten. Firecrawl dokumentiert denselben Standard. Lassen Sie beide Einstellungen unverändert. Legen Sie anschließend Ihre eigene Abrufrate fest: --delay fügt zwischen den Anfragen eine Wartezeit in Millisekunden ein, und --max-concurrency begrenzt die Anzahl paralleler Aufträge. Der Standardwert des Daemons ist 8. Zwei bis vier sind bei einer gemeinsam genutzten VPS-Verbindung schonender und insgesamt selten langsamer, weil eine Website, die für Sie Rate Limits aktiviert, mehr Zeit kostet als durch die zusätzliche Parallelität eingespart wird. Zwischenspeichern Sie die abgerufenen Daten, damit ein zweiter Agentenlauf keine zusätzliche Last für die Quelle erzeugt. Das ist außerdem der günstigste Kostenpunkt bei der Kontrolle der Kosten eines AI-Agenten.

Challenge-Seiten sind ein separates Thema, und Trawl wurde genau dafür entwickelt: Cloudflare Turnstile, reCAPTCHA, hCaptcha und GeeTest. Eine Challenge-Seite verweigert automatisierten Datenverkehr ausdrücklich. Sie zu umgehen, verstößt gegen die Nutzungsbedingungen der Website und an manchen Orten auch gegen das Gesetz. Dieser Leitfaden behandelt daher die Infrastruktur zum Abrufen von Daten und geht nicht darüber hinaus. Dieselben Techniken, mit denen eine Challenge-Seite überwunden wird, erkennen und blockieren Websitebetreiber. Eine darauf basierende Pipeline ist deshalb sowohl instabil als auch unangebracht. Wenn eine Quelle so wichtig ist, suchen Sie nach ihrem RSS-Feed, ihrer öffentlichen API oder einem Bulk-Export. Jede dieser Optionen ist im Betrieb günstiger, und keine davon fällt aus, sobald die Website ihre Challenge-Seite ändert.

Binden Sie über MCP einen Agenten an

MCP (Model Context Protocol) ist die Schnittstelle, über die ein Agent ein Tool aufruft. Welche Tools das Modell überhaupt erreichen und ob es eines ohne vorherige Rückfrage bei Ihnen aufrufen darf, wird eine Ebene höher durch die Harness-Umgebung bestimmt, in der das Modell ausgeführt wird. Daher ist es nur die halbe Konfiguration, den Daemon auf Verbindungen warten zu lassen. Draco enthält im selben Binary einen MCP-Server, der über stdio kommuniziert:

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

Die Tools erscheinen beim Agenten anschließend als draco_scrape, draco_search und als Satz draco_interact_*. Stdio funktioniert nur, wenn der Agent-Prozess und die Binärdatei auf demselben Rechner liegen, weil der Transport die Standardeingabe dieses Prozesses verwendet. Für einen Agenten auf einem anderen Host stellt Hound MCP stattdessen über HTTP bereit: hound --http --host 127.0.0.1 --port 8765 veröffentlicht einen Endpunkt unter http://127.0.0.1:8765/mcp, den Sie über den Tunnel erreichen. Die Auswahl des Transports und die Festlegung, was veröffentlicht werden soll, werden unter MCP-Server auf einem VPS betreiben beschrieben.

Paare mit der Suche abrufen. Ein Agent, der nur Inhalte abrufen kann, wartet darauf, dass Sie ihm URLs vorgeben. Ergänzen Sie eine selbst gehostete SearXNG-Suchinstanz, kann er die URLs selbst finden. Das entspricht dem Browser-Suchskill auf Basis von SearXNG. Sobald der Daemon läuft, steht er als gemeinsamer Dienst für jeden der von Ihnen betriebenen selbst gehosteten KI-Agenten zur Verfügung. Wenn Sie sich bei der Agentenseite am unsichersten sind, wird durch das manuelle Schreiben einer kleinen Agentenschleife als ersten Schritt deutlich, an welcher Stelle ein Fetch-Tool eingebunden wird und wie das Modell das zurückgegebene Markdown verarbeitet.

FAQ

Benötige ich einen Headless-Browser, um Seiten für einen KI-Agenten abzurufen?

Für die meisten Seiten nicht. Serverseitig gerenderte Dokumentationen, Blogs und Nachrichtenartikel werden mit einem einfachen HTTP-Abruf und einer anschließenden Umwandlung von HTML in Markdown vollständig geladen. Genau das macht Draco in seinen niedrigeren Tarifen nach eigenen Angaben mit etwa 300 ms pro Seite und ohne Browser. Bei clientseitig gerenderten Anwendungen lohnt sich der Speicherverbrauch eines Browsers, weil das gelieferte HTML dort nur ein leeres Grundgerüst ist. Dracos V8-Isolate deckt einen großen Teil dieses Zwischenbereichs ohne Browserprozess ab. Wenn das nicht möglich ist, beendet es sich mit Exit-Code 3, needs_browser.

Wie viel RAM benötigt selbst gehostetes Firecrawl auf einem VPS?

Die Compose-Datei setzt für den api-Container ein Limit von 8 GB und für den Playwright-Container ein Limit von 4 GB. Derselbe Stack startet außerdem Redis, RabbitMQ, PostgreSQL und FoundationDB. Planen Sie 8 GB ein. Auf einem System mit 2 GB beendet der Out-of-Memory-Killer des Kernels unter Last Container. Das erste Anzeichen ist ein neu gestarteter Container in docker compose ps, während das Anwendungs-Log keine verwertbare Meldung enthält. Bestätigen Sie den Speichermangel mit dmesg -T | tail.

Ist Draco ein direkter Ersatz für die Firecrawl API?

Für die v1-Endpunkte ist Draco weitgehend kompatibel. Es stellt /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape und /v1/search bereit. Unbekannte Request-Felder werden ignoriert. Ein Client, der für Firecrawl v1 geschrieben wurde, benötigt daher normalerweise nur eine neue Basis-URL. Draco ist nicht das gehostete Produkt. Dahinter steht kein verwalteter Proxy-Pool, und die neueren v2-Routen von Firecrawl gehören nicht zur unterstützten Oberfläche. Prüfen Sie zuerst jeden Aufruf, den Ihr Agent ausführt, mit curl.

Bedeutet das Self-Hosting eines Scrapers, dass ich robots.txt ignorieren kann?

Nein. Der Ausführungsort des Codes ändert nichts daran, was eine Website veröffentlicht hat oder welche Nutzung ihre Bedingungen erlauben. Draco und Firecrawl beachten robots.txt standardmäßig. Das Override-Flag ist für Websites vorgesehen, die Ihnen gehören oder für die Sie eine schriftliche Crawling-Erlaubnis haben. Ratenlimits gelten unabhängig davon am Zielsystem. Ein höfliches --delay mit niedriger Parallelität sorgt daher dafür, dass Ihre IP-Adresse weiter funktioniert. Ein Stack, der nur durch das Umgehen einer Challenge-Sperre funktioniert, fällt ohne Vorwarnung aus.