Der Wechsel des Deno-Teams zu Cloudflare wurde am 9. Oktober 2026 von Deno-Gründer Ryan Dahl im offiziellen Deno-Blog bekannt gegeben, und Cloudflare bestätigte den Plan noch am selben Tag in einem eigenen Blogbeitrag. Das ist kein gewöhnlicher Personalwechsel: Während das gesamte Team wechselt, beginnt für Denos eigenen Hostingdienst Deno Deploy der Countdown bis zur Abschaltung, und für die eigenständige Laufzeitumgebung bleibt nur noch ein Jahr offizieller Pflege.
Was Cloudflare wirklich fehlt, sind selbst hostbare Durable Objects
Cloudflare benannte die Lücke im Beitrag vom selben Tag ungewöhnlich offen. Die quelloffene Laufzeitumgebung workerd nutzt zwar denselben Code wie die Produktion, ihre Durable-Objects-Umsetzung ist jedoch auf eine einzelne Instanz beschränkt: gut genug für lokale Tests, aber nicht skalierbar für Self-Hosting. Cloudflares eigenes Produktions-Routing für Objekte hängt wiederum von hunderten Standorten und einem Stapel externer Dienste ab und eignet sich damit schlecht für das Rechenzentrum eines Kunden. Celld, im August 2026 vom Deno-Team veröffentlicht, füllt genau diese Lücke: Es ist eine quelloffene Umsetzung von Workers und Durable Objects, von Anfang an für Self-Hosting und horizontale Skalierung entworfen. Ryan Dahl und Bert Belder werden nun die Arbeit leiten, cellds Code und Ideen zurück in workerd zu überführen und Self-Hosting zu einem unterstützten Weg für das Workers-Programmiermodell zu machen; weitere Details sollen in den kommenden Monaten folgen.
Zwei Countdowns: sechs Monate für Deploy, ein Jahr für die Runtime
Für Teams, die Deno heute einsetzen, zählt der Zeitplan mehr als die Vision. Deno Deploy läuft noch sechs Monate und wird dann abgeschaltet; zahlenden Kunden wird Migrationshilfe in Richtung Cloudflare Workers angeboten. Die Deno-Runtime erhält ein weiteres Jahr lang monatliche Fehler- und Sicherheitskorrekturen, danach beendet das ursprüngliche Team die Entwicklung; der Code bleibt quelloffen, und die Community kann ihn weiterführen. Die Paketregistrierung JSR bleibt in Betrieb, ihre Infrastruktur zieht zu Cloudflare um, und die Komponente rusty_v8 wird weiter gepflegt, mit dem Ziel, sie in workerd zu integrieren. Sechs Monate weitergerechnet müssen Dienste, die im April 2027 noch auf Deploy laufen, bis dahin migriert sein – und dieses Zeitfenster läuft seit dem Tag der Ankündigung.
Warum auch Agenten-Entwickler hinschauen
Dahl sprach in seiner Ankündigung ausdrücklich das Agenten-Szenario an: Durable Objects verbinden günstige serverlose Ausführung, dauerhaften Zustand und WebSocket-Verbindungen in einem einzigen Objekt – nahe an dem Fundament, das langlebige Agenten-Gerüste brauchen –, und er lud Teams, die Agenten im großen Maßstab bauen, zur direkten Kontaktaufnahme ein. Wo sich die Ausführungsschicht bündelt, entscheidet unmittelbar über Kostenstruktur und Einsatzgrenzen von Agentenprodukten, zumal der Agenten-Traffic den menschlichen bereits überholt hat. Wenn Workers identisch im Cloudflare-Netz und auf kundeneigenen Servern läuft, müssen Agenten-Anbieter nicht mehr zwischen Plattformkomfort und Datenhaltung im eigenen Netz wählen.
Bis die Versprechen ausgeliefert sind, bleibt all das eine Roadmap. Die Werkzeuge rund um selbst gehostetes workerd sind genau der Teil, den Cloudflare nach eigenem Eingeständnis vernachlässigt hat, und ob das Deno-Team diese Lücke schließen kann, hängt davon ab, was in den nächsten Monaten tatsächlich erscheint. Für Deno-Nutzer ist die Entscheidung einfacher: zuerst die Migration am Abschaltdatum von Deploy ausrichten, dann beurteilen, ob sich das selbst gehostete workerd weiter zu verfolgen lohnt.
