Zum Inhalt springen

Das Magazin für Web-Handwerker Sonntag, 11. Oktober 2026

DevOps & Server

Deno wechselt zu Cloudflare, Deno Deploy schließt in sechs Monaten

Das gesamte Deno-Team wechselt zu Cloudflare, das Deno Deploy in sechs Monaten abschaltet und die Wartung der Open-Source-Runtime auf ein Jahr begrenzt. JSR und die Bibliothek rusty_v8 überleben den Wechsel und gehen in die Cloudflare-Infrastruktur über.

Illustration Deno rejoint Cloudflare

Ryan Dahl, Schöpfer der Deno-Runtime, hat am 9. Oktober 2026 angekündigt, dass sein gesamtes Team zu Cloudflare wechselt. Der Schritt führt die Arbeit von Deno mit der der Workers- und Durable-Objects-Teams zusammen und markiert das Ende von Deno als eigenständige Runtime und eigenständiger Hosting-Anbieter. Für Entwickler, die Anwendungen auf Deno Deploy betreiben, bedeutet die Ankündigung eine fest terminierte Migration statt eines gewöhnlichen technischen Updates.

Ein klarer Abschaltfahrplan

Deno Deploy, der Serverless-Hosting-Dienst des Unternehmens, läuft noch sechs Monate weiter, bevor er abgeschaltet wird; zahlende Kunden erhalten Unterstützung bei der Migration zu Cloudflare Workers. Die Open-Source-Runtime überlebt länger, aber nicht unbegrenzt: Cloudflare veröffentlicht ein Jahr lang monatliche Releases, beschränkt auf Sicherheits- und Fehlerkorrekturen, bevor die Entwicklung offiziell eingestellt wird. Der Code bleibt quelloffen und kann von jedem weitergeführt werden, der das Projekt fortsetzen möchte.

KomponenteZukunftZeitrahmen
Deno Deploy (Hosting)Abschaltung, Migrationsunterstützung zu Workers für zahlende Kunden6 Monate
Deno-Runtime (Open Source)Monatliche Releases, nur Sicherheits- und Fehlerkorrekturen1 Jahr, danach Entwicklungsstopp
JSR (Paketregistry)Läuft weiter, Infrastruktur wandert zu CloudflareKein Abschalttermin angekündigt
rusty_v8Von Cloudflare gepflegt, Integration in workerd angestrebtKein Zeitplan genannt

Was das für ein laufendes Deployment bedeutet

Ein heute auf Deno Deploy gehostetes Projekt läuft zunächst ohne Unterbrechung weiter, doch das Sechs-Monats-Fenster ist für eine Infrastruktur-Migration knapp bemessen. Der Wechsel zu Cloudflare Workers erfordert eine Anpassung der Deployment-Konfiguration, nicht nur einen geänderten DNS-Eintrag:

# Déploiement historique sur Deno Deploy (CLI deployctl)
deployctl deploy --project=mon-projet main.ts

# Équivalent côté Cloudflare Workers, une fois le projet migré
npx wrangler deploy

Teams, deren Architektur auf Deno-Deploy-spezifischen APIs beruht (integriertes KV, Deno-Deploy-Cron, proprietäre Umgebungsvariablen), steht eine echte Portierungsarbeit bevor, keine einfache URL-Weiterleitung. Eine Bestandsaufnahme der Abhängigkeiten von der Deno-Deploy-Infrastruktur lohnt sich bereits jetzt, bevor sich das Sechs-Monats-Fenster weiter verengt.

Deno Deploy schließt in sechs Monaten; die Open-Source-Runtime hat nur noch ein Jahr Wartung, bevor ihre Entwicklung offiziell eingestellt wird.

Eine dritte Runtime scheidet als eigenständiges Produkt aus

Deno hatte sich seit 2018 als sichere Alternative zu Node.js positioniert, bevor Bun mit einem Leistungsargument dasselbe Terrain besetzte. Mit dieser Übernahme bleiben zwei der drei modernen JavaScript-Runtimes, die mit Node.js konkurrieren, eigenständig im Rennen: Bun auf der einen Seite, der technische Kern von Deno auf der anderen — nun Teil einer Edge-Plattform statt eines eigenständigen Produkts. Auf Hacker News und Lobste.rs dreht sich die Diskussion weniger um die Technik als um die Deutung des Schritts: Konsolidierung des Serverless-Markts rund um Cloudflare statt echter Kontinuität des Deno-Projekts. Wer sich gerade wegen der Unabhängigkeit von den großen Cloud-Anbietern für Deno Deploy entschieden hatte, dem fällt dieses Argument nun weg. Alternativen wie auf Firecracker-Micro-VMs basierende Edge-Funktionen bleiben für alle verfügbar, die Serverless-Hosting außerhalb des Cloudflare-Ökosystems suchen.

Was in der Zwischenzeit zu tun ist

Für ein Projekt, das sich noch in der Entwicklung befindet, ist es am einfachsten, die den zahlenden Kunden versprochenen Migrationsanweisungen abzuwarten, statt überstürzt zu handeln. Für eine bereits produktiv auf Deno Deploy laufende Seite erlaubt eine Bestandsaufnahme der Kommandozeilen-Werkzeuge und plattformspezifischen Abhängigkeiten, den Migrationsaufwand zu beziffern, bevor die Frist erreicht ist. Teams, die lieber selbst die Kontrolle behalten als einem Anbieter zu folgen, können sich auch dem Self-Hosting zuwenden — eine Option, die einen solchen erzwungenen Wechsel künftig vermeidet.

Was man sich merken sollte

Das Deno-Team wechselt zu Cloudflare, Deno Deploy schließt in sechs Monaten, und die Open-Source-Runtime hat nur noch ein Jahr Wartung, bevor die aktive Entwicklung endet. JSR und rusty_v8 überleben und gehen in die Cloudflare-Infrastruktur über. Jede auf Deno Deploy gehostete Anwendung sollte unverzüglich mit der Bestandsaufnahme ihrer Plattformabhängigkeiten beginnen.

Ich sehe in diesem Schritt die Bestätigung eines bekannten, aber oft unterschätzten Risikos: kostenloses oder günstiges Serverless-Hosting bei einem einzigen Anbieter bleibt eine Abhängigkeit, kein gesichertes Gut. Deno-Deploy-Kunden haben sechs Monate Zeit, sich daran zu erinnern; alle anderen sollten schon jetzt die tatsächliche Portabilität ihres eigenen Stacks prüfen, bevor die nächste derartige Ankündigung kommt — Simon Janvier.

Zum Weiterlesen: die offizielle Ankündigung im Deno-Blog.

Teilen LinkedIn Bluesky Hacker News E-mail

Ebenfalls lesenswert