SearXNG + Crawl4AI: dlaczego przestaliśmy wynajmować API

Zaskoczenie: self-hosting nie jest automatycznie tańszy

Myśleliśmy, że zaoszczędzimy. Zamiast płacić co miesiąc czterocyfrowe kwoty za SerpAPI i Firecrawl, przenieśliśmy naszą infrastrukturę do researchu na SearXNG i Crawl4AI. Oba narzędzia działają na naszych własnych serwerach, oba są open source, oba kosztują zero euro w opłatach licencyjnych. Rachunek wydawał się banalny: koszty sprzętu zwrócą się w trzy miesiące, a potem będziemy na plusie.

Spoiler: po sześciu tygodniach działania faktycznie skreśliliśmy rachunki za API, ale łączne koszty nie spadły. Zyskaliśmy coś innego: kontrolę nad przepływem danych, koniec z limitami zapytań i pewność, że żaden zewnętrzny dostawca nie podwoi jutro cen ani nie wyłączy swojej usługi. Dla naszych klientów, którzy poważnie traktują zgodność z RODO, jest to warte więcej niż zaoszczędzone euro. Ale szczerze: kto patrzy tylko na cenę, ten się rozczaruje.

Problem: rachunki za API i vendor lock-in

Nasze dwa workflowy sourcingowe, które automatyzują badania rynku i research treści, opierały się na dwóch płatnych usługach: SerpAPI do ustrukturyzowanych wyników Google i Firecrawl do czystego parsowania HTML oraz ekstrakcji do Markdowna. Obie działają bez zarzutu, ale koszt obu rośnie liniowo wraz z użyciem. Przy dziesięciu zadaniach researchowych dziennie to żaden problem. Przy stu robi się drogo. Przy trzystu robi się absurdalnie.

Drugi problem był subtelniejszy: zbudowaliśmy workflowy zoptymalizowane pod strukturę odpowiedzi tych API. Gdy SerpAPI zmienia pole, coś się u nas psuje. Gdy Firecrawl wprowadza nowy próg cenowy, musimy zdecydować, czy przebudowujemy, czy płacimy. Mieliśmy zależności, nad którymi nie mieliśmy kontroli.

Architektura: dwie usługi, jedna zasada

Zastąpiliśmy obie usługi alternatywami self-hosted, które koncepcyjnie robią to samo, ale działają na naszej infrastrukturze. SearXNG to metawyszukiwarka, która agreguje wyniki z Google, Bing, DuckDuckGo i innych wyszukiwarek i zwraca je jako JSON. Crawl4AI to framework w Pythonie, który ładuje strony, renderuje JavaScript i wyodrębnia ustrukturyzowane treści. Oba komunikują się przez HTTP, oba zwracają JSON, oba da się podpiąć bezpośrednio do naszych workflowów.

Strategia wdrożenia była prosta: Docker Compose na dedykowanym serwerze, przed nim reverse proxy i gotowe. SearXNG dostaje instancję z cache Redis, Crawl4AI działa z backendem Playwright do renderowania JavaScriptu. Obie usługi są dostępne wyłącznie wewnętrznie, a nasze workflowy odwołują się do nich przez wewnętrzne nazwy hostów. Żadnych publicznych endpointów, żadnych kluczy API, żadnych limitów zapytań.

Najbardziej krytyczną częścią była integracja z istniejącymi workflowami sourcingowymi. Zastąpiliśmy stare węzły API węzłami HTTP Request, które kierują zapytania do naszych własnych usług. Struktury odpowiedzi się różnią, więc zbudowaliśmy logikę mapowania, która przekłada JSON z SearXNG na format oczekiwany przez nasze kolejne węzły. To samo dla Crawl4AI. Samych workflowów nie trzeba było przebudowywać, tylko warstwę adapterów.

Decyzja pierwsza: dlaczego SearXNG, a nie Elasticsearch z własnym crawlerem

Mogliśmy też zbudować własny crawler i indeksować wyniki w Elasticsearch. Byłoby to bardziej elastyczne, ale wpędziłoby nas w pułapkę utrzymania. SearXNG jest stabilny od lat, ma aktywną społeczność i od razu po instalacji daje użyteczne wyniki. Chcieliśmy mieć infrastrukturę do researchu, a nie zajmować się badaniami nad wyszukiwarkami.

Kompromis: SearXNG agreguje istniejące wyszukiwarki, sam niczego nie crawluje. To oznacza, że nadal jesteśmy zależni od Google, Bing i innych, tylko pośrednio. Jeśli Google jutro zablokuje wszystkie metawyszukiwarki, mamy problem. Ale realnie: w naszych przypadkach użycia, w których chodzi o bieżące wiadomości, dane o firmach i trendy w treściach, to ryzyko jest akceptowalne. Nie potrzebujemy przeszukiwania archiwów z dokumentami sprzed dziesięciu lat.

Decyzja druga: dlaczego Crawl4AI, a nie bezpośrednio Scrapy albo Puppeteer

Crawl4AI ukrywa brzydkie szczegóły: sterowanie przeglądarką, renderowanie JavaScriptu, obsługę banerów cookies, ekstrakcję do Markdowna. Scrapy ma większe możliwości, ale jest niskopoziomowy. Puppeteer jest bardziej elastyczny, ale musielibyśmy sami decydować, jak radzić sobie z aplikacjami single-page, lazy loadingiem i mechanizmami antybotowymi. Crawl4AI podjął już te decyzje i pasują one do 80 procent naszych przypadków.

Te 20 procent, które nie pasują: strony z agresywną ochroną przed botami. Crawl4AI nie ma wbudowanego obchodzenia Cloudflare, rotacji proxy ani rozwiązywania CAPTCHA. Na takie przypadki mamy fallback: jeśli Crawl4AI zawiedzie po trzech próbach, wysyłamy URL do etapu ręcznej weryfikacji. To nie jest eleganckie, ale uczciwe. Nie mamy magicznego rozwiązania na strony, które aktywnie walczą ze scrapingiem.

Co poszło nie tak: wydajność i błędne oczekiwania

Pierwszy tydzień był otrzeźwiający. SearXNG był wolny. Naprawdę wolny. Zapytanie, które w SerpAPI trwało 200 milisekund, nagle zajmowało trzy sekundy. Powód: SearXNG odpytuje równolegle kilka wyszukiwarek upstream, czeka na wszystkie odpowiedzi, scala wyniki i zapisuje je w cache. Koncepcyjnie to czyste rozwiązanie, ale kosztowne pod względem opóźnień. Skonfigurowaliśmy cache Redis bardziej agresywnie i zmniejszyliśmy liczbę źródeł upstream. Teraz schodzimy poniżej sekundy, ale nadal jesteśmy wolniejsi niż API.

Crawl4AI miał inny problem: wycieki pamięci. Po kilkuset crawlach kontener padał. Winny był Playwright, który nie sprzątał poprawnie instancji przeglądarki. Zbudowaliśmy cron job, który co sześć godzin restartuje kontener. To nie jest poprawka, to obejście. Otworzyliśmy issue w repozytorium Crawl4AI, ale dopóki nie zostanie rozwiązane, musimy z tym żyć.

Koszty: dlaczego kalkulacja się nie sprawdziła

Nie doszacowaliśmy kosztów sprzętu. Serwer z wystarczającą ilością RAM dla SearXNG, Crawl4AI, Redis i Playwright kosztuje 80 euro miesięcznie. Do tego dochodzą monitoring, kopie zapasowe i czas, który włożyliśmy w konfigurację, debugowanie i utrzymanie. W skali trzech miesięcy to co najmniej 15 godzin pracy inżynierskiej. Jeśli wycenimy je wewnętrznie na 100 euro za godzinę, wychodzi 1500 euro kosztów wdrożenia plus 240 euro kosztów bieżących za trzy miesiące. Rachunek za API wynosił 400 euro miesięcznie, czyli 1200 euro w tym samym okresie.

Krótkoterminowo dopłaciliśmy. Długoterminowo inwestycja się zwróci, ale tylko jeśli zwiększymy wykorzystanie. Prawdziwy zysk jest strategiczny: nie jesteśmy już zależni od zewnętrznych dostawców, nie mamy limitów zapytań ani nagłych podwyżek cen. Dla klientów, którzy muszą działać zgodnie z RODO i nie chcą wysyłać danych do usług z USA, to argument sprzedażowy. Ale kto porównuje tylko koszty, ten się rozczaruje.

Gdzie jesteśmy teraz

Self-hosting to nie model oszczędnościowy, tylko model kontroli. Nauczyliśmy się, że decyzja o własnej infrastrukturze nie powinna być motywowana przede wszystkim finansowo, ale strategicznie. Jeśli traktujesz limity zapytań, vendor lock-in i suwerenność danych jako ryzyka, self-hosting ma sens. Jeśli porównujesz tylko rachunek, zostań przy API.

Dla nas była to właściwa decyzja, bo i tak zmierzamy w stronę większej ilości własnej infrastruktury. Nasi klienci wprost pytają o rozwiązania self-hosted, a my możemy teraz mówić z doświadczenia. Wiemy, gdzie czyhają pułapki, co jest realistyczne, a co jest marketingową obietnicą. To jest warte więcej niż zaoszczędzone koszty API.

Kolejne kroki: budujemy wewnętrzny dashboard, który śledzi metryki SearXNG i Crawl4AI. Opóźnienie, wskaźnik powodzenia, wskaźnik trafień cache. Gdy tylko będziemy mieć prawdziwe liczby, napiszemy ciąg dalszy. Do tego czasu obowiązuje zasada: self-hosting działa, ale nie ma nic za darmo.

Ostatnia aktualizacja: wrzesień 2026

Blck Alpaca to agencja automatyzacji marketingu z wykorzystaniem AI z siedzibą w Wiedniu, specjalizująca się w marketingu opartym na danych, agentach AI szytych na miarę i automatyzacji workflowów w przedsiębiorstwach dla firm w całej Europie.