Deno Deploy wird eingestellt: Was Ihre Migration nachweisen muss

Das Ende von Deno Deploy stellt ein Startup vor zwei Entscheidungen: Wo soll die Anwendung laufen, und wer wird ihre Laufzeitumgebung weiter pflegen? Deno hat sechs weitere Monate Betrieb für Deploy und ein weiteres Jahr monatlicher Fehlerbehebungen und Sicherheitsupdates für die Laufzeitumgebung angekündigt. Bevor Sie den Produktivverkehr umstellen, weisen Sie nach, dass die neue Plattform das Verhalten bewahrt, auf das Ihre Kunden angewiesen sind. Denos Ankündigung vom 9. Oktober nennt diese beiden Zeiträume.

Eine Startseite, die auf Workers lädt, ist ein brauchbares erstes Ergebnis. Damit ist noch nicht nachgewiesen, dass eine Sitzung privat bleibt, gleichzeitige Schreibzugriffe korrekt bleiben oder sich eine gescheiterte Umstellung rückgängig machen lässt. Solche Tests sollten darüber entscheiden, ob die Migration freigegeben werden kann.

Dieser Prüfrahmen richtet sich an Entwicklungsverantwortliche, deren Anwendungen bereits von Deno abhängen. Die folgenden Beispiele sind vorgeschlagene Tests, keine Messungen realer Kundenmigrationen und kein Versprechen, dass jede Anwendung denselben Weg nehmen kann.

Welche Deno-Frist gilt für Ihre Anwendung?

Die Hosting-Frist betrifft Deno Deploy; die Wartungsfrist betrifft die Deno-Laufzeitumgebung. Klären Sie, welche dieser Abhängigkeiten Ihre Produktivanwendung tatsächlich hat, bevor Sie die Arbeiten planen.

In der Ankündigung vom 9. Oktober erklärt Deno, dass das gesamte Team zu Cloudflare wechselt. Deploy bleibt sechs Monate in Betrieb und wird anschließend eingestellt. Die Laufzeitumgebung erhält noch ein Jahr lang monatliche Fehlerbehebungen und Sicherheitsupdates. Danach beendet das Team seine Entwicklungsarbeit; die Laufzeitumgebung bleibt Open Source. JSR besteht weiter, seine Infrastruktur zieht zu Cloudflare um. Zahlenden Kunden wird Unterstützung beim Wechsel zu Workers angeboten. Diese Zusagen nennen weder einen festen Abschaltzeitpunkt noch den vertraglichen Umfang der Unterstützung für einzelne Kunden oder ein künftiges Wartungsteam für die Laufzeitumgebung. Klären Sie diese Einzelheiten direkt, wenn Sie Ihre Umstellung planen.

Eine Anwendung kann die Laufzeitumgebung nutzen, ohne Deploy zu verwenden. Eine Build-Pipeline mit deno task ist anders betroffen als eine API, deren Anfragen auf Deploy enden. Auch ein anderer Anbieter kann eine Deno-kompatible Laufzeitumgebung einsetzen: Supabase beschreibt seine Edge Functions so und nennt daneben sein eigenes Gateway und die Integrationen seiner Plattform. Daraus folgt weder, dass Supabase Deploy-Kunde ist, noch, dass für Supabase die Abschaltfrist von Deploy gilt.

Halten Sie für jeden produktiven Anfragepfad fest, welcher Host ihn bedient und welche Laufzeitumgebung ihn ausführt. Prüfen Sie anschließend, ob auch Datenhaltung oder zeitgesteuerte Aufgaben von Deploy abhängen. So entsteht eine kurze Übersicht der Abhängigkeiten der untersuchten Anwendung. Eine Deno-Konfiguration im Repository allein beantwortet diese Fragen nicht.

Auch die Dokumentation kann zu einer falschen Frist führen. Denos bestehender Migrationsleitfaden beschreibt den Wechsel von Deploy Classic zu Deno Deploy. Sein Ziel ist nicht Workers. Die Deploy-Übersicht enthält ebenfalls noch einen früheren Hinweis zur Abschaltung von Classic. Lesen Sie beide als Dokumentation dieses früheren Übergangs, nicht als vollständige Migrationsanleitung zur Ankündigung vom Oktober 2026.

Falls beide Fristen für Sie gelten, muss die neue Hosting-Plattform vor Ablauf der Hosting-Frist abgenommen sein. Entscheiden Sie getrennt darüber, wie die Laufzeitumgebung weiter gepflegt wird. Berücksichtigen Sie dabei auch Deno-Programme, die nach dem Umzug des öffentlich erreichbaren Dienstes noch in Builds oder internen Jobs laufen.

Wählen Sie das Ziel danach, welches Verhalten es bewahren kann

Das richtige Ziel besteht die Abnahmetests Ihrer Anwendung und lässt sich von Ihrem Team betreiben. Eine Übernahmeankündigung entscheidet diese Frage nicht.

Nutzen Sie die folgende Tabelle, um die ersten Untersuchungen auszuwählen. Ihre Anforderungen sind technische Empfehlungen; die Zusagen der Anbieter ergeben sich weiterhin aus deren Ankündigungen.

Cloudflares Ankündigung beschreibt künftige Arbeiten, die celld und workerd zusammenführen und Self-Hosting unterstützen sollen. Sie benennt auch die derzeitige Beschränkung der Durable-Objects-Implementierung von workerd auf eine einzelne Instanz sowie unvollständige ergänzende Werkzeuge. Das begrenzt die Schlussfolgerungen, die sich aus der geplanten Richtung ziehen lassen.

Für ein Team, das eigene Infrastruktur erwägt, stellt sich außerdem die Frage nach der Betriebsverantwortung. Unser Artikel zu Personalbedarf und Verantwortung beim Self-Hosting behandelt diese Entscheidung. Hier geht es zunächst darum, ob das gewählte Ziel die Tests der Anwendung besteht.

Prüfen Sie ausgeführte Codepfade, Authentifizierung und Hintergrundaufgaben

Ein Migrationstest muss das Verhalten ausführen, das auf der Zielplattform scheitern könnte. Erfolgreiche Kompilierung und übereinstimmende HTTP-Statuscodes sind nur ein Teil des Nachweises.

Beginnen Sie mit einer kleinen Testumgebung, die dieselben repräsentativen Anfragen an die aktuelle Anwendung und den möglichen Ersatz senden kann. Nutzen Sie synthetische Datensätze und separate Testzugangsdaten. Legen Sie den Ausgangszustand fest, damit sich die Ergebnisse sinnvoll vergleichen lassen. Dokumentieren Sie anschließend gewollte Unterschiede wie Hostnamen oder erzeugte Kennungen.

Denos Dokumentation zur Node- und npm-Kompatibilität behandelt die Ausführung von Node-Anwendungen in Deno. Sie belegt nicht, dass Code mit Deno-APIs andernorts unverändert läuft. Für Workers unterscheidet die Dokumentation zur Node.js-Kompatibilität zwischen implementierten APIs, teilweiser Unterstützung und nicht funktionsfähigen Platzhaltern. Ein Import kann gelingen, während ein späterer Aufruf scheitert.

Benennen Sie selten genutzte Codepfade ausdrücklich: den Berichtsexport, die Verarbeitung von Anhängen, den Authentifizierungs-Callback oder eine Aufgabe, die auf ein Dateisystem zugreift oder einen Unterprozess startet. Nehmen Sie nur Funktionen auf, die Ihre Anwendung nutzt. Führen Sie den tatsächlichen Vorgang der Abhängigkeit aus, statt lediglich zu prüfen, ob ihr Modul geladen wird. Halten Sie Zielkonfiguration und Kompatibilitätsdatum im Testprotokoll fest, damit sich ein bestandenes Ergebnis auf eine reproduzierbare Umgebung bezieht.

Vergleichen Sie beim HTTP-Verhalten Antwortinhalte, Header, Weiterleitungen und Cookies, soweit diese zum vereinbarten Verhalten gehören. Prüfen Sie auch fehlerhafte Eingaben, abgelaufene Sitzungen und unberechtigte Anfragen. Geben Sie bei einem mandantenbezogenen Dienst zwei synthetischen Konten ähnlich aufgebaute Datensätze und versuchen Sie, auf die Daten des jeweils anderen Kontos zuzugreifen. Eine Antwort, die den erwarteten Datensatz und zusätzlich Daten eines anderen Kontos enthält, muss im Test durchfallen.

Falls die Anwendung Aufgaben zeitgesteuert ausführt oder in eine Warteschlange stellt, prüfen Sie diese gesondert. Nehmen Sie beispielsweise eine Anfrage an, unterbrechen Sie den Worker vor Abschluss und wiederholen Sie dann die Zustellung. Prüfen Sie den entstandenen Zustand und die externe Wirkung mit einem Testempfänger statt mit dem Postfach eines echten Kunden. Stellen Sie sicher, dass die zuständige Person den Fehler erkennen kann. Eine erfolgreiche Antwort auf die Anfrage belegt nicht, dass die spätere Aufgabe ausgeführt wurde.

Dokumentieren Sie jedes Ergebnis so, dass andere Entwickler es hinterfragen können: Ausgangszustand, Aktion, erwartetes Ergebnis, beobachtetes Ergebnis und relevante Ablaufdaten. Kennzeichnen Sie ein Abnahmekriterium mit Begründung als „nicht zutreffend“, wenn die Anwendung diese Funktion nicht hat. Eine riesige Checkliste mit unerklärten grünen Häkchen liefert weniger Belege als wenige Tests, die konkrete Fehlerfälle prüfen.

Deno KV und Workers KV brauchen unterschiedliche Abnahmetests

Ähnliche Speichernamen belegen kein gleichwertiges Transaktions- oder Leseverhalten. Falls die Korrektheit Ihres Zustands von Deno KV abhängt, machen Sie diese Abhängigkeit sichtbar, bevor Sie den Ersatzspeicher wählen.

Denos Dokumentation zu KV-Transaktionen beschreibt optimistische Nebenläufigkeitskontrolle. Lesezugriffe liefern Versionstamps; eine atomare Operation kann Schlüssel-Versionstamp-Paare zusammen mit Änderungen prüfen. Der Commit gelingt nur, wenn die geprüften Versionen noch übereinstimmen. Anwendungen, die solche Prüfungen nutzen, müssen Konflikte behandeln und entscheiden, ob sie den Vorgang wiederholen.

Die Dokumentation zu Workers KV beschreibt einen letztlich konsistenten Speicher, dessen Änderungen an anderen Standorten erst nach 60 Sekunden oder länger sichtbar sein können. Sie warnt davor, sich auf sofortige Sichtbarkeit zu verlassen, selbst am Ort des Schreibzugriffs. KV eigne sich nicht gut für atomare Operationen oder transaktionale Lese- und Schreibzugriffe. Wer stärkere Konsistenz benötigt, wird auf Durable Objects verwiesen.

Das ist eine konkrete Grenze der Kompatibilität, kein Urteil gegen Workers. Ein Cache und eine Eindeutigkeitsbedingung können selbst innerhalb derselben Anwendung unterschiedliche Speicher benötigen. Auch bei der Wahl einer anderen Cloudflare-Speicherkomponente müssen Sie deren tatsächliche Garantien und Ihre Implementierung prüfen. Der Name allein liefert das fehlende Verhalten nicht.

Angenommen, eine Deno-Anwendung prüft, ob ein Einladungsschlüssel fehlt, und erstellt dann atomar die Einladung und den zugehörigen Zuordnungsdatensatz. Eine naive Portierung, die erst liest und danach unabhängig schreibt, kann jeden sequenziellen Test bestehen. Prüfen Sie stattdessen zwei gleichzeitige Anfragen für dieselbe Einladung. Das erwartete Ergebnis der Anwendung könnte eine angenommene Einladung, ein Konflikt und eine konsistente Zuordnung sein. Definieren Sie dieses Ergebnis aus dem bestehenden Verhalten, bevor Sie den Ersatz entwickeln.

Ein zweites Szenario prüft die Sichtbarkeit. Erstellen Sie einen synthetischen Berechtigungsdatensatz, widerrufen Sie ihn und versuchen Sie sofort, die geschützte Aktion von einem anderen geografischen Standort aus auszuführen. Legen Sie fest, ob der Widerruf sofort gelten muss oder ob das Produkt eine Verzögerung erlaubt. Das Abnahmeergebnis betrifft diese Sicherheitsanforderung, nicht bloß die Frage, ob die Speicher-API Erfolg gemeldet hat.

Für Ablaufzeiten erstellen Sie einen kurzlebigen Datensatz und prüfen den Zugriff unmittelbar vor und nach dessen Ablauf. Beziehen Sie auch einen zuvor zwischengespeicherten Nichtfund ein, falls die Sichtbarkeit neu angelegter Daten relevant ist. Stellen Sie für sortierte Listen genügend synthetische Schlüssel wieder her, um die Annahmen der Anwendung zur Seiteneinteilung und Reihenfolge zu prüfen. Falls Versionstamps als Cursor oder Anwendungsmetadaten dienen, legen Sie fest, wie diese Referenzen nach der Umwandlung funktionieren. Ersetzen Sie sie nicht stillschweigend durch Zeitstempel der Zielplattform.

Erkennen Sie irreführend bestandene Tests vor der Freigabe

Ein irreführend bestandenes Ergebnis umgeht die Bedingung, die es angeblich prüft. Prüfen Sie den Testaufbau ebenso sorgfältig wie den Ersatzcode.

Ein lokaler Emulator kann die Logik prüfen, ohne die Verteilung im Produktivbetrieb abzubilden. Anfragen von einem einzigen Rechner können ein Sichtbarkeitsproblem übersehen, das einen anderen Standort betrifft. Sequenzielle Anfragen belegen keine Sicherheit bei gleichzeitigen Zugriffen. Eine leere Datenbank kann keinen Umwandlungsfehler in alten Datensätzen aufdecken. Ergänzen Sie gezielt die fehlende Bedingung, statt denselben oberflächlichen Test häufiger auszuführen.

Achten Sie auch auf abgefangene und verschluckte Fehler. Ein Fehler in einer Abhängigkeit wird womöglich abgefangen und in ein leeres Ergebnis umgewandelt. Der Endpunkt liefert 200, aber im Export fehlen Zeilen. Prüfen Sie den Inhalt der Ausgabe und das erwartete Fehlerverhalten. Zählen Sie bei Wiederholungstests die endgültige Wirkung, nicht nur die angenommenen Anfragen.

Bei parallel abgespieltem Produktivverkehr ist Sorgfalt nötig. Spielen Sie bereinigte Anfragen mit isoliertem Datenbestand ab und ersetzen Sie Ziele für E-Mails, Zahlungen und Webhooks durch Testempfänger. Ein gespiegelter produktiver Schreibzugriff kann eine zweite externe Wirkung auslösen. Entscheiden Sie vorab, welche Vergleiche nur lesend laufen können und welche ein kontrolliertes Szenario in der Testumgebung brauchen.

Nachweise zur Betriebsfähigkeit gehören zur Abnahme. Lösen Sie einen erkennbaren Fehler in der Testumgebung aus und lassen Sie ihn anhand der Protokolle und Alarme der Zielplattform diagnostizieren. Prüfen Sie, ob die Zugangsdaten zur vorgesehenen Umgebung gehören und ob die Wiederherstellungsanleitung für die zuständige Person funktioniert. Auch eine korrekte Anwendung lässt sich unter Druck schwer wiederherstellen, wenn die Fehlerprotokolle unzugänglich sind.

Prüfen Sie den Rollback mit Schreibzugriffen und Datenabgleich

Ein Rollback ist erst abgeschlossen, wenn die alte Anwendung mit korrektem Datenbestand weiterarbeiten kann. Die Rückleitung des Verkehrs macht Schreibzugriffe, die die Zielplattform angenommen hat, nicht rückgängig.

Deno dokumentiert KV-Backups in kundenseitig kontrollierten S3-kompatiblen Speicher und deren Nutzung mit dem Werkzeug denokv. Das ist ein möglicher Export- und Wiederherstellungsweg, den Sie prüfen sollten. Er wandelt Daten nicht automatisch in Workers KV, D1 oder ein anderes Zielformat um.

Stellen Sie ein repräsentatives Backup in einer isolierten Umgebung wieder her. Vergleichen Sie aussagekräftige Datensätze, Ablaufverhalten und Beziehungen, nicht nur die Anzahl der Objekte. Halten Sie fest, bis zu welchem Zeitpunkt das Backup reicht, und ermitteln Sie die danach angenommenen Schreibzugriffe. Ein lesbares Backup, in dem jüngste Transaktionen fehlen, reicht für den geplanten Rollback nicht aus.

Proben Sie anschließend einen Fehler, nachdem der mögliche Ersatz neue Schreibzugriffe angenommen hat. Unterbinden oder begrenzen Sie weitere Schreibzugriffe, erfassen Sie die angenommenen Änderungen der Zielplattform und gleichen Sie diese mit dem System ab, das wieder maßgeblich sein soll. Legen Sie fest, wie Duplikate, widersprüchliche Änderungen, Löschungen und unterbrochene Jobs behandelt werden. Nutzen Sie Anwendungskennungen und bewusst festgelegte Abgleichregeln; „alles zurückkopieren“ lässt diese Fragen offen.

Bei einem kleinen Dienst kann eine geplante Schreibpause das Vorgehen beherrschbar machen. Ein Dienst, der nicht pausieren kann, braucht ein geprüftes Verfahren zur Änderungserfassung oder Replikation. Gleichzeitiges Schreiben in beide Systeme bringt eigene Fehlerfälle mit sich: Ein Schreibzugriff kann auf einer Seite gelingen und auf der anderen scheitern. Proben Sie diesen Fall, bevor Sie doppelte Schreibzugriffe als Absicherung für die Wiederherstellung betrachten.

Halten Sie schließlich in der Freigabe zur Umstellung fest, ab wann der Rollback zusätzlichen Abgleich erfordert. Bevor die Zielplattform Schreibzugriffe annimmt, kann die Rückleitung des Verkehrs einfach sein. Danach sind das Abgleichverfahren und seine Nachweise erforderlich. Kann das Team den korrekten Zustand nicht innerhalb seiner festgelegten Wiederherstellungsanforderungen herstellen, ist die Umstellung noch nicht freigabereif.

Nutzen Sie Kit, wenn die Migration fehlende Fachkenntnisse aufzeigt

Stellen Sie erst dann jemanden für eine nachgewiesene technische Lücke ein, wenn die Abnahmearbeit gezeigt hat, was fehlt. Eine Abschaltfrist allein belegt nicht, dass das Startup eine dauerhafte Stelle braucht.

Es könnte um vorübergehende Arbeiten zur Datenbankumwandlung, Erfahrung mit Laufzeitkompatibilität oder dauerhafte Betriebsverantwortung gehen. Definieren Sie zuerst das benötigte Ergebnis und die Dauer. In einer klar begrenzten Aufgabe im Vorstellungsgespräch können Sie Kandidatinnen und Kandidaten bitten, einen fehlgeschlagenen bedingten Schreibzugriff zu erklären, einen tatsächlich ausgeführten Kompatibilitätspfad zu untersuchen oder einen Rollback nach dem Anlegen eines neuen Datensatzes durchzudenken. Nutzen Sie synthetische Daten und eine kurze Aufgabe; produktive Migrationsarbeit sollte bezahlt werden.

Bewahren Sie Migrationsnachweise und Entscheidungen zur Umstellung in Ihren Entwicklungswerkzeugen auf. Wenn Sie sich für die Personalsuche entscheiden, passt Kit in den Einstellungsprozess: Damit verwalten Sie Bewerbungen und die Teambewertung. Kit migriert weder Ihre Laufzeitumgebung noch gleicht es Ihre Datenbank ab.

Das unmittelbare Ergebnis ist ein Ersatz, der vor Ablauf der Hosting-Frist die Tests für Verhalten, Zustand und Wiederherstellung besteht. Falls diese Tests eine zu besetzende Rolle aufzeigen, sehen Sie sich Kit Hiring an, um diesen Einstellungsschritt zu organisieren.