These: Deno Deploy läuft nur noch sechs Monate – wer Agenten auf kleine Plattformen setzt, braucht einen Exit-Plan

Das Deno-Team wechselt zu Cloudflare, und für Teams mit Agenten-Infrastruktur beginnt damit eine Frist. Laut dem Deno-Blog von Ryan Dahl vom Freitag, 9. Oktober 2026, läuft Deno Deploy noch sechs Monate und wird danach abgeschaltet. Die Runtime bekommt noch ein Jahr lang monatliche Releases mit Bugfixes und Sicherheitsupdates. Meine These: Wer Agenten auf kleine Plattformen setzt, kauft die Exit-Frage immer mit. Das ist kein Vorwurf an Deno, sondern eine Architektur-Entscheidung, die Sie treffen sollten, bevor eine Ankündigung sie für Sie trifft.

Abhängigkeit. Mit Frist.

Dieser Artikel ist ein Exit-Plan und kein Nachruf. Er trennt sauber, was Deno und Cloudflare selbst sagen, was ich rechne und was meine Einordnung ist. Am Ende steht eine Checkliste, die Sie Ihrem Team direkt vorlegen können. Auch dann, wenn Sie nie eine Zeile Deno geschrieben haben.

Was Deno am 9. Oktober tatsächlich angekündigt hat

Beginnen wir mit dem, was dasteht. Dahl schreibt, das gesamte Deno-Team wechsle zu Cloudflare („joining“), um die bisherige Arbeit dort weiterzuführen. Ob es sich um eine Übernahme handelt, sagt der Deno-Text nicht. Cloudflare ordnet den gemeinsamen Beitrag unter „Acquisitions“ ein. Zu Summen oder Vertragsbedingungen steht in beiden Quellen nichts, und ich rate hier nicht.

Die konkreten Punkte laut Deno, in eigenen Worten:

• Die Deno-Runtime wird noch ein Jahr lang unterstützt, mit monatlichen Releases für Bugfixes und Sicherheitsupdates. Danach beendet Deno seine eigene Entwicklung der Runtime.
• Die Runtime bleibt Open Source. Deno begrüßt ausdrücklich, wenn andere sie weiterentwickeln.
• Deno Deploy läuft sechs Monate weiter und wird dann abgeschaltet.
• Migrationsunterstützung nennt Deno für zahlende Kundschaft, die zu Cloudflare Workers wechselt.
• JSR läuft weiter, die Infrastruktur zieht zu Cloudflare.
• rusty_v8 wird weiter unterstützt, mit dem Ziel der Integration in workerd.

Dahl nennt als Begründung, die künftige Entwicklungsarbeit solle in die gemeinsame Plattform fließen, statt eine separate Runtime und einen separaten Hosting-Dienst weiterzuentwickeln. Und er räumt ein, das sei eine einschneidende Änderung für alle, die auf Deno gebaut haben. Diese Ehrlichkeit verdient Anerkennung.

Zwei Fristen, ein Kalender – meine Rechnung

Deno nennt keine Kalenderdaten. Das ist wichtig, denn in Foren kursieren schnell „Stichtage“, die so nirgends stehen. Hier meine Rechnung, ausdrücklich als dm-Rechnung gekennzeichnet: Gerechnet ab der Ankündigung am Freitag, 9. Oktober 2026, ergeben sechs Monate rechnerisch etwa April 2027 für Deno Deploy. Zwölf Monate ergeben rechnerisch etwa Oktober 2027 für die Runtime-Releases.

Beides ist eine Orientierung für Ihre Planung, keine Angabe von Deno. Den genauen Zeitpunkt der Abschaltung müssten Sie bei Deno erfragen oder in Ihren Vertragsunterlagen nachlesen, falls dort etwas steht.

Warum rechne ich überhaupt? Weil Planung Daten braucht. Wer „sechs Monate“ hört, denkt an irgendwann. Wer Quartale zählt, merkt, dass Beschaffung, Tests und Freigaben in einem Konzern genau so lange dauern.

Eine Einordnung noch: Wer jetzt von „Kündigungsfrist“ spricht, spitzt zu. Es handelt sich um eine Ankündigung, keine Kündigung im Vertragssinn. Ihre tatsächlichen Rechte hängen an Ihren Verträgen, nicht an einem Blogpost.

Meine These: Wer bei kleinen Plattformen bucht, kauft eine Exit-Frage mit

Jetzt wird es persönlich. Meine These: Agenten-Infrastruktur, also Laufzeit, Zustand und Hosting, konsolidiert sich bei wenigen großen Netzanbietern. Das ist meine Einschätzung, keine Aussage einer Quelle. Belegen kann ich sie mit einem einzelnen Fall nicht, ich sehe aber eine Richtung.

Seien wir ehrlich: Für Agenten-Teams ist die Versuchung groß, mit dem Dienst zu starten, der am schnellsten läuft. Das ist oft ein junger Anbieter mit guter Developer Experience. Völlig vernünftig. Das Problem beginnt, wenn niemand den Tag X mitdenkt.

Dabei geht es nicht um „Startups sind gefährlich“. Das wäre Unsinn, und hier ginge es auch schief: Deno gibt sechs Monate, hält die Runtime offen und bietet Migrationshilfe. Das ist ein geordneter Übergang, kein Hinauswurf. Die These lautet vielmehr: Exit-Fähigkeit ist eine Architektur-Entscheidung. Und die trifft man am Anfang, wenn sie billig ist, nicht am Ende, wenn sie Zeit kostet.

Ein Gedankenspiel: Stellen Sie sich vor, Ihr Team betreibt einen Agenten, der Support-Anfragen vorsortiert. Der Zustand der Gespräche liegt beim Hostinganbieter, die Laufzeit-Eigenheiten stecken im Code, und der Zugang zu den Logs läuft über eine proprietäre Oberfläche. Dann sind sechs Monate keine lange Zeit mehr. Das ist hypothetisch, aber vermutlich nicht weit von manchem Alltag.

Warum Durable Objects für Agenten interessant sind – laut Dahl

Dahl begründet den Schritt auch mit KI. Das Zitat im Wortlaut (aus dem Englischen übersetzt): „Der Bedarf an besseren Abstraktionen ist bei KI besonders groß. Durable Objects vereinen Fähigkeiten, die für Agenten-Harnesses besonders nützlich sind: günstige, serverlose Ausführung, persistenter Zustand, WebSockets und eine High-Level-JavaScript-Schnittstelle.“ Das Original lautet: „Durable Objects bring together capabilities that are particularly useful for agent harnesses.“

Das ist Dahls Einschätzung, nicht der Befund einer unabhängigen Prüfung. Ich behaupte hier nicht, Durable Objects seien die beste Plattform für Agenten. Ich sage nur: Wer das Modell überzeugend findet, sollte wissen, dass es einen eigenen Programmierstil mit sich bringt. Selbst Varda gibt im Cloudflare-Blog die verbreitete Kritik wieder, Apps mit Durable Objects seien nicht nur anders geschrieben, sondern auch anders aufgebaut – und hält dagegen, dass Innovation manchmal genau das verlange.

Und genau hier liegt der Knackpunkt für den Exit: Je spezifischer das Modell, desto wichtiger die Frage, wo sonst es laufen kann.

Cloudflares Gegenargument: Lock-in schadet uns selbst

Jetzt der Teil, der in einem fairen Text nicht fehlen darf. Kenton Varda schreibt im gemeinsamen Beitrag auf dem Cloudflare-Blog ausführlich gegen die Lock-in-Theorie an. Die Theorie, so Varda, laute: Workers sei absichtlich anders gebaut, damit Kundschaft nicht mehr wegkommt. Das sei falsch. Workers sei anders, weil es nach Cloudflares Überzeugung besser sei. Varda nennt als Beispiele die sogenannten Bindings, die den Zugriff auf externe Ressourcen einfacher und sicherer machen sollen, und Durable Objects, mit denen sich Echtzeit-Zusammenarbeit und verteilte Systeme leichter bauen ließen. Das sind Herstellerangaben, die ich als solche wiedergebe.

Zum Lock-in selbst zitiere ich Varda sinngemäß aus dem Englischen: Lock-in schade Cloudflare tatsächlich, und deshalb habe man sich für Open Source entschieden („‚Lock-in‘ actually hurts us — that’s why we went open source“). Er berichtet außerdem von ehemaligen Kunden, die mit workerd abgewandert seien: „And that’s OK!“. Open Source und eine „escape hatch“ seien gutes Geschäft. Als Hintergrund nennt er, dass Shopify 2022 eine Open-Source-Runtime verlangt habe.

Ich finde das Argument ernst zu nehmen. Es ist eine Einschätzung eines Anbieters, aber sie kommt mit einer überprüfbaren Handlung: Der Code ist offen. Prüfen müssen Sie trotzdem selbst, was offen genug ist, und zwar für Ihren konkreten Fall.

workerd und celld: Was zusammengeführt wird

Der zweite Teil der Meldung ist technisch der interessantere. Laut Cloudflare-Blog sollen workerd und celld zusammengeführt werden. Das Ziel: Workers und Durable Objects radikal einfacher selbst hosten, damit Entwickelnde dieselben Bausteine an mehr Orten nutzen können.

Zur Einordnung beschreibt Dahl im selben Beitrag celld als ein Binary in Rust, mit Objektspeicher als einziger externer Abhängigkeit. Veröffentlicht wurde es laut Varda im August. Dahl schreibt zudem, workerd sei bereits Open Source, doch die Unterstützung für Durable Objects sei dort auf eine einzelne Instanz beschränkt. Genau diese Lücke wolle er mit der verteilten Variante schließen. Wer es betreibt, verwaltet laut Dahl viele celld-Instanzen und einen einzigen Objektspeicher-Bucket.

Einen Zeitplan für die Zusammenführung nennen die Quellen nicht. Das bleibt eine offene Frage. Und mit ihr hängt eine zweite zusammen: Was passiert in der Übergangszeit mit der Reife der Self-Hosting-Variante?

Dahl lädt außerdem Teams, die Agenten in großem Maßstab auf eigener Infrastruktur betreiben wollen, ausdrücklich zur Kontaktaufnahme ein. Das ist ein Angebot. Ob und wie es greift, wird die Praxis zeigen.

Was Deno nicht sagt – und was Sie deshalb offen lassen sollten

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptMoving boxes stacked next to a server rack in an office, a clipboard checklist without readable text on top, symbolizing a planned platform exit. Photorealistic editorial magazine photo, natural light, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks, no recognizable products of real brands.

Gute Berichterstattung nennt auch Lücken. Folgendes steht in den Quellen nicht:

• Ein Kalenderdatum für die Abschaltung von Deno Deploy.
• Die Zahl der betroffenen Kundschaft.
• Migrationshilfe für Nicht-Zahlende. Deno nennt sie nur für zahlende Kundschaft. Daraus folgt nicht, dass es für andere keine gibt. Die Quelle schweigt dazu.
• Ein Zeitplan für die Zusammenführung von workerd und celld.
• Details zu Deno Sandbox, Subhosting oder Fresh. Deren Status ist in den Quellen nicht ausgeführt.
• Preise für Workers.

Wer eines dieser Produkte nutzt, sollte nicht raten, sondern nachfragen. Mehr kann ich aus den Quellen seriös nicht ableiten.

Plattformmacht bei Agenten: Das Muster kennen Sie schon

Der Deno-Fall steht nicht allein. Wir bei digital-magazin.de haben zuletzt beschrieben, wie Googles Gemini agent das Prompt-Fenster zum Gatekeeper macht. Anderes Thema, ähnliche Frage: Wer kontrolliert den Zugang? Und wie teuer wäre ein Wechsel?

Auch bei den Kosten lohnt der Blick auf die Abhängigkeit. Wer Modelle über Routing steuert, ist an dessen Logik gebunden. Dazu passt unser Text zum Routing mit Claude Haiku 5.5. Ich will hier keine Zweitstory aufmachen, nur den Faden zeigen: Abhängigkeiten stecken in Laufzeit, Modell und Hosting zugleich.

Ein dritter Punkt ist die Laufzeitgrenze. Ohne klar definierte Ausführungsgrenzen wird jeder Umzug zum Risiko. Wir bei digital-magazin.de haben das am Beispiel von SAP und Nvidia mit der Execution-Boundary erläutert.

Mythos und Realität: Open Source als Exit-Versicherung

Der Mythos: Solange der Code offen liegt, kann Ihnen nichts passieren. Fällt der Anbieter weg, übernehmen Sie die Runtime einfach selbst. Das klingt beruhigend. Es ist meine Einschätzung, dass dieser Satz in vielen Teams unausgesprochen als Absicherung durchgeht.

Die Realität, ebenfalls meine Einschätzung: Open Source ist eine Tür, kein Umzugswagen. Die Tür steht offen, das zählt. Aber durchtragen müssen Sie Ihre Last allein. Wer eine Runtime selbst weiterbetreibt, übernimmt Sicherheitsupdates, Personal und Betrieb. Falsch ist also die Annahme, offener Code nehme Ihnen die Arbeit ab. Er nimmt Ihnen nur das Verbot, sie zu erledigen.

Dazu kommt eine unbequeme Frage, die selten gestellt wird: Wer im Team versteht die Interna dieser Runtime gut genug, um eine Sicherheitslücke zu bewerten, einen Patch einzuspielen und danach noch ruhig zu schlafen? Ein Fork ist schnell gezogen. Ihn über Jahre zu pflegen, ist ein eigenes Vorhaben mit eigenem Budget, eigenen Zuständigkeiten und eigenem Bereitschaftsdienst. Punkt.

Der Mythos hat allerdings einen wahren Kern, und den möchte ich fair benennen. Deno lässt die Runtime ausdrücklich offen und lädt andere dazu ein, sie weiterzuentwickeln. Das ist mehr, als viele Anbieter in einer solchen Lage tun. Cloudflare wiederum verweist auf workerd als Ausweg für alle, die nicht auf der eigenen Plattform bleiben wollen. Beides sind echte Angebote, und beides senkt die Hürde. Aber: Eine gesenkte Hürde ist keine beseitigte Hürde.

Mein Urteil dazu: Open Source verbessert Ihre Verhandlungsposition und Ihre Optionen. Eine Versicherung im strengen Sinn ist es nicht, denn eine Versicherung zahlt, wenn der Schaden eintritt. Hier zahlen Sie, in Arbeitszeit und Know-how, und zwar genau dann, wenn ohnehin viel anderes brennt. Wer offenen Code als Exit-Strategie einplant, sollte deshalb gleich mitrechnen, wer ihn betreibt und womit.

Warum Agenten schwerer umziehen als eine Website

Eine Website lässt sich im Zweifel kopieren: Dateien rüber, Domain umstellen, fertig. Bei Agenten ist das in meiner Einordnung ein Trugschluss. Sie sind keine Auslieferung von Inhalten, sondern laufende Prozesse mit Gedächtnis. Und Gedächtnis zieht man nicht einfach um.

Erstens halten Agenten Zustand. Gesprächsverläufe, Aufgabenstatus, Zwischenergebnisse: All das lebt irgendwo, und dieses Irgendwo gehört meist zur Plattform. Zweitens brauchen Agenten langlebige Verbindungen, die offen bleiben, während Arbeit läuft. Drittens besitzen sie Tool-Zugänge und Secrets, also Schlüssel zu Systemen, die Sie beim Umzug neu ausrollen, rotieren und prüfen müssen. Viertens brauchen sie Protokolle, damit später nachvollziehbar bleibt, was der Agent wann und warum getan hat. Wer dafür Auditierbarkeit verspricht, muss diese Spuren auch nach einem Wechsel noch lesen können.

Nun der Punkt, der mich besonders beschäftigt. Genau diese Dinge nennt Dahl als Stärken von Durable Objects: persistenter Zustand und WebSockets. Das ist aus seiner Sicht ein Verkaufsargument, und es kann ein gutes sein. Meine Einschätzung ist trotzdem: Was ein Modell für Agenten attraktiv macht, bindet sie auch. Eine Stärke, die Zustand und Verbindungen an einen bestimmten Ort knüpft, ist zugleich eine Stelle, an der Sie sich später losreißen müssen. Beides gehört zusammen. Das eine gibt es nicht ohne das andere.

Stellen Sie sich vor, Ihr Team will einen Agenten von einer Plattform auf eine andere verlegen. Der Code lässt sich vielleicht übertragen. Aber was passiert mit den laufenden Aufgaben, die gerade halb erledigt sind? Wohin wandern die Gesprächsverläufe, und in welchem Format? Wer rotiert die Zugangsdaten, ohne dass der Agent zwischendurch ins Leere greift? Und lässt sich später belegen, was vor dem Umzug geschah, wenn die alten Protokolle an der alten Stelle liegen bleiben?

Das sind keine Detailfragen, sondern der eigentliche Umzug. Der Code ist der kleinere Teil. Schwer wiegt alles, was der Agent im Betrieb angesammelt hat.

Deshalb mein Rat, ausdrücklich als Einschätzung: Behandeln Sie Zustand, Verbindungen, Secrets und Protokolle von Anfang an als eigene Bausteine mit eigener Exit-Frage. Wer sie sauber trennt und exportierbar hält, verkürzt jeden späteren Wechsel. Wer sie mit der Plattform verschmelzen lässt, bekommt Komfort jetzt und eine Rechnung später.

Die Exit-Checkliste für Agenten-Infrastruktur

Genug Analyse. Hier die Checkliste, die ich Ihnen empfehle. Sie gilt für Deno, aber ebenso für jeden anderen Anbieter, bei dem Ihr Agent läuft. Das ist meine Empfehlung, keine Vorgabe der Quellen.

1. Vertrag prüfen. Welche Kündigungs- und Abschaltfristen sichert Ihr Vertrag tatsächlich zu, und was sagt er zu Migrationszusagen? Eine Ankündigung per Blogpost ist kein Vertragsbestandteil.
2. Datenexport klären. Können Sie Zustand, Logs und Secrets vollständig und in einem brauchbaren Format herausholen? Bei Secrets zählt zusätzlich, wie Sie sie sicher neu ausrollen.
3. Laufzeit abstrahieren. Läuft Ihr Agent auf einer offenen Runtime und nutzt er Standard-APIs? Je mehr plattformspezifische Eigenheiten im Code stecken, desto teurer der Umzug.
4. Self-Host-Option bewerten. Gibt es eine Variante, die Sie auf eigener Infrastruktur betreiben könnten, und wie ausgereift ist sie? Bei Workers lohnt der Blick auf workerd und celld, mit der Einschränkung, dass der Zeitplan der Zusammenführung offen ist.
5. Migration proben. Haben Sie den Umzug einmal geübt, auch nur im Kleinen? Ein Probelauf zeigt die Stolperstellen, die kein Dokument verrät.

Fünf Punkte. Kein Hexenwerk. Wer sie ehrlich beantwortet, kennt seine Abhängigkeit, und das ist mehr, als die meisten Teams von sich behaupten können.

Was das für Teams auf Deno konkret heißt

Zuerst die gute Nachricht: Für die Runtime gibt es laut Deno noch ein Jahr Releases, und sie bleibt Open Source. Wer sie nutzt, hat Zeit, ohne Zeitdruck zu planen. Rechnerisch (dm-Rechnung, gerechnet ab der Ankündigung am 9. Oktober 2026) läuft diese Phase bis etwa Oktober 2027.

Für Deno Deploy ist der Takt enger. Wer dort Agenten betreibt, sollte den Weg zu Cloudflare Workers prüfen, denn dafür nennt Deno Migrationsunterstützung für zahlende Kundschaft. Rechnerisch endet der Betrieb etwa im April 2027, wieder nur als meine Rechnung, nicht als Angabe von Deno.

Wer sich gegen Workers entscheiden will, sollte früh klären, ob Alternativen zum eigenen Code passen. Das ist keine Empfehlung für oder gegen einen Anbieter, nur der Hinweis, die Entscheidung nicht erst im letzten Quartal zu treffen.

Und JSR? Läuft weiter, die Infrastruktur zieht zu Cloudflare. Wer Pakete dort nutzt, bleibt laut Deno versorgt. Auch hier gilt: im Auge behalten, ohne in Alarm zu verfallen.

Und jetzt?

Ich fasse meine Einschätzung ohne Pathos zusammen: Das Deno-Team macht einen geordneten Übergang, Cloudflare argumentiert offen gegen Lock-in, und trotzdem bleibt die Lehre unbequem. Ihre Agenten-Infrastruktur gehört zu den wenigen Dingen, bei denen ein Anbieterwechsel nicht nur Technik ist, sondern ein Kalenderproblem.

Mal ehrlich: Wie viele Ihrer Systeme könnten Sie in sechs Monaten verlegen, ohne dass jemand schlecht schläft? Und wenn die Antwort „keines“ lautet, welcher der fünf Punkte der Checkliste ist dann der erste, den Sie am Montag angehen?