Das Wichtigste in Kürze
Deno als eigenständiges Produkt hat jetzt ein Enddatum. Am 9. Oktober 2026 gaben Ryan Dahl und Kenton Varda von Cloudflare bekannt, dass das gesamte Deno-Team zu Cloudflare wechselt. Deno Deploy, die gehostete Plattform, läuft noch sechs Monate und wird dann geschlossen. Die Deno-Runtime bekommt ein Jahr lang monatliche Releases mit Bugfixes und Sicherheitsupdates, danach endet die offizielle Entwicklung. Der Code bleibt Open Source, die Community kann ihn weiterführen.
Die neue Aufgabe des Teams: das Programmiermodell von Cloudflare Workers überall lauffähig zu machen, auch auf Ihren eigenen Servern. Für die meisten Deno-Deploy-Kunden ist der Umzug zu Workers der praktische Weg; Cloudflare sagt zahlenden Kunden Unterstützung bei der Migration zu.
Was haben Cloudflare und Deno angekündigt?
In einem gemeinsamen Beitrag erklärten Dahl und Varda, dass das Deno-Team das Workers-Modell an mehr Orte bringen soll. Konkret sollen Code und Konzepte von Celld in workerd einfließen, die Open-Source-Runtime, auf der Cloudflare Workers bereits in Produktion läuft. Celld ist ein einzelnes Rust-Binary, dessen einzige externe Abhängigkeit ein Object Storage ist – es lässt sich also ohne das Netz von Cloudflare selbst betreiben.
Denos eigene Ankündigung legt fest, was mit den Produkten passiert. Deno Deploy bleibt sechs Monate bis zur Abschaltung. Die Runtime geht in den Wartungsmodus: ein Jahr ab Ankündigung monatliche Releases mit Fixes und Sicherheitspatches, danach keine offizielle Weiterentwicklung. JSR bleibt online und wechselt auf Cloudflare-Infrastruktur. TechCrunch und The New Stack berichteten am 9. und 10. Oktober über den Deal und wiesen darauf hin, dass keine Konditionen genannt wurden.
Warum will Cloudflare Deno?
Es geht um das Programmiermodell, nicht um die Marke der Runtime. Deno Deploy und Workers konkurrierten um dieselben Edge-Serverless-Kunden, und Celld hat gezeigt, dass Deno das Workers-Modell auch ohne Cloudflare anbieten konnte. Indem Cloudflare diese Arbeit ins Haus holt, bekommt es ein offizielles Self-Hosting-Angebot für Workers und Durable Objects. Das ist relevant für Kunden, die das Modell mögen, aber nicht jede Last im Netz eines Drittanbieters betreiben können – etwa wegen Vorgaben zur Datenresidenz oder On-Premises-Pflichten. Varda bezeichnete Open Source und einen „Notausgang“ als gutes Geschäft; Dahl sagte, Ziel sei, das Workers-Modell zu einem Standardweg für den Bau von Servern zu machen.
Was das für Software-Teams in den USA und der EU bedeutet
Erstens: Das ist ein Anbieterausstieg mit Frist. Alles, was auf Deno Deploy läuft, braucht innerhalb von sechs Monaten ein neues Zuhause: Code, Umgebungsvariablen, Cron-Jobs, KV-Daten, eigene Domains und TLS. Behandeln Sie es wie jede Plattform-Abkündigung: erfassen, was dort läuft, Ziel festlegen und einen Cutover mit Rollback-Plan terminieren, statt bis zu den letzten Wochen zu warten.
Zweitens: Eine Runtime im Wartungsmodus ist eine Sicherheitsfrage. Nach dem Jahresfenster lässt sich eine Deno-Runtime ohne offizielle Patches in SOC-2-, ISO-27001- oder NIS2-Prüfungen schwerer rechtfertigen – nicht mehr unterstützte Software ist dort ein Standardbefund. Wer Deno selbst betreibt, sollte das Support-Ende jetzt im Risikoregister vermerken und entscheiden, ob er auf einen Community-Fork setzt, über workerd zu Workers wechselt oder auf Node.js portiert, mit dem Deno ohnehin kompatibel sein wollte.
Drittens: Das selbst gehostete Workers-Modell könnte Edge-Architekturentscheidungen verändern. Bekommt workerd das einfache Self-Hosting von Celld, könnte derselbe Code im Cloudflare-Netz in den USA und auf eigenen Servern in einer EU-Region laufen. Für regulierte FinTech- und HealthTech-Lasten ist das interessant, aber noch ein Plan und kein ausgeliefertes Produkt. Planen Sie nicht darauf, bevor es ein Release mit dokumentiertem Betrieb gibt.
Was bedeutet das für den DACH-Markt?
Im DACH-Raum wurde Deno Deploy vor allem von Agenturen, Start-ups und Produktteams für Edge-Funktionen, Webhooks und kleine APIs genutzt – oft als „Schatten-Infrastruktur“ außerhalb des zentralen Cloud-Vertrags. Genau solche Dienste fallen bei einer Abkündigung zuerst durchs Raster. Für viele Teams ist das zugleich eine Chance, die Edge-Strategie zu bereinigen: Wer ohnehin auf Cloudflare setzt, konsolidiert auf Workers; wer Datenresidenz in Deutschland oder der Schweiz streng auslegt, sollte die angekündigte Self-Hosting-Variante beobachten, aber bis zu einem stabilen Release auf Node.js in Containern bei einem EU-Hoster oder in der eigenen Kubernetes-Umgebung setzen.
Regulatorisch ist der Fall ein Lehrbuchbeispiel für Exit-Strategien. Finanzunternehmen müssen nach DORA für IKT-Drittdienstleister, die kritische Funktionen unterstützen, Ausstiegsstrategien dokumentieren und testen; eine angekündigte Abschaltung mit sechs Monaten Vorlauf ist genau das Szenario, das diese Pläne abdecken sollen. Bei einem Umzug zu einem neuen Anbieter gehören zudem die Auftragsverarbeitungsverträge nach Art. 28 DSGVO und das Verzeichnis der Verarbeitungstätigkeiten auf den neuen Stand. Praktisch heißt das: Migration jetzt im Change- und Auslagerungsmanagement anmelden, nicht erst kurz vor dem Stichtag.
Was sollten Deno-Nutzer jetzt tun?
- Deno-Deploy-Projekte inventarisieren. Jedes Projekt mit Domains, Umgebungsvariablen, geplanten Jobs und Daten in Deno KV erfassen – plus den jeweiligen Verantwortlichen.
- Ziel pro Workload wählen. Request-Handling-Code auf Basis von Web-Standard-APIs lässt sich meist mit überschaubaren Änderungen zu Workers portieren. Code mit Deno-spezifischen APIs oder lang laufenden Prozessen passt oft besser zu Node.js in Containern.
- Datenmigration zuerst planen. KV-Daten und zustandsbehaftete Funktionen umzuziehen dauert länger als Code. Früh exportieren und Wiederherstellung testen.
- Runtime pinnen und beobachten. Bei selbst betriebenem Deno eine Version fixieren, die monatlichen Sicherheitsreleases abonnieren und das Support-Ende ins Risikoregister eintragen.
- JSR-Abhängigkeiten prüfen. JSR bleibt online, aber stellen Sie sicher, dass Ihre CI Pakete nach dem Infrastruktur-Umzug weiterhin auflösen kann, und behalten Sie eine Lockfile.
Häufige Fragen
Kauft Cloudflare Deno?
Ja. Am 9. Oktober 2026 gaben Deno und Cloudflare bekannt, dass das gesamte Deno-Team einschließlich der Mitgründer Ryan Dahl und Bert Belder zu Cloudflare wechselt. Finanzielle Details wurden nicht genannt.
Wann wird Deno Deploy abgeschaltet?
Laut Deno läuft Deno Deploy ab der Ankündigung vom 9. Oktober 2026 noch sechs Monate und wird dann abgeschaltet, also etwa im April 2027. Zahlende Kunden erhalten Hilfe bei der Migration zu Cloudflare Workers.
Wird die Deno-Runtime eingestellt?
Nicht sofort. Deno liefert ein Jahr lang monatliche Releases mit Bugfixes und Sicherheitsupdates. Danach endet die offizielle Entwicklung, die Runtime bleibt aber Open Source und kann von der Community weitergeführt werden.
Was passiert mit JSR?
JSR, die vom Deno-Team geschaffene JavaScript-Paketregistry, bleibt in Betrieb. Ihre Infrastruktur zieht zu Cloudflare um.
Sollten wir zu Cloudflare Workers oder zu Node.js migrieren?
Das hängt von der Last ab. Request-Handling-Code auf Basis von Web-Standard-APIs lässt sich meist mit überschaubaren Änderungen zu Workers portieren. Code mit Deno-spezifischen APIs, lang laufenden Prozessen oder viel lokalem Zustand ist oft leichter auf Node.js in Containern umzuziehen. Entscheiden Sie pro Service, nicht pauschal für das ganze Unternehmen.
Quellen
Deno — Deno is joining Cloudflare
Cloudflare — Deno joins Cloudflare (Ryan Dahl and Kenton Varda)
TechCrunch — Cloudflare acquires Deno to improve its Workers programming model
The New Stack — Cloudflare acquires Node.js creator’s startup that copied its serverless playbook