Ein Engineer. Eine Woche. Tausend Dollar.
Das ist, was es Cloudflare kostete, Next.js von Grund auf neu zu bauen.
Nicht patchen. Nicht umhüllen. Nicht den Build-Output rückwärtsentwickeln, wie es alle anderen versucht hatten. Eine vollständige Neuimplementierung der Next.js API-Oberfläche — Vite statt Webpack, Cloudflare Workers statt Node.js, und ein Deployment-Modell, das by Design am Edge läuft, statt als nachträglicher Einfall.
Das Ergebnis heißt V-Next. Und als ich die Ankündigung zum ersten Mal las, war meine erste Reaktion eine Mischung aus "das ist beeindruckend" und "warte, ist das eigentlich stabil genug, um darüber nachzudenken?" Diese zwei Gefühle hielten sich gleichzeitig etwa einen Tag lang, bis ich anfing, mich in die technischen Details und die Produktionsdaten zu vertiefen.
Hier ist, was mein Denken veränderte: Die $1.000-Zahl ist nicht der interessante Teil. Kosten sind nur die Schlagzeile, die Aufmerksamkeit erregt. Was tatsächlich untersucht werden sollte, ist die Methodik — wie eine von KI unterstützte Feedback-Schleife, verankert durch Next.js' eigene Open-Source-Testsuite, was ein monatelanges Teamprojekt hätte sein sollen, in sieben Tage Arbeit eines einzelnen Engineers verwandelte. Diese Methodik ist bedeutender als das Framework selbst, weil sie etwas darüber beschreibt, wie komplexe Software künftig gebaut wird.
Es gibt auch eine vergrabene technische Entscheidung in V-Next, an der die meisten Analysen vorbeigehen — diejenige, die erklärt, warum die Bundle-Größenreduzierung 57% beträgt und nicht 15%. Ich komme darauf zurück, aber zuerst musst du verstehen, warum Cloudflare dazu motiviert war, dies überhaupt zu tun, denn die Hintergrundgeschichte lässt die Architekturentscheidungen Sinn ergeben.
Das Vercel Lock-In Problem, über das Niemand Ehrlich Spricht
Next.js ist wirklich ausgezeichnete Software. Vercel baute etwas, das echte Probleme löste — SEO-freundliches Rendering, statische Generierung, server-seitiges Rendering, Incremental Static Regeneration, Server Actions — und verpackte es in eine Deployment-Erfahrung, die alles einfach wirken ließ. Das Framework und die Plattform wuchsen gemeinsam, und diese Ko-Evolution ist ein Teil dessen, was Next.js dominant machte.
Es ist auch genau das, was die Spannung erzeugte.
Vercel läuft auf vollem Node.js. Das gibt ihm Zugriff auf die gesamte Node.js API-Oberfläche — native Module, Dateisystem, Krypto, Streams, alles. Next.js-Funktionen entwickelten sich in der Annahme, dass volle Kompatibilität verfügbar war. Einige dieser Funktionen — insbesondere die fortgeschritteneren ISR-Konfigurationen und Server-Action-Muster — funktionieren auf Vercel und werden überall sonst zu Wartungsproblemen.
Cloudflare Workers ist eine andere Laufzeitumgebung. Es ist nicht Node.js. Es ist eine benutzerdefinierte V8-basierte Ausführungsumgebung mit einer Teilmenge von Web-Standard-APIs und einer begrenzten Node.js-Kompatibilitätsschicht. Der Kompromiss ist erheblich: Workers laufen am Edge, in Rechenzentren in mehr als 300 Städten, mit Cold-Start-Zeiten, die in Millisekunden statt Sekunden gemessen werden. Das Leistungsprofil ist wirklich anders. Aber diese Leistung kommt von einer eingeschränkten Laufzeitumgebung, und Next.js wurde nie mit dieser Einschränkung im Sinn entworfen.
Der Community-Versuch, diese Lücke zu überbrücken, hieß OpenNext — ein Open-Source-Projekt, das versuchte, Next.js auf Cloudflare Workers zum Laufen zu bringen, indem es den Build-Output anpasste. Das Problem war architektonisch. OpenNext musste rückwärtsentwickeln, was Next.js' Build-Prozess produzierte, und es dann transformieren, um in einer anderen Laufzeitumgebung zu funktionieren. Jedes Mal, wenn Vercel Next.js-Interna aktualisierte (was ständig passiert), brach etwas in OpenNext. Maintainer jagten immer dem Framework hinterher, anstatt zu bauen.
Cloudflare beobachtete diesen Zyklus lange genug, betrachtete den Aufwand für die Wartung von OpenNext und traf eine andere Entscheidung: Aufhören, Next.js' Output anzupassen, und stattdessen das Ding neu bauen, das ihn produziert.
Das ist V-Next. Eine saubere Implementierung der Next.js API-Oberfläche — dasselbe app/-Verzeichnis, dieselben Routing-Konventionen, dieselben Komponentenmuster, die Entwickler bereits kennen — aber von Grund auf gegen ein Cloudflare Workers-Ziel geschrieben.
Wie KI ein Framework in Sieben Tagen Baute
Die Methodik ist der Teil dieser Geschichte, der meine Aufmerksamkeit immer wieder zurückzieht.
Die Next.js-Testsuite ist öffentlich. Sie ist umfassend — deckt Routing-Verhalten, Rendering-Modi, Datenabruf-Muster, Fehlergrenzen und ein paar Hundert andere Fälle ab, die genau definieren, wie korrektes Next.js-Verhalten aussieht. Es ist die Art von Testabdeckung, die man für ein Framework möchte, von dem Millionen von Anwendungen abhängen.
Cloudflares Engineer verwendete diese Tests als Spezifikation. Nicht Dokumentation. Nicht den Next.js-Quellcode. Die Tests — weil Tests Verhalten eindeutig definieren auf eine Weise, wie es Prosa-Dokumentation nie ganz tut.
Der Prozess lief als Feedback-Schleife: KI generiert Code, Tests laufen, Fehler werden an die KI zurückgegeben, KI überarbeitet, Tests laufen erneut. Wiederholen. Die Open-Source-Testsuite lieferte die Grundwahrheit, auf die die KI-Generierung zusteuern musste. Ohne diesen Anker würde von KI generierter Code abdriften — etwas Produzierendes, das wie Next.js-Verhalten aussieht, aber in Randfällen abweicht auf Weisen, die erst in der Produktion auftauchen.
Die Rolle des menschlichen Engineers war Überwachung und Kurskorrektur. Wenn die KI eine Anforderung missverstand, wenn zwei Tests in inkompatible Richtungen zogen, wenn eine generierte Lösung technisch Tests bestand, aber etwas semantisch Falsches implementierte — das waren die Momente, die menschliches Urteil erforderten. Nicht der Großteil der Arbeit. Aber die entscheidenden 10%, die bestimmten, ob der Output tatsächlich korrekt war.
Die Kostenzahl — $1.000 — spiegelt KI-Rechenausgaben wider. Eine Woche intensiver Agenten-Läufe, Test-Iterationen und Revisions-Zyklen. Diese Zahl wird nur sinken, da Modelle effizienter werden.
Was dieser Ansatz erfordert, ist eine umfassende Testsuite, die das Verhalten, das du zu replizieren versuchst, tatsächlich spezifiziert. Die meisten Projekte haben das nicht. Next.js hat es, weil es ein reifes, intensiv gepflegtes Open-Source-Projekt mit Tausenden von Beitragenden ist, denen die Verhaltenskorrektheit wichtig ist. Die Methodik, die hier funktionierte, funktioniert genau deshalb, weil die Spezifikation bereits in Tests codiert war. Das ist eine echte Einschränkung, und es lohnt sich, das anzuerkennen.
Was ich an der Methodik am interessantesten finde, ist, wo der menschliche Engineer seine Zeit verbrachte. Nicht das Schreiben von Implementierungscode — die KI handhabte das. Nicht das Ausführen von Tests — CI handhabt das. Die menschliche Arbeit war größtenteils semantischer Natur: zu evaluieren, ob eine generierte Lösung, die Tests bestand, tatsächlich das Richtige implementierte. Tests verifizieren Verhalten innerhalb definierter Eingaben. Sie verifizieren nicht, dass du die richtige Architektur für die nächsten drei Versionen des Frameworks gewählt hast.
Diese Unterscheidung ist wichtig. Es gibt eine Klasse von Entscheidungen — "Soll der Routing-Zustand im Speicher leben oder bei jeder Anfrage aus der URL rekonstruiert werden?" — wo Tests keine klare Antwort geben, aber architektonische Konsequenzen sich im Laufe der Zeit aufhäufen. Das sind die Entscheidungen, bei denen menschliches Fachwissen unerlässlich ist. Die KI kann beide Ansätze generieren. Es braucht jemanden, der Produktions-Next.js-Apps gewartet hat, um zu wissen, welcher sechs Monate später Probleme verursacht.
Die Implikation für Teams, die darüber nachdenken, diese Methodik auf ihre eigenen Projekte anzuwenden: Du brauchst eine dichte Testsuite und einen Domänenexperten, der den Output prüfen kann. Die KI komprimiert die Implementierungszeit. Sie beseitigt nicht die Notwendigkeit für technisches Urteil. Diese zwei Dinge sind verschieden, und sie zu verwechseln ist der Weg, wie du mit einer Codebasis endest, die alle Tests besteht und dennoch grundlegende Architekturprobleme hat.
Die Technische Entscheidung, die die 57% Bundle-Reduzierung Erklärt
Hier ist die Sache, über die die meisten V-Next-Berichterstattungen hinweggehen.
Von Webpack zu Vite zu wechseln ist nicht nur ein Build-Tool-Tausch. Die zwei Tools haben fundamental unterschiedliche Philosophien bezüglich Bundling.
Webpack wurde in einer Ära von HTTP/1 entworfen, in der es die richtige Entscheidung war, alles in weniger, größere Dateien zu bündeln — weniger Round Trips bedeuteten bessere Leistung. Vite wurde entworfen, nachdem ES-Module universell wurden, was die Optimierungsrechnung vollständig veränderte. Vite verwendet native ES-Module in der Entwicklung und Rollup unter der Haube für Produktions-Builds. Beide sind darauf ausgerichtet, kleinere, zielgerichtetere Ausgaben zu produzieren als Webpack.
Darüber hinaus läuft Cloudflare Workers am Edge — was bedeutet, dass geografische Latenz bereits durch die Laufzeitarchitektur gelöst ist. Du rennst nicht gegen 200ms Round Trips zu einem weit entfernten Server. Der Edge-Standort handhabt das. Wofür du optimierst, verschiebt sich von "weniger HTTP-Anfragen" zu "kleinere Gesamtnutzlast." Die Ausgabe-Philosophie von Vite passt besser zu dieser Einschränkung.
Die 57% Bundle-Größenreduzierung ist keine Magie. Es ist der zusammengesetzte Effekt eines Build-Tools, das schlankere Ausgaben produziert, kombiniert mit einem Deployment-Ziel, das die Webpack-Ära-Optimierungen, die Bundles in erster Linie schwerer machten, nicht benötigt.
Build-Zeiten, die 4x schneller sind, folgen ähnlicher Argumentation. Die Entwicklungserfahrung von Vite war immer schneller als die von Webpack — nahezu sofortiger Hot Module Replacement, schnellere Cold Starts, parallele Verarbeitung, die Webpacks Plugin-Architektur erschwerte. Dieser Geschwindigkeitsvorteil überträgt sich auch auf Produktions-Builds.
Was V-Next mit ISR Macht
Incremental Static Regeneration ist eine der leistungsstärksten Funktionen von Next.js und auch die schwierigste, in eine andere Laufzeitumgebung zu portieren. Originales Next.js ISR verwendet das Dateisystem — es schreibt regenerierte Seiten auf Festplatte auf dem Server, serviert sie und revalidiert im Hintergrund.
Cloudflare Workers hat kein Dateisystem. Es hat Cloudflare KV — einen global verteilten Schlüssel-Wert-Speicher mit Edge-Lesegeschwindigkeiten.
V-Nexts ISR-Implementierung verwendet KV als Speicherschicht. Seiten werden in KV-Stores geschrieben, von dort aus serviert und im konfigurierten Intervall revalidiert. Das Verhalten aus der Perspektive des Entwicklers ist gleich. Die Implementierung darunter ist an die Laufzeitbeschränkungen von Workers angepasst.
Das ist tatsächlich eine gute Passform. KV-Lesevorgänge am Edge sind schnell. Die global verteilte Natur von KV bedeutet, dass über ISR regenerierte Seiten ohne zusätzliche Konfiguration in der Nähe von Nutzern in allen mehr als 300 Rechenzentren von Cloudflare verfügbar sind. Auf Vercel erfordert ISR spezifisches Edge-Cache-Verhalten, das du pro Route konfigurierst. Auf V-Next mit Cloudflare ist die Verteilung eine Eigenschaft der Speicherschicht selbst.
Was V-Next Bedeutet, Wenn Du Heute Etwas Baust
Bevor du anfängst, irgendetwas zu migrieren: V-Next ist experimentell. Cloudflare war darüber klar, und es ist die richtige Rahmung. Mehrere echte Anwendungen laufen darauf in der Produktion — einschließlich CIO.gov, was eine bedeutungsvolle Empfehlung ist — aber die Randfälle sind real.
Folgendes funktioniert noch nicht vollständig:
Open Graph Edge Runtime Analytics portieren nicht sauber. Wenn du dich auf diese für Social-Sharing-Vorschauen in spezifischen Konfigurationen verlässt, teste vor dem Festlegen.
KV Blob-Bindings und Postgres-Bindings haben Einschränkungen. V-Next verwendet Cloudflares Speicher-Primitive, und komplexe Datenbankintegrationsmuster, die in einer Node.js-Umgebung funktionieren, stoßen auf die Workers Laufzeitbeschränkungen. Prisma mit direkten Postgres-Verbindungen erfordert beispielsweise Hyperdrive (Cloudflares Datenbank-Proxy-Dienst), um korrekt zu funktionieren.
Turbopack ist nicht integriert. Wenn du Turbopack für lokale Entwicklungsgeschwindigkeit übernommen hast, läufst du Vite in V-Next — was schnell ist, aber ein anderes Tool ist und einige Turbopack-spezifische Konfigurationen nicht übertragen werden.
Create Next App Scaffolding hat noch kein V-Next-Äquivalent. Du richtest Projekte manuell ein oder passt bestehende Setups an.
Einige Vercel-spezifische APIs, von denen Next.js still abhängt, existieren in V-Next nicht. Wenn du @vercel/og, @vercel/analytics oder ähnliche von Vercel bereitgestellte Pakete verwendest, die mit Next.js-Interna integrieren, brauchen diese Alternativen.
Projekte, bei denen V-Next jetzt Sinn macht:
Wenn du ein neues Projekt startest und planst, es sowieso auf Cloudflare Workers zu deployen, ist V-Next eine ernsthafte Überlegung wert. Du bekommst die Next.js API-Oberfläche, die du bereits kennst, schnellere Builds, kleinere Bundles, und du erbst nicht die Webpack-Einschränkungen.
Wenn du auf Vercel bist und Kosten ein Druckpunkt sind, ist das es wert, zu benchmarken. Cloudflares Preismodell (Bandbreite ist günstiger, Compute am Edge ist für bestimmte Nutzungsmuster günstiger) kann die Wirtschaftlichkeit im großen Maßstab bedeutend anders machen.
Wenn du eine hochfrequentierte Content-Site mit starker ISR-Nutzung betreibst, hat der KV-gestützte Ansatz echte Vorteile für globale Leseleistung.
Projekte, mit denen du vorerst warten solltest:
Komplexe Next.js-Anwendungen, die viele Vercel-spezifische Funktionen verwenden oder auf fortgeschrittene Node.js API-Muster angewiesen sind, werden auf Kompatibilitätswände stoßen. Die Migrationsoberfläche ist für experimentelle Software zu groß.
Anwendungen mit strengen Stabilitätsanforderungen. Produktionskritische Systeme gehören nicht auf experimentelle Frameworks, es sei denn, du hast ernsthafte technische Kapazität, um mit dem Unerwarteten umzugehen.
Die Teile Davon, die Dich Unbehaglich Machen Sollten
Ehrliche Reaktion: V-Next hat mich beeindruckt. Der technische Ansatz ist solide, die Leistungszahlen sind real, und die von KI unterstützte Entwicklungsmethodik repräsentiert etwas wirklich Neues darüber, wie Frameworks gebaut werden können.
Und: Ich bin mir nicht sicher, ob Cloudflare der Held in dieser Geschichte ist.
Vercel baute Next.js. Sie haben es Open-Source gemacht, gepflegt, die Entwicklung dafür jahrelang finanziert. Cloudflare nutzte diese Open-Source-Oberfläche — insbesondere die Testsuite, deren Aufbau das Team von Vercel enorme Mühe kostete — um ein konkurrierendes Produkt zu erstellen. Das ist rechtlich in Ordnung. Es ist das, was Open Source erlaubt. Aber es lohnt sich zu benennen, was es ist: Cloudflare profitierte direkt von Vercels Investition, um mit Vercels Plattform zu konkurrieren.
Das Vendor-Lock-in-Problem verschwindet auch nicht. Es verlagert sich. V-Next ist für Cloudflare Workers konzipiert. ISR läuft auf Cloudflare KV. Assets werden von Cloudflare R2 serviert. Wenn du V-Next adoptierst, bist du nicht an Vercel gebunden — du bist an Cloudflare gebunden. Die Abhängigkeit wechselte nur die Hände.
Meine unpopuläre Meinung: das könnte für viele Teams der richtige Tausch sein. Cloudflare besitzt seine Infrastruktur von Anfang bis Ende — Rechenzentren, Compute, Bandbreite, Speicher. Diese vertikale Integration ist ein echter Vorteil für Preisvorhersehbarkeit und Leistungsoptimierung. Vercel baut auf AWS auf, was eine Schicht zur Kostenstruktur hinzufügt. Aber Entwickler sollten klarsichtig darüber sein, was "Lock-in entkommen" hier eigentlich bedeutet.
Es gibt auch ein breiteres strategisches Bild, das es wert ist, im Hinterkopf zu behalten. Cloudflare erwarb Astro — ein weiteres beliebtes Frontend-Framework — früher in dieser Timeline. V-Next ist Teil eines Musters: Cloudflare verkauft nicht mehr nur Infrastruktur. Sie bauen eine meinungsstarke Full-Stack-Entwicklerplattform, die gleichzeitig mit Vercel über mehrere Frameworks konkurriert. Der Endzustand, auf den sie hinarbeiten, ist einer, bei dem das gesamte Frontend-Deployment-Ökosystem — Framework, Build-Tooling, CDN, Speicher, Compute — innerhalb von Cloudflares Produktoberfläche lebt.
Das ist nicht von Natur aus schlecht für Entwickler. Konkurrenz zwischen Vercel und Cloudflare um die Entwicklererfahrung wird beide Plattformen dazu bringen, sich zu verbessern. Aber es lohnt sich, die Anreizstruktur hinter V-Next zu erkennen. Das ist ein Kundenakquisitions-Spiel, kein philanthropischer Framework-Beitrag. Cloudflare möchte den Traffic, die Bindung und die abrechenbare Compute, die mit dem Betrieb deiner Produktionsanwendungen einhergehen. V-Next ist das technische Mittel zu diesem kommerziellen Zweck.
Das zu verstehen macht V-Next nicht schlechter. Es klärt nur die Linse, durch die Cloudflare Entscheidungen über seine zukünftige Entwicklung treffen wird. Funktionen, die dich auf der Cloudflare-Infrastruktur halten, werden priorisiert. Portabilitätsfunktionen, die den Abgang erleichtern, nicht.
Die von KI unterstützte Entwicklungsgeschichte braucht auch sorgfältige Rahmung. Ein Engineer + KI + eine Woche ist bemerkenswert. Es ist auch ein Engineer, der Next.js tiefgründig verstand, Cloudflare Workers tiefgründig verstand und den von KI generierten Output mit Präzision evaluieren konnte. Die KI komprimierte die Implementierungstimeline. Das menschliche Fachwissen bestimmte, ob der komprimierte Output korrekt war. Beide Teile dieser Gleichung sind wichtig.
Was die Zahlen Tatsächlich Zeigen
Lass mich konkret sein darüber, was bewiesen ist und was noch etabliert wird.
4x schnellere Build-Zeiten: gemessen gegen echte Projekte, nicht Spielzeug-Apps. Wenn deine CI-Pipeline 8-12 Minuten für Next.js-Builds aufwendet, schaust du mit V-Next auf Sub-3-Minuten-Builds. Das häuft sich über ein Team an — weniger Kontextwechsel beim Warten auf Builds, schnelleres CI-Feedback, mehr Iterationen pro Tag.
57% kleinere Bundles: das ist signifikant für Time to Interactive, besonders auf Mobilgeräten. Eine 57%-Reduzierung der Bundle-Größe übersetzt sich direkt in schnellere Seitenladezeiten bei eingeschränkten Verbindungen. Für Content-Sites beeinflusst das sowohl die Nutzererfahrung als auch Core Web Vitals-Scores.
CIO.gov läuft V-Next in der Produktion: eine US-Regierungsseite mit echtem Traffic und echten Compliance-Anforderungen, die experimentelle Software betreibt, ist ein bedeutungsvolles Signal. Regierungs-IT-Teams nehmen Risiken nicht auf die leichte Schulter. Die Tatsache, dass sie gewechselt haben, ist Datenpunkt.
Was noch nicht etabliert ist: langfristige Stabilität unter komplexen Workload-Mustern, die vollständige Kompatibilitätsoberfläche über die echte Vielfalt der Next.js-Nutzung in Produktionscodebases und der Wartungspfad, sobald V-Next aktuelle Next.js-Versionen einholt.
Verfolge diese Metriken, wenn du V-Next pilotierst: Build-Zeit (CI-Logs geben dir das sofort), Bundle-Größe (Cloudflares Build-Output berichtet das) und Time to Interactive (Lighthouse oder WebPageTest gegen Produktion). Diese drei Zahlen sagen dir, ob die theoretischen Vorteile in deiner spezifischen Anwendung sichtbar werden.
Ein praktischer Hinweis: Richte zuerst ein Shadow-Deployment ein. Betreibe V-Next parallel zu deinem bestehenden Vercel-Deployment auf nicht-kritischen Routen, bevor du umstellst. Das gibt dir echte Traffic-Benchmarks ohne Produktionsrisiko. Die Kompatibilitätslücken, die für dein spezifisches Projekt wichtig sind, werden schnell unter realen Bedingungen auftauchen — weit zuverlässiger als jedes interne Testing enthüllen kann. Zwei Wochen Shadow-Traffic auf deinen tatsächlichen Nutzermustern sind mehr wert als jeder Benchmark-Vergleich aus dem Projekt von jemand anderem.
Der Teil, der es Wert Ist, Dabei zu Verweilen
Ein Engineer und ein KI-Modell haben ein großes Frontend-Framework in sieben Tagen neu gebaut, und der Output läuft in der Produktion auf echten Seiten einschließlich einer Regierungsdomäne.
Das ist kein Benchmark. Das ist ein Proof of Concept dafür, wie komplexe Software gebaut werden kann.
Die Next.js-Testsuite diente als Spezifikation. Die KI diente als Implementierungsmotor. Menschliches Fachwissen diente als Qualitätsschranke. Diese Arbeitsteilung wird in den nächsten 18 Monaten in mehr Softwareprojekten auftauchen — nicht nur Framework-Rebuilds, sondern komplexe Migrationen, Bibliotheksports und API-Neuimplementierungen, bei denen das korrekte Verhalten bereits definiert ist, aber die Implementierungsarbeit prohibitiv ist.
Die interessante Frage ist nicht, ob Cloudflare V-Next fertigstellen kann. Sie haben die technische Kapazität und das Infrastruktur-Motiv. Die interessante Frage ist, was als nächstes neu gebaut wird, von wem, und was das mit der Annahme macht, dass komplexe Software Teams von Menschen über lange Zeiträume erfordert.
Wenn ein Framework in einer Woche neu gebaut werden kann, was kann dann noch?
Das ist die Frage, die V-Next eigentlich stellt. Die Antwort wird neu gestalten, wie wir über die Kosten und das Tempo ehrgeiziger Ingenieurarbeit denken — und als jemand, der professionell mit KI-Agenten baut, ist diese Frage für mich bedeutend aufregender als jede Benchmark-Zahl.
🤝 Lass Uns Zusammenarbeiten
Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.
- 🔗 Fiverr (Maßanfertigungen & Integrationen): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (Enterprise-Lösungen): ramlit.com
- 🎨 ColorPark (Design & Branding): colorpark.io
- 🛡 xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
