Die meisten Leute stecken Firecrawl in die Schublade der Scraping-Bibliotheken – also die „pip install, Skript schreiben, fertig“-Crowd. Diese Einordnung ist aber falsch, und der Unterschied ist wichtig, bevor man überhaupt einen einzigen Befehl eingibt. Firecrawl selbst gehostet ist keine Bibliothek, die man importiert; es ist ein Dienst, den man betreibt, und ihn einzurichten bedeutet, sechs Docker-Container laufen zu lassen, die miteinander kommunizieren.
Ich habe den selbst gehosteten Stack auf einem Mac (arm64, Docker über colima) ohne Cloud-Schlüssel ausgeführt, seinen /v1/scrape-Endpunkt auf ein paar Scraping-freundliche Demo-Sites gerichtet und geschaut, was dabei herauskam. Kurz gesagt: Das Kernversprechen wurde gehalten – eine Seite rein, sauberes LLM-bereites Markdown raus – aber die Einrichtung war die aufwendigste aller Tools, die ich in dieser Forschungsbasis getestet habe. Dies ist ein erster Blick, keine endgültige Bewertung, und ich werde genau darlegen, was ich getestet habe und was nicht.
Firecrawl ist ein Dienst, keine Bibliothek
Hier ist das mentale Modell, das zuerst korrigiert werden muss. Die Scraping-Tools, die die meisten Entwickler verwenden, sind Bibliotheken: Man fügt eine Abhängigkeit hinzu, ruft eine Funktion auf, bekommt HTML oder geparste Daten innerhalb des eigenen Prozesses zurück. Firecrawl selbst gehostet ist ein anderes Kaliber. Es ist eine laufende Plattform mit einer eigenen API, und man kommuniziert über HTTP mit ihr.
Die offizielle Positionierung lautet: „Die API zum Suchen, Scrapen und Interagieren mit dem Web in großem Maßstab“, und die Produktform ist genau das – Seiten rein, sauberes Markdown oder strukturierte Daten raus. Wenn man selbst hostet, verknüpft man sich nicht mit Firecrawl. Man fährt einen docker compose-Stack hoch und ruft einen Endpunkt auf, genau wie man jeden internen Microservice aufrufen würde.
Der Stack, den ich ausgeführt habe, bestand aus sechs Diensten:
- api – die HTTP-Schnittstelle, die man tatsächlich aufruft
- playwright-service – ein Headless-Browser für JavaScript-Rendering
- redis – Warteschlange und Cache
- rabbitmq – Message Broker
- nuq-postgres – eine Postgres-Variante für den Job-Status
- foundationdb – verteilter Schlüssel-Wert-Speicher
Das ist ein echtes Backend, kein Hilfsskript. Redis, RabbitMQ, Postgres und FoundationDB sind alle für sich genommen industrielle Infrastruktur. Der Vorteil ist, dass Firecrawl die komplexen Teile des Scrapings – Warteschlangen, Rendering, Wiederholungsversuche – hinter einem API-Aufruf abwickelt. Die Kosten sind, dass man nun diese sechs Container betreibt. Behalten Sie diesen Kompromiss im Hinterkopf; er zieht sich durch diese gesamte Rezension.
Als Referenz habe ich gegen die firecrawl-py 4.32.0 und firecrawl-js 4.30.0 SDKs getestet und das offizielle vorgefertigte ghcr.io/firecrawl/firecrawl:latest-Image am 09.07.2026 heruntergeladen. Das Repository hat zu diesem Datum ungefähr 148.000 Sterne (nennen wir es Metadaten, nicht eine Qualitätsbewertung) unter einer AGPL-3.0-Lizenz – ein Detail, auf das ich zurückkommen werde, da es die Berechnung für die kommerzielle Nutzung ändert.
Der Kerntest: Eine Seite wird zu sauberem Markdown
Der ganze Grund, warum Firecrawl existiert, ist, eine Webseite in Markdown umzuwandeln, das ein LLM tatsächlich lesen kann. Das ist also das Erste, was ich überprüft habe.
Ich habe /v1/scrape auf books.toscrape.com gerichtet, einen statischen Katalog, der speziell für Scraping-Übungen erstellt wurde. Das Ergebnis: 9.222 Zeichen sauberes, LLM-bereites Markdown, wobei der Seitentitel All products | Books to Scrape korrekt geparst wurde. Kein rohes HTML, das in einen String gekippt wurde – strukturiertes Markdown, mit Überschriften, Links und Bildreferenzen intakt. Die Art von Ausgabe, die man direkt in eine Retrieval-Pipeline einfügen oder einem Modell zuführen könnte, ohne einen zweiten Reinigungsschritt.
Dies ist Firecrawls größte Stärke, und selbst gehostet lieferte es dies ohne Probleme. Wenn Ihre Aufgabe lautet: „Geben Sie mir den lesbaren Inhalt dieser Seite als Markdown“, kam eine statische Seite genau wie beworben zurück. Das ist ein wirklich nützliches Grundelement, und es ist der Grund, warum das Tool die Anhängerschaft hat, die es hat.
Es ist wichtig, den Umfang genau zu definieren: Ich habe den Einzelpfad /v1/scrape getestet. Ich habe /v1/crawl, den Multi-Page-Crawler, der eine ganze Site durchsucht, nicht getestet. Das ist eine separate Funktion mit eigenen Fehlermodi, und ich werde nicht behaupten, dass sie funktioniert, wenn ich sie nicht ausgeführt habe.
JavaScript-Seiten: Der gebündelte Browser verdient seinen Container
Eine statische Seite ist der einfache Fall. Die schwierigere Frage für jeden Web-Scraper ist, was passiert, wenn der Inhalt erst nach der Ausführung von JavaScript erscheint – was im modernen Web die meiste Zeit der Fall ist.
Hier hört der playwright-service-Container auf, Overhead zu sein, und wird zum eigentlichen Punkt. Ich habe den Web-Scraper auf quotes.toscrape.com/js/ gerichtet, eine Version der Demo-Site, die ihre Zitate clientseitig rendert. Wenn Firecrawl nur das rohe HTML abrufen würde, wären die Zitate nicht vorhanden – sie existieren erst, wenn der Browser das Skript der Seite ausführt.
Das Scrape kam mit 1.574 Zeichen Markdown zurück, und das Einstein-Zitat war darin enthalten. Dieses Zitat ist Post-JavaScript-Inhalt: Seine Anwesenheit ist der Beweis, dass der playwright-service die Seite tatsächlich in einer echten Browser-Engine gerendert hat, bevor er Text extrahiert hat, anstatt die leere Pre-Render-Shell zu greifen.
Einer der sechs Container ist also ein Headless-Browser, und er erledigt die Aufgabe, für die man ihn einstellen würde. Das ist die konkrete Rechtfertigung für die schwerere Architektur: Man zahlt nicht nur für Container, man zahlt für die Fähigkeit, JS-lastige Seiten zu rendern, ohne die eigene Browser-Automatisierung einzurichten. Für viele reale Ziele ist das der Unterschied zwischen brauchbarer Ausgabe und leeren Divs.
Wenn das Ziel schlecht ist: Strukturierte Fehler, kein Absturz
Web-Scraper verbringen einen überraschend großen Teil ihres Lebens damit, auf Dinge zu zeigen, die nicht funktionieren – tote Hosts, falsch geschriebene URLs, Server, die hängen bleiben. Wie ein Tool fehlschlägt, ist genauso aufschlussreich wie wie es erfolgreich ist.
Ich habe der API absichtlich einen ungültigen Host gegeben. Sie gab einen strukturierten HTTP 500 zurück und lief weiter – kein Stack-Trace, der an den Client gespuckt wurde, kein Container, der umfiel, kein hängender Prozess. Der Fehler kam als saubere Antwort zurück, auf die der Aufrufer verzweigen kann.
Das ist das langweilige, korrekte Verhalten, das man von etwas erwartet, das man in eine Pipeline einfügen würde. Ein Web-Scraper, der bei einem schlechten Ziel in Panik gerät, ist ein Web-Scraper, den man nicht automatisieren kann. Dieser gab einen Fehler zurück, den man abfangen und weitermachen kann. Ich habe nur einen einzigen Fehlerfall getestet, also lesen Sie dies als „hat den einen Fehler, den ich ihm zugeworfen habe, korrekt behandelt“, nicht als eine umfassende Resilienzprüfung – aber der eine Datenpunkt war das richtige Ergebnis.
Setup-Realität: Der größte Aufwand in der Basis
Nun der Teil, den niemand für den Launch-Tweet screenshotet. Firecrawl selbst gehostet war, ohne Übertreibung, die aufwendigste Einrichtung aller Tools in dieser Forschungsbasis – und ich habe viele davon eingerichtet.
Sechs Container sind die Grundkosten. Aber ich bin auch auf zwei Probleme gestoßen, und ich möchte genau sagen, wessen Schuld sie waren – wie sich herausstellte, nicht Firecrawls.
Problem eins: der Build aus der Quelle. Das Erstellen der Images aus der Quelle schlug in meiner colima-VM bei einem containerd-Snapshotter-Fehler fehl. Das ist eine bekannte, fehleranfällige Interaktion zwischen dem Build und der Speicherschicht von colima – ein Infrastrukturproblem in meiner Umgebung, kein Fehler in Firecrawl. Die Compose-Datei dokumentiert eine Alternative: Verwenden Sie stattdessen die offiziellen vorgefertigten ghcr.io/firecrawl/*-Images, anstatt lokal zu bauen. Ich bin auf diese umgestiegen, und der gesamte Stack kam sauber hoch. Wenn Sie einen Standard-Docker-Daemon anstelle von colima verwenden, werden Sie dies möglicherweise überhaupt nicht sehen; ich kennzeichne es als Umgebungsvorbehalt, und die Validierung des Contributor-Builds auf einem sauberen Daemon steht auf meiner Liste der offenen Punkte.
Problem zwei: der SSRF-Schutz. Meine ersten Scrapes wurden durch Firecrawls private IP / SSRF-Schutz blockiert. Warum? Die Netzwerkfunktionen von colima ordnen öffentliche Hostnamen 198.18.x.x-Adressen zu, die in einem reservierten Bereich liegen, den Firecrawl korrekterweise als privat behandelt – so hat seine Sicherheitsschicht ihre Aufgabe erfüllt und sich geweigert, etwas abzurufen, das wie ein internes Ziel aussah. Um dies nur für lokale Tests zu umgehen, habe ich ALLOW_LOCAL_WEBHOOKS=true gesetzt.
Dieses Flag wird in die Produktion kopiert und führt zu Zwischenfällen, daher sei genau gesagt, was es ist: Der SSRF-Schutz ist ein Feature, kein Hindernis. Er verhindert, dass ein Scraping-Dienst dazu verleitet wird, Ihr internes Netzwerk anzugreifen. Ich habe ihn deaktiviert, weil eine Eigenart des colima-DNS meine legitimen öffentlichen Ziele innerhalb der VM privat erscheinen ließ. Schalten Sie den SSRF-Schutz in einer echten Bereitstellung nicht aus. Wenn Sie eine operative Anmerkung aus dieser Rezension mitnehmen, dann diese.
Beide Probleme waren, um es klar zu sagen, Artefakte des Betriebs von Docker über colima auf einem Laptop – keine Mängel in der Software. Andererseits ist das Setup-Gewicht selbst real und von Firecrawl beabsichtigt. Dies ist nicht das Tool, zu dem man greift, wenn man ein schnelles lokales Skript möchte; es ist das Tool, das man einrichtet, wenn man einen Rendering-fähigen Scraping-Dienst möchte und bereit ist, dafür Infrastruktur zu betreiben.
Was ich nicht getestet habe und was es nicht kann
Hier ist, was ich nicht behandelt habe und was das Tool Ihnen nicht bietet.
Selbst gehostet hat keine Fire-Engine. Firecrawls Cloud-Produkt enthält Fire-engine, seine proprietäre Anti-Block-Schicht zur Umgehung von Bot-Abwehrmechanismen. Gemäß der projekteigenen SELF_HOST.md erhalten selbst gehostete Instanzen diese nicht. Wenn Sie sich also vorstellen, dass selbst gehostetes Firecrawl aggressive Anti-Bot-Systeme sofort durchbricht, korrigieren Sie das Bild – diese Funktion befindet sich in der Cloud-Ebene und war nicht Teil dessen, was ich ausgeführt habe.
Die Cloud-API wurde hier nicht getestet. Ich hatte keinen Cloud-Schlüssel, daher bezieht sich alles oben Genannte nur auf den selbst gehosteten Stack. Der verwaltete Cloud-Dienst – mit Fire-engine, gehosteter Skalierung und den KI-Funktionen – ist ein anderes Produkt, und ich werde seine Leistung nicht von außen beurteilen. Betrachten Sie jegliche Cloud-Behauptung als außerhalb des Umfangs dieser Rezension.
KI-Funktionen benötigen einen Schlüssel. Das json-Strukturausgabeformat und der /extract-Endpunkt stützen sich auf ein LLM, was bedeutet, dass man einen OpenAI-Schlüssel mitbringen oder Ollama einbinden muss. Das bringt die Modellwahl in die Materialliste: Bevor Sie sich für ein Setup entscheiden, vergleichen Sie die aktuellen API-Preise der Anbieter, die Sie einbinden könnten. Ich habe diese Pfade nicht getestet, daher befinden sich /extract und die strukturierte json-Ausgabe ebenfalls in der Spalte der ungetesteten Funktionen.
Proxies sind ein Vorbehalt, keine Schlagzeile. Firecrawl unterstützt die Proxy-Konfiguration, aber ich führe es bewusst als Fußnote auf – es ist ein Regler, den man drehen kann, kein Grund, das Tool zu wählen, und selbst gehostet fehlt immer noch die Anti-Block-Schicht der Cloud.
AGPL-3.0 ist eine echte Compliance-Entscheidung. Dies verdient einen eigenen Abschnitt.
Die Lizenz: AGPL-3.0 lesen, bevor Sie veröffentlichen
Firecrawl ist unter AGPL-3.0 lizenziert. Das ist keine beiläufige Zeile am Ende einer README-Datei – es ist ein starkes Copyleft mit einer Netzwerk-Nutzungsklausel, und es kann direkt beeinflussen, ob Sie ein kommerzielles Produkt auf einer selbst gehosteten Instanz aufbauen können.
Kurz gesagt: Standard- GPL-Verpflichtungen treten bei der Verbreitung in Kraft. AGPL geht weiter – die Netzwerk-Nutzungsbestimmung bedeutet, dass das Anbieten der Software-Funktionalität für Benutzer über ein Netzwerk als die Art der Nutzung zählen kann, die Verpflichtungen zur Quellcode-Verfügbarkeit mit sich bringt. Wenn Sie selbst gehostetes Firecrawl in einen Dienst einbetten, den Ihre Kunden über das Internet erreichen, ist diese Klausel direkt relevant, und „wir haben nie eine Binärdatei ausgeliefert“ ist nicht der Ausweg, den die Leute annehmen.
Ich bin nicht Ihr Anwalt, und die Lizenzinterpretation hängt davon ab, wie genau Sie bereitstellen. Aber für jede kommerzielle Empfehlung ist AGPL-3.0 eine erstklassige Überlegung, kein Kleingedrucktes. Beziehen Sie die Person ein, die in Ihrem Unternehmen für die Lizenzierung zuständig ist, bevor Sie darauf aufbauen. Dies zu kennzeichnen ist keine Kritik an Firecrawl – viele ausgezeichnete Tools sind AGPL – es ist nur eine Tatsache, die Sie frühzeitig auf dem Tisch haben müssen.
Wo Thunderbits Entwickler-Stack passt
Thunderbit für Web-Datenextraktion testen
Wenn Ihr eigentliches Ziel „Seite → LLM-bereites Markdown“ oder „Seite → strukturierte Daten“ ist und die sechs Container-Betriebssteuer plus die AGPL-Frage nichts sind, was Sie selbst verantworten möchten, dann ist das genau die Lücke, für die Thunderbit's Entwickler-Stack gebaut wurde. Dieselbe KI-Engine hinter unseren über 100.000 Erweiterungsbenutzern, auf drei Arten für technische Arbeiten zugänglich – wobei die Infrastruktur auf unserer Seite der Linie bleibt.
- Open API (REST).
POST /distillwandelt eine Seite in sauberes, LLM-bereites Markdown um;POST /extractgibt strukturierte Daten gemäß einem von Ihnen definierten JSON-Schema zurück. JS-Rendering, Anti-Bot-Behandlung und dynamische Inhalte werden serverseitig verarbeitet – kein Browser-Container, den Sie ausführen müssen. EinrenderMode-Flag (none/basic/full) steuert, wie stark gerendert wird, und Batch-Endpunkte verarbeiten bis zu 100 URLs für die Destillation. - MCP-Server. Ein offizieller Model Context Protocol-Server, sodass ein KI-Agent innerhalb von Claude oder Cursor während der Aufgabe scrapen kann:
thunderbit_suggest_fieldszur Planung einer Extraktion (kostenlos),thunderbit_distillfür Markdown,thunderbit_extractfür strukturierte Daten. Der Agent entscheidet, wann Daten abgerufen werden, ohne seine Umgebung zu verlassen. - CLI.
npx -y @thunderbit/thunderbit-cliführt Scrapes vom Terminal, Skripten, CI oder Cron aus – kein Browser, kein Stack, der beaufsichtigt werden muss. Leiten Sie es direkt in andere Tools:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Der Kontrast zu selbst gehostetem Firecrawl ist klar. Firecrawl selbst gehostet gibt Ihnen die volle Kontrolle und volle operative Verantwortung: sechs Container, das Setup-Gewicht, die AGPL-Bedingungen und keine Fire-Engine für Anti-Block. Thunderbits API/MCP/CLI tauscht diese Kontrolle gegen eine gehostete Engine, die schema-konformes strukturiertes JSON zurückgibt – nicht nur rohes Markdown – wobei die Container, die Anti-Bot-Schicht und die Copyleft-Verpflichtungen von Ihnen genommen werden. Verschiedene Tools für unterschiedliche Infrastruktur-Anforderungen.
Hier ist der Kompromiss in einer Übersicht:
| Überlegung | Firecrawl selbst gehostet | Thunderbit Entwickler-Stack (API · MCP · CLI) |
|---|---|---|
| Bereitstellungsform | Dienst, den Sie betreiben (6 Container) | Gehostete API, die Sie aufrufen |
| Zum Starten | docker compose einen 6-Dienste-Stack hochfahren | API-Schlüssel, dann Anfrage |
| JS-Rendering | Gebündelter playwright-service (Sie betreiben ihn) | Serverseitig, renderMode-Flag |
| Strukturierte Ausgabe | Benötigt LLM-Schlüssel (/extract, json) | POST /extract mit JSON-Schema |
| Anti-Bot-Schicht | Keine selbst gehostet (Fire-engine ist nur Cloud) | Serverseitig behandelt |
| Lizenz | AGPL-3.0 (Netzwerk-Nutzungs-Copyleft) | Kommerzielle API, kein Copyleft auf Ihrem Code |
| Am besten geeignet, wenn | Sie volle Kontrolle wünschen und Infrastruktur betreiben | Sie Markdown/strukturierte Daten ohne Betrieb wünschen |
Keines ist universell „besser“. Wenn der Betrieb der Plattform der Punkt für Sie ist – volle Datenkontrolle, keine externe Abhängigkeit und AGPL passt zu Ihrer Situation – ist selbst gehostetes Firecrawl eine leistungsfähige, aktiv gewartete Wahl. Wenn Sie lieber einen API-Aufruf tätigen und das Sechs-Container-Leben überspringen möchten, ist das der Ansatz für den Thunderbit-Stack.
Wer Firecrawl tatsächlich selbst hosten sollte
Entfernt man den Hype, ist das Bild klar genug, um nach Bedarf zu sortieren.
Hosten Sie Firecrawl selbst, wenn Sie die volle Kontrolle über Ihre Scraping-Infrastruktur wünschen, Sie sich mit dem Betrieb von Redis / RabbitMQ / Postgres / FoundationDB in der Produktion wohlfühlen, Ihre Rendering-Anforderungen den playwright-service-Container rechtfertigen und AGPL-3.0 für Ihre Bereitstellung funktioniert. Die Kernfunktion ist real: Ich habe sauberes, strukturiertes, LLM-bereites Markdown sowohl von einer statischen als auch von einer JS-gerenderten Seite erhalten, und der gesamte Stack lief auf vorgefertigten Images.
Suchen Sie woanders, wenn Sie ein schnelles lokales Skript wünschen (dies ist das aufwendigste Setup in der Basis, Punkt), Sie Cloud-Grade-Anti-Block ohne eigenen Betrieb benötigen (selbst gehostet hat keine Fire-engine) oder die AGPL-Netzwerk-Nutzungsklausel mit Ihren kommerziellen Plänen kollidiert. Für den Fall „Ich brauche nur Markdown oder strukturierte Daten von einer URL, ohne den Betrieb“ deckt eine gehostete API wie Thunderbits /distill und /extract denselben Bereich ab, ohne die Container.
Meine vorläufige Einschätzung: starker Kern, hoher operativer Aufwand und eine Lizenz, die Sie vor der kommerziellen Nutzung klären müssen. Es verdient seinen Platz für Teams, die die gesamte Pipeline besitzen möchten – und es verlangt viel von allen anderen. Ich werde dies erneut prüfen, sobald ich /v1/crawl ausgeführt, /extract mit einem LLM-Schlüssel getestet und den Build aus der Quelle auf einem Nicht-Colima-Daemon validiert habe; das sind die offenen Fragen zwischen dieser und einem endgültigen Urteil.
Thunderbit für Web-Datenextraktion testen Get Started Free
FAQs
Ist selbst gehostetes Firecrawl dasselbe wie die Cloud-Version?
Nein. Selbst gehostet bietet Ihnen die Kern-Scrape-zu-Markdown-Engine und JavaScript-Rendering über den gebündelten playwright-service, aber es enthält nicht Fire-engine, die proprietäre Anti-Block-Schicht des Cloud-Produkts. KI-Funktionen wie der /extract-Endpunkt und die json-Ausgabe erfordern ebenfalls Ihren eigenen LLM-Schlüssel (OpenAI oder Ollama). In dieser Rezension habe ich nur den selbst gehosteten Stack getestet; die Cloud-API war außerhalb des Umfangs.
Wie viele Container benötigt selbst gehostetes Firecrawl tatsächlich? Sechs: api, playwright-service, redis, rabbitmq, nuq-postgres und foundationdb. Es ist ein vollständiger Dienst-Stack, keine einzelne Binärdatei – deshalb war es das aufwendigste Setup aller Tools in dieser Forschungsbasis. Planen Sie den operativen Overhead für den Betrieb von Message-Broker-, Cache- und Datenbankinfrastruktur ein, nicht nur für ein Skript.
Kann Firecrawl JavaScript-lastige Seiten selbst gehostet verarbeiten? Ja, in meinen Tests. Der gebündelte playwright-service rendert Seiten in einer echten Browser-Engine vor der Extraktion. Ich habe dies auf quotes.toscrape.com/js/ bestätigt, wo das Einstein-Zitat – Inhalt, der erst nach der Ausführung von JavaScript existiert – im zurückgegebenen Markdown erschien. Diese Rendering-Fähigkeit ist genau der Grund, warum einer der sechs Container ein Headless-Browser ist.
Beeinflusst die AGPL-3.0-Lizenz die kommerzielle Nutzung? Das kann sie, und Sie sollten dies als eine primäre Frage behandeln. AGPL-3.0 ist ein starkes Copyleft mit einer Netzwerk-Nutzungsklausel, was bedeutet, dass das Anbieten der Software-Funktionalität für Benutzer über ein Netzwerk Verpflichtungen zur Quellcode-Verfügbarkeit mit sich bringen kann – selbst wenn Sie niemals eine Binärdatei verbreiten. Wenn Sie planen, ein kommerzielles Produkt auf einer selbst gehosteten Instanz aufzubauen, sprechen Sie mit der Person in Ihrem Unternehmen, die für die Lizenzierung zuständig ist, bevor Sie sich festlegen. Diese Rezension kennzeichnet die Lizenz; es ist keine Rechtsberatung.
Was ist der Unterschied zwischen Firecrawl und Thunderbits Entwickler-Tools?
Firecrawl selbst gehostet ist ein Dienst, den Sie betreiben – sechs Container, die Sie selbst ausführen, mit AGPL-3.0-Bedingungen und ohne integrierte Anti-Block-Schicht. Thunderbits Entwickler-Stack (Open API, MCP-Server, CLI) ist eine gehostete Engine, die Sie aufrufen: POST /distill für Markdown, POST /extract für JSON-Schema-strukturierte Daten, mit JS-Rendering und Anti-Bot-Behandlung serverseitig und ohne Copyleft-Verpflichtung für Ihren eigenen Code. Firecrawl eignet sich für Teams, die die volle Infrastrukturkontrolle wünschen; Thunderbit eignet sich für diejenigen, die die Ausgabe ohne den operativen Aufwand wünschen.
