Alternatives à Deno Deploy en 2026 : où migrer vos applications ?

Parmi les alternatives à Deno Deploy, Cloudflare Workers est la première piste à examiner : Deno le désigne comme destination de migration et annonce encore 6 mois de fonctionnement pour Deploy. Privilégiez Netlify pour un site dont la logique en périphérie repose sur Deno, Supabase Edge Functions pour une API adossée à une base de données, Vercel Functions pour une application structurée autour de son framework, ou Val Town pour de petites tâches planifiées. Si votre application utilise Deno KV, choisissez son remplaçant avant de décider où exécuter les fonctions.

Tarifs et documentation vérifiés le 12 octobre 2026. Ce comparatif porte sur les tarifs publics, les modalités d’exécution et le travail de migration ; il ne repose pas sur des tests de déploiement depuis un compte connecté. Le délai avant fermeture provient de l’annonce de Deno du 9 octobre.

Alternatives à Deno Deploy : le comparatif en un coup d’œil

Retenez la destination qui préserve le comportement de votre application avec le moins de modifications à entretenir. Migrer un endpoint TypeScript qui interroge une base externe n’a pas les mêmes implications que déplacer une application dont les transactions, les tâches planifiées et la file de messages vivent entièrement dans Deno Deploy.

Les sources tarifaires sont Cloudflare, Netlify, Supabase, Vercel, Val Town, sa FAQ sur la facturation et les tarifs VPS de DigitalOcean. Il s’agit de prix d’entrée, pas d’une estimation de votre facture mensuelle complète.

Qu’a annoncé Deno, et quel délai faut-il retenir ?

Deno Deploy va fermer ; le runtime Deno bénéficie d’une période de maintenance distincte. Dans l’annonce datée du 9 octobre 2026, Ryan Dahl écrit :

Deno Deploy continuera de fonctionner pendant six mois avant de fermer.

La même annonce promet un accompagnement des clients payants qui migrent vers Cloudflare Workers. Deno s’engage aussi à publier pendant un an encore des versions mensuelles du runtime, avec corrections de bugs et mises à jour de sécurité, puis à en arrêter le développement. Le runtime reste open source. JSR, le registre de paquets JavaScript et TypeScript, continuera de fonctionner et son infrastructure sera transférée chez Cloudflare. Lire l’annonce de Deno.

Deno annonce des durées, pas une date précise de fermeture. N’en déduisez pas une échéance qui n’a pas été donnée, et ne confondez pas la maintenance plus longue du runtime avec un délai supplémentaire pour Deploy. Les clients payants ont intérêt à utiliser l’accompagnement proposé tout en préparant ensemble la migration de l’application et celle des données.

1. Cloudflare Workers : la première piste pour migrer Deno Deploy

Cloudflare Workers est une plateforme managée qui exécute des gestionnaires de requêtes et des tâches de fond. C’est le premier candidat à retenir, puisque Deno y oriente explicitement ses clients. Pour un fondateur dont l’application combine une API TypeScript, une base externe et une tâche de nettoyage planifiée, le travail consiste surtout à adapter les interactions avec le runtime et la configuration du déploiement. Une application construite autour de Deno KV demande, en plus, de repenser le stockage. Choisissez Workers comme plateforme de destination, en prévoyant explicitement le travail sur les composants propres à Deno qui ne pourront pas être repris tels quels.

Pour quels projets : API, webhooks, tâches cron, files de messages et sites qui bénéficient d’une infrastructure managée.
Point fort : la destination de migration désignée par Deno, avec des services de stockage et de planification sur place.
Tarifs : Workers Free ; Workers Paid impose un minimum de $5 USD/mois par compte ; l’usage Enterprise relève du contrat souscrit.
Essai gratuit : l’offre permanente Workers Free permet d’évaluer la plateforme gratuitement.
Effort de migration : faible à moyen pour des gestionnaires sans état ; élevé quand il faut repenser les transactions KV et les tâches en file d’attente.

Ce qui change dans votre code TypeScript

Workers utilise le runtime workerd, et non le runtime Deno. L’espace de noms global Deno n’y est pas disponible. Les interfaces web standard comme Request, Response et fetch constituent une bonne base pour le code portable ; à l’inverse, Deno.serve, Deno.env, Deno.openKv et Deno.cron signalent les points à remplacer. La compatibilité Node.js ne couvre elle aussi qu’un sous-ensemble d’API : réussir à importer un paquet en développement ne suffit donc pas à prouver que ses dépendances fonctionneront à l’exécution. API du runtime Workers.

Wrangler est l’outil en ligne de commande de Cloudflare pour le déploiement. Le tutoriel Wrangler de Deno montre comment conserver Deno dans la chaîne de développement : ajouter npm:wrangler, générer les types Workers, exporter un module doté d’un gestionnaire fetch et produire le bundle avec esbuild et son plugin Deno si la résolution des modules Deno est nécessaire. Utiliser Deno pour préparer le code à envoyer ne transforme pas le Worker déployé en processus Deno.

Faites passer les secrets et l’accès aux ressources par des bindings, ces références configurées qui permettent à un Worker d’accéder à sa base, à sa file de messages ou aux valeurs de son environnement. Inspectez les dépendances autant que les fichiers de l’application : un utilitaire peut masquer un accès au système de fichiers, même si votre gestionnaire de route utilise uniquement des API web. Les bindings Cloudflare.

Remplacer chaque service selon son comportement

La distinction essentielle porte sur Workers KV et Deno KV. Workers KV privilégie les lectures fréquentes et les écritures relativement rares ; les lectures mises en cache peuvent renvoyer des données périmées. La ressemblance des noms ne suffit pas pour y transférer des réservations de stock, des soldes de compte ou un contrôle atomique d’unicité. Fonctionnement de Workers KV.

D1 est la voie SQL : les préfixes de clés et les index secondaires doivent devenir un schéma conçu pour l’application. Son API batch exécute les instructions dans une transaction, mais ne transpose pas automatiquement un contrôle optimiste de Deno. Durable Objects associe un état à une instance de calcul chargée de la coordination. Cette option mérite d’être étudiée lorsqu’une entité, comme un salon ou un compte, exige une coordination séquentielle. Transactions D1, Durable Objects.

Pour les tâches planifiées, Cron Triggers utilise un gestionnaire scheduled et des horaires UTC. Pour le travail différé, Queues fournit le système de messagerie. Une planification détermine quand démarrer ; une file conserve le travail en attente de traitement. Remplacer l’une ne remplace pas l’autre. Les sites statiques peuvent utiliser Workers Static Assets, en séparant les fichiers générés de la logique dynamique des requêtes.

Tarifs et limites à intégrer au budget

Workers Free comprend 100,000 requêtes par jour et 10 ms de CPU par appel. Paid inclut 10 millions de requêtes et 30 millions de millisecondes CPU par mois, puis facture $0.30 par million de requêtes supplémentaire et $0.02 par million de millisecondes CPU supplémentaire. Il faut aussi chiffrer la base de données, les files de messages et les autres produits utilisés. Tarifs actuels de Workers.

La taille du bundle ne justifie plus, à elle seule, de passer à Paid : Free et Paid autorisent tous deux 64 MiB non compressés, tandis que la mémoire reste limitée à 128 MB. Consultez les limites actuelles et notre explication du passage à Paid lié à la taille du bundle. Notre analyse de Cloudflare présente plus largement l’articulation des différents produits du compte.

1. 1

   Recenser les dépendances au runtime

   Repérez les appels à l’espace de noms Deno, les imports par URL, les accès au système de fichiers, les secrets, les opérations KV, les planifications et les consommateurs de messages. Séparez la logique métier portable des adaptateurs qui assurent ces interactions.

2. 2

   Créer un point d’entrée adapté à Workers

   Suivez le tutoriel Wrangler de Deno : configurez le gestionnaire du module et les types Workers générés, puis le build personnalisé compatible avec Deno si vos imports l’exigent. Préservez le contrat de réponse existant tout en changeant la manière d’appeler le gestionnaire.

3. 3

   Préparer le stockage et les déclencheurs

   Choisissez la base avant d’importer les enregistrements. Ajoutez les bindings, transposez les planifications dans Cron Triggers et réécrivez producteurs et consommateurs de messages. Documentez ce qui se passe lorsqu’une tâche est distribuée une nouvelle fois.

4. 4

   Répéter la migration avant de rediriger le trafic

   Utilisez des jeux de données de test locaux et un environnement de destination distinct pour comparer les codes de statut, les en-têtes, l’authentification et les changements d’état. Le déploiement du code n’est qu’une étape : les données et les tâches de fond doivent être prêtes pour la même bascule.

2. Netlify : pour les sites avec une logique edge basée sur Deno

Netlify est une plateforme de déploiement web dotée d’Edge Functions basées sur Deno. Elle convient aux sites dont les traitements dynamiques interviennent autour des requêtes entrantes : localisation, vérification de l’authentification, redirections ou personnalisation légère. Garder cette logique à côté des aperçus de déploiement du site peut avoir plus de valeur que d’adopter un nouveau modèle d’infrastructure. Un gestionnaire edge sans état se prête bien à la migration ; un backend très dépendant des files de messages impose davantage de séparation. Choisissez Netlify lorsque le site constitue le produit et que la logique edge vient le servir. Présentation des Edge Functions.

Pour quels projets : sites statiques et applications web avec des traitements de requêtes légers basés sur Deno.
Point fort : des Edge Functions déployées avec le site, aperçus et retours arrière compris.
Tarifs : Free $0 sans limite de durée ; Personal $9/mois ; Pro $20/mois avec un nombre illimité de membres ; Enterprise sur devis.
Essai gratuit : Free comprend une limite de 300 crédits par mois.
Effort de migration : faible à moyen pour un site et sa logique edge sans état ; plus élevé lorsqu’il faut séparer stockage, planifications et consommateurs de messages.

Un runtime familier, mais d’autres règles pour l’application

Une Edge Function utilise le gestionnaire et le contexte de Netlify. Vérifiez aussi les imports : Netlify documente un fichier d’import map distinct, au lieu de celui intégré à deno.json, et présente la prise en charge des paquets npm comme une bêta. C’est un travail de migration concret si la résolution des dépendances de votre projet repose aujourd’hui sur la configuration Deno. API des Edge Functions.

L’exécution est plafonnée à 50 ms de CPU par requête, avec un délai maximal de 40 secondes pour les en-têtes de réponse. Attendre un service distant et transformer un document volumineux ne consomment pas le même budget. Une vérification d’authentification peut convenir à une architecture edge légère ; un traitement intensif en CPU mérite un autre mode d’exécution. Limites des Edge Functions.

Que deviennent Deno KV, cron et les files de messages ?

Utilisez Netlify Blobs pour les contenus adaptés à un accès par clé, et Netlify Database, son service Postgres, pour les données relationnelles et les mises à jour transactionnelles. Blobs propose des lectures à cohérence forte en option, mais cela ne reproduit pas à lui seul l’API atomique multiclés de Deno KV. Le nouveau stockage doit préserver la règle métier, par exemple l’interdiction des noms d’utilisateur en double.

Les Scheduled Functions sont une fonctionnalité distincte de Netlify Functions. Une Edge Function contenant Deno.cron n’acquiert pas pour autant une planification managée. Isolez la tâche, configurez sa planification et examinez son runtime séparément. Si l’ancienne tâche consomme une file Deno KV, identifiez explicitement le stockage durable des messages et leur consommateur : planifier une fonction ne migre pas les messages en attente.

Pour un fondateur qui gère un site de contenu et une synchronisation horaire, cette séparation reste raisonnable : la diffusion du site et sa personnalisation rejoignent la plateforme web, tandis que la synchronisation reçoit sa propre fonction planifiée et son stockage durable. L’option est moins séduisante lorsque l’application se compose surtout de workers de fond interdépendants.

Chiffrer les crédits et les besoins de l’équipe

Personal comprend 1,000 crédits/mois. Les paliers mensuels de Pro sont de 3,000 pour $20, 5,000 pour $33, 10,000 pour $63, 15,000 pour $95 et 20,000 pour $126. À partir de 5,000 crédits, les paliers supérieurs permettent de reporter les crédits mensuels inutilisés sur le cycle de facturation suivant ; le palier de base ne le permet pas. Paliers de crédits actuels de Netlify.

La recharge automatique est désactivée par défaut. Une fois activée, elle permet d’ajouter 500 crédits pour $5 sur Personal et 1,500 pour $10 sur Pro. Épuiser le quota du compte sans acheter de crédits supplémentaires peut mettre ses projets en pause : préparer un lancement public suppose donc de décider des dépenses autant que du déploiement. Ne confondez pas ces offres actuelles à crédits avec les anciennes tarifications Netlify par siège.

3. Supabase Edge Functions : pour les API adossées à une base de données

Supabase Edge Functions exécute des fonctions TypeScript sur un runtime compatible avec Deno. C’est le choix le plus adapté lorsque la migration accompagne une décision de passer à Postgres, une base relationnelle. Une application par abonnement qui reçoit des webhooks de paiement et met à jour des fiches clients y trouve une destination naturelle. Le runtime familier réduit une partie des changements, tandis que la conception de la base devient le chantier principal. Choisissez Supabase lorsque les données persistantes de l’application déterminent son architecture. Documentation des fonctions.

Pour quels projets : webhooks et API à rapprocher de Postgres, de l’authentification et du stockage de fichiers.
Point fort : des fonctions compatibles avec Deno intégrées à une plateforme de base de données.
Tarifs : Free $0/mois ; Pro à partir de $25/mois ; Team à partir de $599/mois ; Enterprise sur devis.
Essai gratuit : Free comprend 500,000 appels d’Edge Functions et une base de 500 MB par projet.
Effort de migration : moyen pour les gestionnaires compatibles ; élevé lorsque Deno KV doit devenir un schéma relationnel avec une nouvelle logique transactionnelle.

Migrer le modèle de données autant que l’endpoint

Remplacez les appels Deno KV par des accès Postgres. Un préfixe représentant, par exemple, les éléments enregistrés par un utilisateur devient une relation interrogeable ; un contrôle d’unicité devient une contrainte ou une transaction en base. Évitez de conserver une collection de clés opaques pour simplifier l’import en apparence si toutes les requêtes importantes devront aussitôt les décoder.

Un gestionnaire de paiement peut, par exemple, devoir enregistrer un événement et mettre à jour un droit d’accès dans la même opération. Le critère d’acceptation est que les reprises ne puissent pas attribuer ce droit deux fois. Une réponse HTTP réussie de la nouvelle fonction ne prouve pas que cette règle a survécu à la réécriture du stockage.

Supabase propose aussi Cron, capable d’exécuter un traitement en base ou d’appeler une Edge Function, et Queues, une messagerie durable reposant sur Postgres. Remplacez explicitement par ces services l’enregistrement Deno.cron et le code de mise en file et de consommation de Deno KV. Définissez comment les messages sont acquittés et à quelles conditions une tâche échouée peut être retentée.

Limites d’exécution et coût de départ complet

Les Edge Functions autorisent 256 MB de mémoire et 2 secondes de CPU par requête. La durée totale du worker est plafonnée à 150 secondes sur Free et 400 secondes sur les offres payantes, mais cette durée plus longue n’augmente pas le budget CPU. Ces plafonds mesurent des choses différentes ; ils ne sont pas des manières interchangeables de décrire un worker de longue durée. Limites des fonctions.

Pro et Team comprennent 2 millions d’appels de fonctions, puis facturent $2 par million supplémentaire. Free autorise 2 projets actifs et met les projets inactifs en pause après 1 semaine. Les offres payantes incluent un crédit de calcul de $10/mois, qui couvre une instance Micro. Tarifs Supabase.

Supabase est moins adapté au frontend statique du site. La documentation des limites précise que servir du HTML exige un domaine personnalisé ; sinon, une réponse text/html est réécrite en text/plain. Distinguez le choix de l’hébergement frontend de celui de l’API.

4. Vercel Functions : quand le framework web motive la migration

Vercel Functions propose des fonctions serveur managées rattachées à un déploiement web. Cette solution convient lorsque le framework frontend et le workflow de mise en production sont les principales raisons du changement. Si un fondateur réorganise déjà son application autour d’un framework pris en charge par Vercel, intégrer les routes API à cette structure peut être cohérent. Pour un service Deno que l’on souhaite conserver tel quel par ailleurs, la sortie est moins directe. Choisissez Vercel pour le workflow de l’application, en prévoyant explicitement le portage du runtime et du stockage.

Pour quels projets : applications web structurées autour d’un framework, avec des routes API à côté du frontend.
Point fort : un workflow de déploiement unifié pour l’application et ses fonctions serveur.
Tarifs : Hobby $0/mois ; Pro $20/mois ; Enterprise sur devis.
Essai gratuit : Pro annonce un essai ; Hobby est réservé à un usage personnel non commercial.
Effort de migration : moyen pour adapter le runtime et les routes ; élevé si le stockage et les tâches de fond doivent également être remplacés.

Porter le code ou conserver un runtime communautaire ?

Vercel classe Node.js parmi ses runtimes pris en charge et Deno comme runtime communautaire sous le nom vercel-deno. Les implications en matière de maintenance diffèrent. Pour une migration soumise à une échéance, évaluez la compatibilité de cette intégration communautaire et la responsabilité de son suivi avant d’en faire une dépendance indispensable à la production. Sinon, portez le gestionnaire et ses dépendances vers le runtime officiellement pris en charge qu’utilise votre framework. Documentation des runtimes Vercel.

Pour Deno KV, choisissez une base et remplacez l’API. Le guide du stockage Vercel distingue Blob pour les fichiers, Global Config pour la configuration et les bases du Marketplace pour les données applicatives. Un stockage de configuration ne doit pas devenir la destination par défaut des données clients transactionnelles sous prétexte qu’il offre une interface clé-valeur pratique.

Vercel Cron remplace la planification, pas l’enregistrement des tâches dans le code avec Deno.cron. Hobby autorise une exécution une fois par jour, avec une précision de planification à l’heure ; Pro permet un intervalle minimal d’une fois par minute. Une synchronisation fréquente suffit donc à écarter Hobby sur le seul critère de la planification. Usage et tarifs de Cron.

Vercel Queues est désormais disponible en bêta sur toutes les offres, avec des topics durables, des reprises automatiques et une distribution au moins une fois. C’est donc une destination possible pour les tâches de la file Deno KV, mais les producteurs, les consommateurs et le mécanisme d’acquittement doivent toujours être réécrits. Intégrez le statut bêta à votre décision si cette file constitue l’unique circuit de traitement des commandes clients.

Le prix augmente avec le nombre de personnes qui déploient

L’abonnement Pro comprend 1 siège autorisant le déploiement et $20 de crédit de consommation mensuel. Chaque siège payant supplémentaire coûte $20/mois ; les sièges de consultation sont gratuits. La consommation au-delà du crédit et les options payantes sont facturées séparément. Détails de la facturation Pro.

Pour une entreprise qui quitte Deno Deploy, la gratuité de Hobby ne constitue pas un budget de production. Partez d’une offre autorisant l’usage commercial, puis ajoutez les besoins en base de données et en files de messages. Vous éviterez qu’une migration apparemment économique se transforme en une série de factures imprévues.

5. Val Town : pour les petites API et les tâches planifiées

Val Town est un environnement hébergé pour de petits programmes, avec des déclencheurs HTTP, e-mail et cron. Il convient particulièrement au petit service qui remplit une fonction précise : un webhook qui met à jour un système externe, une API pour un outil interne ou l’envoi planifié d’un récapitulatif. Son runtime Deno le rend pertinent pour cette migration, même si les interfaces de stockage et de déclenchement diffèrent. Choisissez Val Town pour une automatisation compacte plutôt que pour une plateforme que vous devez exploiter. Documentation Val Town.

Pour quels projets : petites API, gestionnaires de webhooks, intégrations planifiées et utilitaires internes.
Point fort : du code hébergé avec déclencheurs intégrés et stockage SQLite.
Tarifs : Free $0 ; Pro $21/mois avec facturation annuelle ; Business à partir de $167/mois avec facturation annuelle ; Enterprise sur devis. La FAQ de l’éditeur indique des abonnements mensuels à $25 pour Pro et $200 pour Business.
Essai gratuit : Free est une offre permanente, sans domaines personnalisés ni vals privés.
Effort de migration : faible pour un utilitaire sans état, moyen pour une petite tâche avec persistance, élevé pour une application plus vaste avec état.

La période de facturation compte : le tarif annuel sélectionné sur la page des prix ne doit pas être présenté comme un abonnement résiliable chaque mois au même prix. La FAQ de Val Town fournit les prix avec facturation mensuelle et confirme l’utilisation du runtime Deno.

Une petite migration suppose un petit périmètre

Placez le gestionnaire dans un val, le conteneur d’application versionné de Val Town, puis associez son appel à un déclencheur HTTP ou cron. Pour une tâche qui se contente d’appeler une API externe et d’envoyer un récapitulatif, l’état durable peut se limiter au dernier élément traité. Le raisonnement est beaucoup plus simple que pour une application destinée aux clients, avec plusieurs entités transactionnelles et consommateurs de messages.

Remplacez Deno KV par la base SQLite propre à chaque val si elle convient, ou conservez une base externe. Réécrivez les recherches par clé et les contrôles atomiques sous forme d’opérations en base. La migration n’est pas terminée si Deno.openKv pointe encore vers le stockage hébergé qui doit fermer.

Pour les tâches en file d’attente, faites apparaître explicitement les travaux en suspens dans l’architecture. Un cron qui parcourt périodiquement une table de tâches est une conception possible, mais vous devez implémenter la réservation des tâches, les reprises et la gestion des doublons. Le comportement de la file Deno KV n’est pas conservé automatiquement.

Fréquence, confidentialité et durée déterminent l’offre

Sur Free, l’intervalle cron minimal est de 15 minutes et la durée totale est limitée à 1 minute par exécution. Pro abaisse l’intervalle à 1 minute et porte la durée maximale à 10 minutes ; sa fiche tarifaire indique aussi 10 domaines personnalisés et 2,000 vals privés. Tarifs et limites actuels.

Un récapitulatif quotidien public peut tenir dans Free. Une intégration privée ou une tâche qui doit interroger un service plus souvent nécessite une autre offre, même avec un trafic minime. La confidentialité du code et le contrôle d’accès à l’endpoint sont aussi deux exigences distinctes : un code source privé ne définit pas, à lui seul, qui peut appeler votre endpoint HTTP.

L’effort de migration est faible pour un utilitaire sans état avec un déclencheur simple, moyen lorsque l’état persistant d’une tâche doit être déplacé et élevé si vous cherchez à y reproduire le runtime et l’architecture de données d’une application plus importante. Ces niveaux évaluent le périmètre du travail, pas le nombre d’heures nécessaires.

6. Deno auto-hébergé : pour conserver le comportement du runtime

Exécuter Deno sur un serveur privé virtuel, ou VPS, préserve le runtime et vous confie la responsabilité de l’hébergement. Un conteneur regroupe le runtime et l’application pour les exécuter sur l’hôte de votre choix. Cette piste mérite d’être étudiée lorsque les accès au système de fichiers, les API propres à Deno ou le fonctionnement de processus de longue durée concentrent l’essentiel du travail de portage. Choisissez l’auto-hébergement lorsque conserver le runtime évite plus de complexité que l’exploitation du serveur n’en ajoute. Deno publie un guide officiel pour Docker.

Pour quels projets : applications très dépendantes de Deno, dont le responsable sait gérer un serveur ou un déploiement de conteneurs.
Point fort : la maîtrise du runtime, du système de fichiers et du cycle de vie des processus.
Tarifs : le runtime open source ne comporte pas d’offre d’hébergement managé. À titre d’exemple, DigitalOcean propose un Basic Regular Droplet à $4.00/mois, avec 512 MiB de RAM ; l’option 1 GiB coûte $6.00/mois.
Essai gratuit : DigitalOcean mentionne des crédits promotionnels, mais sa page tarifaire ne propose pas d’offre Droplet gratuite permanente.
Effort de migration : moins de réécriture liée au runtime, davantage de responsabilités d’exploitation ; les données hébergées nécessitent toujours un plan d’export, d’import et de restauration.

Ces tarifs VPS affichés ne constituent pas une recommandation de dimensionnement valable pour toute application Deno. Intégrez le stockage des sauvegardes, la supervision et votre temps d’exploitation à la décision. Un serveur que vous possédez déjà peut éviter un nouvel abonnement d’hébergement tout en générant du travail de maintenance.

Que deviennent Deno KV et cron en auto-hébergement ?

Deno KV peut utiliser le chemin d’une base locale persistante, avec SQLite sous le capot dans la CLI. Cela permet de conserver une plus grande partie de l’API KV qu’un passage au service de stockage d’un autre fournisseur. En revanche, cela ne copie pas vos enregistrements hébergés, ne recrée pas un hébergement distribué et ne rend pas durable le système de fichiers éphémère d’un conteneur. Exportez les données, organisez leur import, montez un stockage persistant et vérifiez que vous savez restaurer une sauvegarde. Documentation Deno KV.

La même distinction s’applique à la planification. Dans la CLI, Deno.cron conserve l’état d’exécution en mémoire et chaque processus possède son propre ensemble de tâches. Si vous exécutez plusieurs réplicas de l’application, vous devez déterminer lequel prend en charge chaque tâche planifiée ou comment ils se coordonnent. Garder le même appel d’API ne préserve pas le service de planification managé de Deploy. Comportement de Deno cron.

Pour une petite application sur un seul serveur, cette charge d’exploitation peut être acceptable. Pour une entreprise qui a besoin d’une infrastructure redondante et où personne ne souhaite assumer les sauvegardes, les correctifs et la reprise après incident, une petite facture VPS peut détourner beaucoup de ressources.

workerd et celld : une autre voie d’auto-hébergement

L’annonce de Cloudflare cite workerd et celld parmi les options d’auto-hébergement déjà disponibles. Ces outils utilisent le modèle de programmation Workers : ils s’envisagent après un portage vers ce modèle et ne promettent pas d’exécuter tout le code Deno existant sans modification. Cloudflare reconnaît aussi une limite de montée en charge liée à l’instance unique dans l’implémentation des Durable Objects de workerd autonome, et décrit l’intégration de travaux et d’idées de celld dans workerd. Annonce de Cloudflare.

N’attribuez à aucun des deux un abonnement managé ni une offre gratuite inventés. Le budget correspond à l’infrastructure et à l’exploitation que vous fournissez. Pour une équipe sous pression, l’évaluation doit porter sur les capacités disponibles aujourd’hui et le plan de reprise qu’elle sait mettre en œuvre ; de futures intégrations ne remplacent pas ces décisions.

Deno auto-hébergé peut servir de transition, mais il faut aussi prévoir la maintenance du runtime à plus long terme, compte tenu de la période de support annoncée par Deno.

Choisir selon ce que fait réellement votre projet

Le choix change lorsque les données et leur comportement sont plus difficiles à déplacer que le code. Évaluez l’effort à partir des modifications identifiables : faible pour une adaptation du gestionnaire ou du build sans changement du stockage externe ; moyen si une interface avec le runtime ou l’API de stockage doit être réécrite ; élevé s’il faut repenser les transactions, transférer des tâches en attente ou assumer de nouvelles responsabilités d’exploitation. Même une petite application peut demander une migration importante si son bon fonctionnement repose sur ces mécanismes.

Pour des fonctions TypeScript sans API propres à Deno, commencez par Workers. Préservez le contrat des requêtes et des réponses, puis adaptez le point d’entrée et le déploiement. Netlify devient plus intéressant si ces fonctions transforment les requêtes d’un site ; Supabase, si elles agissent surtout sur sa base de données. Vercel prend l’avantage lorsque le framework de l’application motive déjà le changement. Sur ces différentes destinations, un gestionnaire sans état représente généralement le cas le plus simple.

Pour Deno KV, choisissez d’abord le modèle de stockage. Des contenus surtout lus peuvent convenir à Workers KV ou Netlify Blobs. Des enregistrements transactionnels orientent vers D1, Postgres ou une autre base conçue autour de la règle à préserver. Les besoins de coordination peuvent orienter vers Durable Objects. Un petit utilitaire peut se contenter de SQLite dans Val Town. Un KV local auto-hébergé conserve davantage de code, mais vous transfère la responsabilité de la durabilité et de la restauration. Considérez toute migration d’un KV hébergé comme un chantier au moins moyen, tant que l’inventaire des transactions et des index n’a pas démontré le contraire.

Pour cron, comparez les règles d’exécution. Un rapport quotidien et une interrogation fréquente n’exigent pas les mêmes offres. Workers Cron Triggers est la première piste managée à examiner ; Val Town convient à une tâche compacte ; Supabase Cron, à la maintenance d’une base ; Netlify Scheduled Functions, au travail associé à un site. La restriction quotidienne de Vercel Hobby l’écarte pour les tâches fréquentes. Réenregistrer une planification demande peu de travail ; empêcher des exécutions simultanées de produire des effets indésirables peut en demander davantage.

Pour les files de messages, déplacez ensemble les tâches en attente et leur consommateur. Cloudflare Queues et Supabase Queues constituent des destinations explicites ; Vercel Queues ajoute une option en bêta. La migration englobe l’identité des messages, les reprises, les acquittements et les tâches déjà en attente. Un simple minuteur ne les remplace pas. Le périmètre est élevé lorsque ces tâches correspondent à des engagements pris envers des clients payants.

Pour les sites statiques, transférez les fichiers générés avant de porter du code serveur inutile. Workers Static Assets et Netlify sont des candidats directs ; Vercel mérite d’être retenu si le framework du site bénéficie de son workflow. Vérifiez séparément les redirections, les en-têtes, les formulaires, l’authentification et les routes dynamiques. Déplacer une sortie purement statique demande moins d’effort qu’un site qui personnalise ses réponses à chaque requête.

Migrer Deno KV sans perdre les règles de l’application

Un déploiement de code et une migration de données ne réussissent pas selon les mêmes critères. Le code doit répondre correctement ; la migration doit préserver les enregistrements et les règles qui rendent ces réponses correctes.

Avant l’export, recensez les fonctions KV utilisées : clés composites typées, parcours par préfixe, expiration, index secondaires, contrôles optimistes de version, mises à jour atomiques et observateurs de changements. Le guide KV de Deno montre pourquoi un ensemble de clés peut porter bien plus de comportements applicatifs qu’un simple export d’objets ne le laisse supposer.

Un index de noms d’utilisateur l’illustre bien. Si l’application stocke à la fois une fiche utilisateur et une correspondance entre nom et utilisateur, copier les deux enregistrements ne suffit pas. Le nouveau mécanisme d’écriture doit préserver leur relation et refuser les mises à jour contradictoires. De même, un horodatage qui servait à faire expirer une session exige une règle explicite à destination ; importer sa valeur sans reproduire ce comportement peut laisser la session valide trop longtemps.

Pour les files de messages, conservez un inventaire séparé des tâches en attente, terminées et échouées lorsque la source expose ces informations. Décidez s’il faut laisser l’ancien consommateur vider la file avant la bascule, ou transférer les tâches avec des identifiants qui sécurisent leur rejeu. L’idempotence signifie que répéter une tâche ne répète pas son effet métier. C’est ce qui empêche une nouvelle tentative d’envoi de reçu d’en expédier plusieurs, ou le rejeu d’un message de traitement de commande de créer du travail en double.

1. 1

   Définir le traitement des écritures pendant la copie

   Sauvegardez la source et décidez comment gérer les écritures durant la copie. Une courte suspension peut convenir à une petite application ; une synchronisation plus complexe exige une réconciliation. Ne laissez pas des changements simultanés disparaître silencieusement entre l’export et la bascule.

2. 2

   Vérifier les enregistrements et les comportements

   Comparez les nombres d’enregistrements par type d’entité, des valeurs représentatives et l’encodage des clés. Testez les soumissions en double, les mises à jour contradictoires, les expirations et les enregistrements absents avec des jeux de données contrôlés. Vérifiez le résultat métier attendu, pas seulement la réponse positive de la nouvelle API.

3. 3

   Basculer ensemble le trafic et la responsabilité des tâches

   Redirigez les requêtes uniquement lorsque les données de destination sont prêtes. Désactivez ou transférez les anciennes planifications et les anciens consommateurs pour éviter que les deux plateformes produisent le même effet. Recréez méthodiquement les secrets et les destinations des webhooks.

4. 4

   Surveiller et conserver une voie de retour utilisable

   Surveillez les erreurs, les tâches échouées et les événements métier après le changement. Conservez la sauvegarde de la source. Si la destination a accepté de nouvelles écritures, le retour arrière nécessite un plan de réconciliation des données, pas seulement une annulation du changement DNS.

Lors de votre prochaine session de travail, établissez l’inventaire et choisissez une destination pour l’opération avec état la plus difficile à déplacer. Portez cette opération avant de peaufiner le reste de la migration. Elle révélera davantage de risques que le déplacement d’un endpoint de santé sans état supplémentaire.

Comment ces solutions ont été sélectionnées

Ces pistes couvrent les composants d’une application Deno Deploy : fonctions HTTP, données persistantes, tâches planifiées, files de messages et fichiers statiques. Cloudflare arrive en premier parce que Deno le désigne comme destination de migration. Netlify, Supabase et Val Town sont retenus pour leur exécution basée sur Deno et leurs usages distincts ; Vercel pour son workflow de déploiement web ; l’auto-hébergement pour la maîtrise du runtime.

Les tarifs et les capacités ont été vérifiés sur les pages publiques des éditeurs le 12 octobre 2026. Les niveaux d’effort décrivent les changements imposés par les interfaces documentées. Ils ne représentent ni des durées de migration mesurées, ni des résultats de tests de charge, ni des essais réalisés depuis un compte connecté. Les services cloud généralistes ont été écartés : allonger la liste des fournisseurs ne résoudrait pas les décisions centrales sur le runtime, les données et la responsabilité des tâches.

Les choix à éviter pour cette migration

Évitez de remplacer mécaniquement un Deno KV transactionnel par Workers KV. Retenez-le uniquement si son comportement en lecture et en écriture convient aux données. Un stockage peu coûteux ne compense pas des hypothèses de cohérence devenues fausses.

Évitez Netlify Edge Functions pour les traitements de fond intensifs en CPU. Son budget d’exécution en périphérie est une limite utile à la conception ; ne comptez pas sur une offre payante pour changer le modèle d’exécution.

Évitez Vercel Hobby pour une application commerciale en production. La page tarifaire le réserve à l’usage personnel non commercial. Ses restrictions cron empêchent aussi d’en faire une référence gratuite pertinente pour des tâches fréquentes.

Évitez Val Town Free pour du code source qui doit rester privé. L’adéquation de l’offre passe avant le volume de trafic. Évitez également de faire de Supabase Edge Functions le remplacement par défaut d’un site statique classique : choisissez explicitement l’hébergement frontend.

Évitez l’auto-hébergement sans responsable de la reprise après incident. Démarrer le processus est la partie facile. Quelqu’un doit savoir restaurer les données, relancer les services et expliquer quel ordonnanceur fait autorité après une panne.

Les questions à se poser avant de migrer

Quand Deno Deploy va-t-il fermer ?

L’annonce prévoit six mois de fonctionnement, sans donner de date précise. Retenez cette durée ; ne lui substituez pas la période de maintenance plus longue du runtime.

Peut-on conserver Deno en quittant Deno Deploy ?

Oui. Netlify Edge Functions, Supabase Edge Functions et Val Town proposent une exécution basée sur Deno ou compatible avec lui ; un VPS ou un conteneur permet d’exécuter Deno soi-même. Chaque plateforme managée possède ses propres API et limites. Conserver Deno ne préserve pas automatiquement la base KV hébergée, les planifications ou la file de messages.

Peut-on transférer directement Deno KV vers Cloudflare KV ?

Seulement en adaptant aussi l’API et en confirmant que les exigences de cohérence de l’application sont compatibles avec Workers KV. Les contrôles atomiques, les transactions, les index et les observateurs de Deno KV doivent être remplacés explicitement. Pour des enregistrements transactionnels, étudiez D1 ou une autre base ; pour coordonner l’état de chaque entité, envisagez Durable Objects.

Quelle offre gratuite peut exécuter ma tâche cron ?

Vérifiez d’abord la fréquence, le budget d’exécution, la confidentialité du code source et les conditions d’usage commercial. Val Town Free impose un intervalle minimal de 15 minutes et une durée maximale de 1 minute par exécution. Vercel Hobby est limité aux tâches quotidiennes et à l’usage personnel non commercial. Workers Free dispose d’un budget CPU serré ; Netlify et Supabase appliquent leurs propres quotas partagés. La gratuité de l’ordonnanceur ne prouve pas que toute la tâche tiendra dans l’offre gratuite.