# Deno geht zu Cloudflare — und die Runtime hat noch ein Jahr

> Das Deno-Team wechselt zu Cloudflare, Deno Deploy schließt in sechs Monaten, die Runtime bekommt noch ein Jahr Fixes. Was genau angekündigt wurde, wer betroffen ist und was du jetzt prüfen solltest.

Source: https://www.jpkc.com/db/blog/deno-cloudflare/

Ende August habe ich hier über [Bun und Anthropic](https://www.jpkc.com/db/blog/bun-anthropic-claude-code/) geschrieben: Die Runtime, die in der Claude-Code-Binary steckt, gehört seit Dezember 2025 einem KI-Unternehmen. Knapp sechs Wochen später folgt die nächste Nachricht dieser Art, und sie ist deutlich härter. Am 9. Oktober 2026 hat Ryan Dahl angekündigt, dass das gesamte Deno-Team zu Cloudflare wechselt. Der Satz, der in der Diskussion danach am meisten Aufmerksamkeit bekam, steht weit unten in seinem Beitrag: Nach einem weiteren Jahr endet die Entwicklung der Deno-Runtime.

Auf den Tag genau zwei Jahre nach Deno 2.0 ist das kein Kauf, bei dem ein Produkt unter neuem Dach weiterläuft, sondern ein geordneter Ausstieg. In diesem Artikel ordne ich ein, was genau angekündigt wurde, warum Dahl diesen Schritt geht, wer außer den direkten Deno-Nutzern betroffen ist — die Liste ist länger, als du vielleicht denkst — und was du jetzt prüfen solltest. Wo ich Fristen nenne, die nicht offiziell sind, sage ich das dazu.

## Die Kurzfassung

| Was | Was passiert | Bis wann |
|---|---|---|
| **Deno-Runtime** | Monatliche Releases mit Bugfixes und Sicherheitsupdates, danach Ende der Entwicklung durch das Team; bleibt Open Source (MIT) | ein Jahr, also etwa bis Oktober 2027 |
| **Deno Deploy** | Läuft weiter und wird dann abgeschaltet; zahlende Kunden bekommen Migrationshilfe zu Cloudflare Workers | sechs Monate, also etwa bis April 2027 |
| **JSR** | Läuft weiter, die Infrastruktur zieht zu Cloudflare | keine Frist genannt |
| **rusty_v8** | Wird weiter unterstützt und soll in Cloudflares Runtime `workerd` integriert werden | keine Frist genannt |
| **celld** | Wird mit `workerd` zusammengeführt | laut Cloudflare „in den kommenden Monaten" mehr |

Die Monatsangaben in der letzten Spalte sind meine Rechnung ab dem 9. Oktober. Ein konkretes Abschaltdatum für Deno Deploy oder eine Migrationsanleitung zu Workers gibt es zum Zeitpunkt dieses Artikels noch nicht.

## Was genau angekündigt wurde

Es gibt zwei Primärquellen, und es lohnt sich, beide zu lesen: Dahls Beitrag [„Deno is joining Cloudflare"](https://deno.com/blog/cloudflare) (englisch) auf dem Deno-Blog und den gemeinsamen Beitrag von Dahl und Kenton Varda, dem technischen Kopf hinter Cloudflare Workers, auf dem [Cloudflare-Blog](https://blog.cloudflare.com/deno-joins-cloudflare/) (englisch). Cloudflare führt ihn dort unter dem Schlagwort „Acquisitions"; einen Kaufpreis nennt keine der beiden Seiten.

Der Kern steht in Dahls Beitrag als nüchterne Liste. Zur Runtime: „We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development." Zu Deno Deploy: Der Dienst läuft noch sechs Monate und wird dann abgeschaltet; zahlenden Kunden wird beim Umzug zu Cloudflare Workers geholfen. Die Paket-Registry **JSR** läuft weiter, ihre Infrastruktur wandert zu Cloudflare. Und **rusty_v8**, die Rust-Bindung an die V8-Engine, auf der Deno aufbaut, wird weiter gepflegt und soll in `workerd` einfließen.

Dahl begründet das mit einer Fokusentscheidung: Das Team stecke seine künftige Arbeit in eine gemeinsame Plattform, statt eine eigene Runtime und einen eigenen Hosting-Dienst weiterzuentwickeln. Er schreibt selbst, dass das eine folgenreiche Änderung für alle ist, die auf Deno gebaut haben.

Was in beiden Beiträgen **nicht** steht: was aus Deno KV, Deno Sandbox, dem Subhosting-Angebot für Plattformbetreiber und dem Web-Framework Fresh wird. Wenn du eines davon nutzt, fehlt dir im Moment schlicht die Information.

## Warum Dahl diesen Schritt geht

Die Begründung erzählt Dahl im Cloudflare-Beitrag als Bogen, der mit seiner ersten Node.js-Demo beginnt, und sie ist schlüssiger, als die Schlagzeile „Deno gibt auf" vermuten lässt.

In einer Berliner Lagerhalle, schreibt er, habe er Node.js einst mit einem IRC-Server in rund 500 Zeilen JavaScript vorgestellt — das war 2009 auf der JSConf EU. Was ihn an dieser Demo immer gestört habe: Es war ein einzelner Server, sogar ein einzelner Thread. Wer IRC skalieren will, braucht mehrere Maschinen, die sich die Channels teilen, dazu Speicher für Verlauf und Benutzerkonten. 2018 folgte, ebenfalls auf der JSConf EU, sein Vortrag „10 Things I Regret About Node.js" und daraus Deno — eine Runtime mit Berechtigungsmodell, TypeScript ohne Build-Schritt und eingebauter Toolchain. Dahl schreibt heute selbst, dass Deno zwar das Schreiben von JavaScript verbessert habe, aber nicht grundlegend verändert, was Entwickler um die Runtime herum zusammenbauen müssen: Verteilung, Zustand, Speicher, Skalierung.

Die Antwort darauf fand er nach eigener Darstellung in Cloudflares **Durable Objects**. Ein Durable Object ist ein kleiner, einzeln adressierbarer Server mit eigener SQLite-Datenbank; sein JavaScript läuft single-threaded, er verwaltet WebSockets, und auf seine lokale Datenbank greift er synchron zu. Baust du einen Chat mit einem Durable Object pro Channel, hast du Daten und Verbindungen automatisch aufgeteilt — die Skalierung steckt im Programmiermodell, nicht in der Infrastruktur.

Das Problem: Außerhalb von Cloudflare ließ sich dieses Modell kaum betreiben. Cloudflares Runtime `workerd` ist seit 2022 Open Source, unterstützt Durable Objects aber nur als Einzelinstanz. Deshalb hat das Deno-Team **celld** gebaut, im August 2026 erstmals veröffentlicht: eine einzelne, in Rust geschriebene Binary, die [selbst gehostete, verteilte Durable Objects](https://celld.dev/) (englisch) bereitstellt und als einzige externe Abhängigkeit einen Objektspeicher braucht. Bestehende Cloudflare-Apps sollen darauf unverändert laufen, sofern sie nur die unterstützten APIs nutzen. Dahl schreibt, der Betrieb von Deno Deploy habe ihm gezeigt, wie verflochten Cloud-Infrastruktur werden kann; celld sei das Gegenteil davon.

Bemerkenswert offen ist Kenton Varda in seinem Teil des Beitrags. Er räumt ein, dass Cloudflare bei `workerd` das Ökosystem drumherum vernachlässigt habe — Cloudflare habe die Runtime veröffentlicht und gehofft, die Community passe sie an jede Umgebung an, und das sei nicht passiert. Die skalierbare Durable-Objects-Unterstützung für Selbsthoster habe immer gefehlt, mit TODO-Kommentaren seit der ersten Version. celld sei genau das gewesen, was Cloudflare selbst bauen wollte. Ryan Dahl und Deno-Mitgründer Bert Belder sollen nun das Selbsthosting von `workerd` zu einem vollwertig unterstützten Weg machen und dafür Code und Ideen aus celld in `workerd` übernehmen.

Varda nutzt den Beitrag auch, um einem Vorwurf zu widersprechen, der laut Varda im Netz verbreitet ist: Workers sei absichtlich anders gebaut, um Kunden einzusperren. Sein Gegenargument ist, dass große Kunden wie Shopify ohne Open-Source-Runtime nie unterschrieben hätten und dass es ehemalige Kunden gibt, die mit `workerd` abgewandert sind. Ob du das als Entwarnung beim Lock-in liest, hängt davon ab, wie sehr du darauf vertraust, dass das Selbsthosting wirklich gleichwertig wird.

## Wer betroffen ist — mehr als die Deno-Nutzer

Auf den ersten Blick betrifft die Ankündigung nur zwei Gruppen: Kunden von Deno Deploy, die bis etwa April 2027 umziehen müssen, und Entwickler, die Deno als lokale Runtime oder für `deno compile`-Binaries nutzen. Die zweite Gruppe hat mehr Zeit, aber keine Perspektive über Oktober 2027 hinaus, wenn sich niemand findet, der die Entwicklung übernimmt.

Spannender ist, wer Deno *indirekt* nutzt, ohne es zu wissen:

- **Supabase Edge Functions** laufen auf Supabases eigener [Edge-Runtime](https://github.com/supabase/edge-runtime) (englisch), die auf Deno basiert. Ein Supabase-Mitarbeiter schrieb in der [Hacker-News-Diskussion](https://news.ycombinator.com/item?id=50031340) (englisch), Supabase betreibe eigene Infrastruktur und hänge nicht an Denos Hosting. Ziel sei, das Nachfolgeprodukt **Supabase Compute** — laut [Supabase-Website](https://supabase.com/compute) (englisch) derzeit in einer privaten Alpha — für bestehende Edge Functions „well before Deno's support window closes" verfügbar zu machen; einen öffentlichen Zeitplan gebe es noch nicht.
- **Netlify Edge Functions** beschreibt Netlify in seiner [Dokumentation](https://docs.netlify.com/build/edge-functions/overview/) (englisch) als „secure runtime based on Deno". Laut einem Netlify-Mitarbeiter in derselben Diskussion nutzt Netlify Denos verwaltete Infrastruktur nicht mehr, wohl aber weiterhin die Deno-Runtime.
- **Slack** setzt für seine „Run on Slack"-Apps auf ein [Deno-SDK](https://github.com/slackapi/deno-slack-sdk) (englisch). Eine Reaktion von Slack habe ich bis zum Zeitpunkt dieses Artikels nicht gefunden.
- **yt-dlp**, der verbreitete Video-Downloader, empfiehlt Deno als [JavaScript-Runtime](https://github.com/yt-dlp/yt-dlp/wiki/EJS) (englisch) zum Lösen der JavaScript-Challenges von YouTube und aktiviert es standardmäßig. Wenn Deno auf deinem Rechner installiert ist, ohne dass du dich erinnerst, warum — das könnte der Grund sein.
- **Val Town** führt den Code seiner Nutzer laut eigener [Dokumentation](https://docs.val.town/reference/runtime/) (englisch) auf der Deno-Runtime aus.

Keine dieser Plattformen hat ein akutes Problem. Supabase und Netlify betreiben ihre Runtimes selbst, und ein Jahr Sicherheitsupdates ist eine ordentliche Übergangsfrist. Aber jede von ihnen muss jetzt entscheiden, ob sie einen Fork pflegt, auf etwas anderes umsteigt oder auf eine Community-Übernahme hofft. Wenn du auf einer dieser Plattformen Funktionen betreibst, lohnt es sich, deren Ankündigungen in den nächsten Monaten im Blick zu behalten.

Gelassen bleiben kannst du bei **JSR** — die Registry läuft weiter, und Pakete dort sind ohnehin für mehrere Runtimes gedacht — und bei allem, was du über npm beziehst.

## Was du jetzt tun solltest

1. **Bestandsaufnahme.** Wo läuft bei dir Deno? Direkt in Projekten, als `deno compile`-Binary, in CI-Pipelines, indirekt über Supabase, Netlify, Slack oder Val Town, lokal über yt-dlp?
2. **Deno Deploy zuerst.** Das ist die kürzeste Frist. Wenn du zahlender Kunde bist, warte auf das angekündigte Migrationsangebot, aber plane schon jetzt: Workers ist nicht Deno, und alles, was an Deno-spezifischen APIs hängt — `Deno.serve`, Deno KV, Dateisystemzugriffe —, muss umgebaut werden.
3. **Deno-spezifische APIs zählen.** Code, der nur Web-Standards (`fetch`, `Request`, `Response`, Web Streams) und npm-Pakete nutzt, lässt sich mit überschaubarem Aufwand auf Node.js, Bun oder Workers bringen. Je mehr `Deno.*`-Aufrufe, desto größer der Umbau.
4. **Updates weiter einspielen.** Die monatlichen Releases sind Sicherheitsupdates — gerade in der Auslaufphase solltest du sie nicht auslassen.
5. **Bei Neuprojekten nicht mehr auf Deno setzen**, solange keine glaubwürdige Fortführung durch die Community angekündigt ist.

## Meine Einordnung

Mit dieser Nachricht arbeiten die Teams hinter zwei der drei großen serverseitigen JavaScript-Runtimes für Unternehmen, deren Hauptgeschäft etwas anderes ist: Bun bei Anthropic, das Deno-Team bei Cloudflare. Bun lebt dabei als Produkt weiter, Deno nicht. Node.js bleibt als einziges unter dem Dach einer neutralen Stiftung, der OpenJS Foundation.

Das ist kein Urteil über die Qualität von Bun oder Deno. Deno hat das JavaScript-Ökosystem spürbar vorangebracht — Berechtigungen, TypeScript ohne Build-Schritt, Web-Standard-APIs auf dem Server; vieles davon ist inzwischen auch in Node.js angekommen. Aber es zeigt, dass die Frage „Wem gehört die Runtime, und was passiert, wenn dessen Prioritäten sich ändern?" zur Technologieentscheidung dazugehört. Im Bun-Artikel habe ich die Governance als den Punkt beschrieben, den ich am belastbarsten finde: keine Stiftung, keine Rückfallzusage für den Fall, dass der Eigentümer die Richtung ändert — und das Fork-Recht der MIT-Lizenz als eigentliche Versicherung. Bei Deno ist dieser Fall jetzt eingetreten, und zwar nicht wegen Geldmangel oder schlechter Technik, sondern weil das Team ein größeres Ziel bei einem anderen Unternehmen besser verfolgen kann.

Für diese Seite ändert sich unmittelbar nichts. Sie baut mit Eleventy auf Node.js, abgesichert so, wie ich es in [meinem Node.js-Setup](https://www.jpkc.com/db/blog/nodejs-npm-absichern/) beschrieben habe: Socket Firewall, exakt gepinnte Versionen, `npm ci`. Und sie liegt nicht hinter Cloudflare, wie ich im Beitrag zu den [Crawler-Defaults](https://www.jpkc.com/db/blog/cloudflare-crawler-defaults/) erwähnt habe. Die Fork-Frage aus dem Bun-Artikel ist bei Deno jetzt aber keine Theorie mehr: Ob sich jemand findet, der eine Runtime aus V8, Rust und einer kompletten Toolchain über Jahre weiterpflegt, wird zeigen, wie viel diese Versicherung in der Praxis wert ist.

Die technische Idee hinter dem Wechsel halte ich trotzdem für überzeugend. Wenn Workers und Durable Objects tatsächlich ohne Abstriche selbst gehostet werden können, wäre das ein echter Gewinn: ein Programmiermodell, das verteilte Anwendungen einfach macht, ohne dass du dich an einen Anbieter bindest. Ob das gelingt, entscheidet sich nicht in Ankündigungen, sondern in den Releases der nächsten Monate.

## FAQ

### Wird Deno eingestellt?

Die Entwicklung durch das Deno-Team endet nach einem weiteren Jahr, in dem es monatliche Releases mit Bugfixes und Sicherheitsupdates gibt. Der Code bleibt Open Source unter MIT-Lizenz; Dahl lädt ausdrücklich andere ein, die Entwicklung fortzuführen. Ob sich dafür jemand findet, ist offen.

### Wann wird Deno Deploy abgeschaltet?

Laut Ankündigung vom 9. Oktober 2026 läuft Deno Deploy noch sechs Monate, rechnerisch also bis etwa April 2027. Ein konkretes Datum hat Deno bisher nicht genannt. Zahlende Kunden sollen Unterstützung beim Umzug zu Cloudflare Workers bekommen.

### Was wird aus JSR?

JSR läuft weiter, die Infrastruktur wird zu Cloudflare verlagert. Pakete, die du dort veröffentlicht hast oder von dort beziehst, bleiben verfügbar.

### Was ist celld?

Ein Open-Source-Server des Deno-Teams, der Cloudflares Durable Objects und Workers selbst gehostet und verteilt über mehrere Maschinen betreibt. Er besteht aus einer einzelnen Rust-Binary und braucht als einzige externe Abhängigkeit einen Objektspeicher wie S3. celld soll mit Cloudflares Open-Source-Runtime `workerd` zusammengeführt werden.

### Was wird aus dem Markenstreit um „JavaScript"?

Deno hatte im November 2024 beim US-Markenamt die Löschung von Oracles Marke „JavaScript" beantragt. Laut Verfahrensakte ruht das Verfahren seit dem 28. August 2026 auf Antrag von Oracle mit Zustimmung von Deno, weil die Parteien über einen Vergleich verhandeln. In den beiden Ankündigungen kommt das Thema nicht vor.

## Weiterlesen

Die Geschichte der anderen gekauften Runtime steht in [Anthropic und Bun](https://www.jpkc.com/db/blog/bun-anthropic-claude-code/). Wie ich Node.js-Projekte gegen Supply-Chain-Angriffe absichere, beschreibt [Sicheres Arbeiten mit Node.js und npm](https://www.jpkc.com/db/blog/nodejs-npm-absichern/), und warum diese Seite überhaupt mit Eleventy gebaut wird, [Warum 11ty](https://www.jpkc.com/db/blog/warum-11ty/).

Die Originalquellen: Ryan Dahls Beitrag [„Deno is joining Cloudflare"](https://deno.com/blog/cloudflare) mit allen Fristen und der gemeinsame Beitrag von Ryan Dahl und Kenton Varda auf dem [Cloudflare-Blog](https://blog.cloudflare.com/deno-joins-cloudflare/) mit der technischen Begründung.