SearXNG + Crawl4AI: Warum wir keine APIs mehr mieten

Die Überraschung: Self-Hosting ist nicht automatisch billiger

Wir dachten, wir würden Geld sparen. Statt monatlich vierstellig für SerpAPI und Firecrawl zu zahlen, haben wir unsere Research-Infrastruktur auf SearXNG und Crawl4AI umgestellt. Beide Tools laufen auf unseren eigenen Servern, beide sind Open Source, beide kosten null Euro Lizenzgebühren. Die Rechnung schien trivial: Hardware-Kosten amortisieren sich in drei Monaten, danach sind wir im Plus.

Spoiler: Nach sechs Wochen Betrieb haben wir zwar die API-Rechnungen gestrichen, aber die Gesamtkosten sind nicht gesunken. Was wir gewonnen haben, ist etwas anderes: Kontrolle über Datenflüsse, keine Rate-Limits mehr und die Gewissheit, dass kein Drittanbieter morgen seine Preise verdoppelt oder seinen Service einstellt. Für unsere DACH-Kunden, die DSGVO-Posture ernst nehmen, ist das mehr wert als die gesparten Euro. Aber ehrlich: Wer nur auf den Preis schaut, wird enttäuscht.

Das Problem: API-Rechnungen und Vendor-Lock-in

Unsere beiden Sourcing-Workflows, die Marktforschung und Content-Recherche automatisieren, haben sich auf zwei kostenpflichtige Services verlassen: SerpAPI für strukturierte Google-Ergebnisse und Firecrawl für sauberes HTML-Parsing und Markdown-Extraktion. Beide funktionieren einwandfrei, aber beide skalieren linear mit der Nutzung. Bei zehn Research-Jobs pro Tag kein Problem. Bei hundert wird es teuer. Bei dreihundert wird es absurd.

Das zweite Problem war subtiler: Wir haben Workflows gebaut, die auf die Antwortstruktur dieser APIs optimiert waren. Ändert SerpAPI ein Feld, bricht bei uns etwas. Firecrawl führt ein neues Pricing-Tier ein, und wir müssen entscheiden, ob wir umbauen oder zahlen. Wir hatten Abhängigkeiten, die wir nicht kontrollieren konnten.

Die Architektur: Zwei Dienste, ein Prinzip

Wir haben beide Services durch selbst-gehostete Alternativen ersetzt, die konzeptionell dasselbe tun, aber auf unserer Infrastruktur laufen. SearXNG ist eine Meta-Suchmaschine, die Ergebnisse von Google, Bing, DuckDuckGo und anderen aggregiert und als JSON zurückgibt. Crawl4AI ist ein Python-Framework, das Webseiten lädt, JavaScript rendert und strukturierte Inhalte extrahiert. Beide sprechen HTTP, beide liefern JSON, beide lassen sich direkt in unsere Workflows einhängen.

Die Deployment-Strategie war simpel: Docker Compose auf einem dedizierten Server, ein Reverse Proxy davor, fertig. SearXNG bekommt eine Instanz mit Redis-Cache, Crawl4AI läuft mit Playwright-Backend für JavaScript-Rendering. Beide Dienste sind nur intern erreichbar, unsere Workflows sprechen sie über interne Hostnamen an. Keine öffentlichen Endpunkte, keine API-Keys, keine Rate-Limits.

Die Integration in die bestehenden Sourcing-Flows war der kritische Teil. Wir haben die alten API-Nodes durch HTTP-Request-Nodes ersetzt, die gegen unsere eigenen Dienste laufen. Die Antwortstrukturen sind unterschiedlich, also haben wir Mapping-Logik gebaut, die SearXNG-JSON in das Format übersetzt, das unsere nachgelagerten Nodes erwarten. Dasselbe für Crawl4AI. Die Workflows selbst mussten nicht umgebaut werden, nur die Adapter-Schicht.

Entscheidung eins: Warum SearXNG und nicht Elasticsearch mit Custom Crawler

Wir hätten auch einen eigenen Crawler bauen und die Ergebnisse in Elasticsearch indexieren können. Das wäre flexibler gewesen, hätte uns aber in ein Maintenance-Loch geworfen. SearXNG ist seit Jahren stabil, hat eine aktive Community und liefert out-of-the-box brauchbare Ergebnisse. Wir wollten Research-Infrastruktur, keine Suchmaschinen-Forschung betreiben.

Der Trade-off: SearXNG aggregiert bestehende Suchmaschinen, es crawlt nicht selbst. Das bedeutet, wir sind immer noch von Google, Bing und anderen abhängig, nur indirekt. Wenn Google morgen alle Meta-Suchmaschinen blockt, haben wir ein Problem. Aber realistisch: Für unsere Use Cases, bei denen es um aktuelle News, Unternehmensdaten und Content-Trends geht, ist das Risiko akzeptabel. Wir brauchen keine Archiv-Suche über zehn Jahre alte Dokumente.

Entscheidung zwei: Warum Crawl4AI und nicht Scrapy oder Puppeteer direkt

Crawl4AI abstrahiert die hässlichen Details: Browser-Steuerung, JavaScript-Rendering, Cookie-Banner-Handling, Markdown-Extraktion. Scrapy ist mächtiger, aber low-level. Puppeteer ist flexibler, aber wir müssten selbst entscheiden, wie wir mit Single-Page-Apps, Lazy-Loading und Anti-Bot-Mechanismen umgehen. Crawl4AI hat diese Entscheidungen schon getroffen, und sie passen zu 80 Prozent unserer Fälle.

Die 20 Prozent, die nicht passen: Seiten mit aggressivem Bot-Schutz. Crawl4AI hat keine eingebaute Cloudflare-Umgehung, keine Proxy-Rotation, keine CAPTCHA-Lösung. Für diese Fälle haben wir einen Fallback: Wenn Crawl4AI nach drei Versuchen scheitert, schicken wir die URL an einen manuellen Review-Schritt. Das ist nicht elegant, aber ehrlich. Wir haben keine magische Lösung für Seiten, die aktiv gegen Scraping kämpfen.

Was schiefging: Performance und falsche Erwartungen

Die erste Woche war ernüchternd. SearXNG war langsam. Richtig langsam. Eine Suchanfrage, die bei SerpAPI 200 Millisekunden brauchte, dauerte plötzlich drei Sekunden. Der Grund: SearXNG fragt mehrere Upstream-Suchmaschinen parallel ab, wartet auf alle Antworten, merged die Ergebnisse und cached sie. Das ist konzeptionell sauber, aber latency-intensiv. Wir haben den Redis-Cache aggressiver konfiguriert und die Anzahl der Upstream-Quellen reduziert. Jetzt sind wir bei unter einer Sekunde, aber immer noch langsamer als die API.

Crawl4AI hatte ein anderes Problem: Memory Leaks. Nach ein paar hundert Crawls war der Container tot. Das lag an Playwright, das Browser-Instanzen nicht sauber aufräumte. Wir haben einen Cron-Job gebaut, der den Container alle sechs Stunden neu startet. Das ist kein Fix, das ist ein Workaround. Wir haben ein Issue im Crawl4AI-Repo geöffnet, aber bis dahin leben wir damit.

Die Kosten: Warum die Rechnung nicht aufging

Wir haben die Hardware-Kosten unterschätzt. Ein Server mit genug RAM für SearXNG, Crawl4AI, Redis und Playwright kostet 80 Euro im Monat. Dazu kommen Monitoring, Backups und die Zeit, die wir in Setup, Debugging und Wartung gesteckt haben. Über drei Monate gerechnet sind das mindestens 15 Stunden Engineering-Zeit. Wenn wir die intern mit 100 Euro pro Stunde bewerten, sind wir bei 1.500 Euro Setup-Kosten plus 240 Euro laufende Kosten für drei Monate. Die API-Rechnung lag bei 400 Euro pro Monat, also 1.200 Euro für denselben Zeitraum.

Kurzfristig haben wir draufgezahlt. Langfristig wird es sich amortisieren, aber nur, wenn wir die Nutzung hochfahren. Der eigentliche Gewinn ist strategisch: Wir haben keine Abhängigkeit mehr von Drittanbietern, keine Rate-Limits, keine plötzlichen Preiserhöhungen. Für Kunden, die DSGVO-konform arbeiten müssen und keine Daten an US-Services schicken wollen, ist das ein Verkaufsargument. Aber wer nur die Kosten vergleicht, wird enttäuscht sein.

Wo wir gelandet sind

Self-Hosting ist kein Sparmodell, es ist ein Kontrollmodell. Wir haben gelernt, dass die Entscheidung für eigene Infrastruktur nicht primär finanziell motiviert sein sollte, sondern strategisch. Wenn du Rate-Limits, Vendor-Lock-in und Datenhoheit als Risiken bewertest, macht Self-Hosting Sinn. Wenn du nur die Rechnung vergleichst, bleib bei den APIs.

Für uns war es die richtige Entscheidung, weil wir ohnehin in Richtung mehr eigene Infrastruktur gehen. Unsere DACH-Kunden fragen explizit nach selbst-gehosteten Lösungen, und wir können jetzt aus Erfahrung sprechen. Wir wissen, wo die Fallstricke liegen, was realistisch ist und was Marketing-Versprechen sind. Das ist mehr wert als die gesparten API-Kosten.

Die nächsten Schritte: Wir bauen ein internes Dashboard, das SearXNG- und Crawl4AI-Metriken trackt. Latency, Success-Rate, Cache-Hit-Rate. Sobald wir echte Zahlen haben, schreiben wir ein Follow-up. Bis dahin gilt: Self-Hosting funktioniert, aber es ist kein Free Lunch.

Zuletzt aktualisiert: September 2026

Blck Alpaca ist eine KI-Marketing-Automatisierungsagentur mit Sitz in Wien, spezialisiert auf datengetriebenes Marketing, maßgeschneiderte KI-Agenten und Enterprise-Workflow-Automatisierung für Unternehmen im DACH-Raum.