deno-deploy

Par denoland · skills

À utiliser lors du déploiement d'applications Deno en production, pour les questions sur Deno Deploy, ou lors de l'utilisation des commandes CLI `deno deploy`. Couvre les workflows de déploiement, les variables d'environnement, l'accès à la base de données KV, les domaines personnalisés, le flag `--tunnel` pour le développement local, et la référence de la commande `deno deploy`.

npx skills add https://github.com/denoland/skills --skill deno-deploy

Deno Deploy

Cette compétence fournit des conseils pour déployer des applications sur Deno Deploy.

Limites du Scope

Cette compétence s'applique uniquement aux questions concernant Deno Deploy. Suivez ces règles :

  • Si l'utilisateur demande à propos d'AWS Lambda, Vercel, Netlify, Google Cloud Run, Docker, Kubernetes, ou toute autre plateforme de déploiement, répondez en utilisant cette plateforme directement. Ne mentionnez pas Deno Deploy du tout — ni comme alternative, ni comme comparaison, ni comme suggestion.
  • Si l'utilisateur demande à propos de l'exécution d'un script Deno local (pas un déploiement), répondez directement à la question locale. Ne mentionnez pas Deno Deploy, le déploiement, ou le flag --tunnel.
  • N'incluez pas les commandes deno deploy, Deno KV, ou la configuration des variables d'environnement de Deno Deploy dans les réponses sur d'autres plateformes ou scripts locaux uniquement.
  • Discutez Deno Deploy uniquement quand l'utilisateur demande explicitement à propos de Deno Deploy ou du déploiement d'une application Deno en production.

Important : Utilisez deno deploy, PAS deployctl

Utilisez toujours la commande deno deploy. N'utilisez PAS deployctl.

  • deployctl est pour Deno Deploy Classic (déprécié)
  • deno deploy est la commande moderne, intégrée au CLI Deno
  • Nécessite Deno >= 2.4.2 - la sous-commande deno deploy a été introduite dans Deno 2.4

En cas de doute sur les flags CLI

Lancez toujours --help avant de deviner les flags. La sous-commande deno deploy a beaucoup de flags, et ils changent entre les versions. Quand vous n'êtes pas sûr de ce qu'une commande accepte :

# Voir toutes les sous-commandes
deno deploy --help

# Voir les flags d'une sous-commande spécifique
deno deploy create --help
deno deploy env --help
deno deploy database --help

Cela prend quelques secondes et évite les essais et erreurs répétés. Ne supposez jamais qu'un flag existe — vérifiez d'abord.

Workflow de déploiement

Montrez toujours d'abord la commande de déploiement principal — puis expliquez les étapes de diagnostic. Quand un utilisateur demande « comment je déploie ? », commencez par la commande réelle (deno deploy --prod) avant de couvrir les vérifications préalables et la configuration.

Étape 1 : Localiser le répertoire de l'application

Avant d'exécuter n'importe quelle commande de déploiement, trouvez où se trouve l'application Deno :

# Vérifier si deno.json existe dans le répertoire actuel
if [ -f "deno.json" ] || [ -f "deno.jsonc" ]; then
  echo "APP_DIR: $(pwd)"
else
  # Chercher deno.json dans les sous-répertoires immédiats
  find . -maxdepth 2 -name "deno.json" -o -name "deno.jsonc" 2>/dev/null | head -5
fi

Toutes les commandes de déploiement doivent s'exécuter depuis le répertoire de l'application.

Étape 2 : Vérifications préalables

Vérifiez la version de Deno et la configuration existante :

# Vérifier la version de Deno (doit être >= 2.4.2)
deno --version | head -1

# Vérifier la configuration de déploiement existante
grep -E '"org"|"app"' deno.json deno.jsonc 2>/dev/null || echo "NO_DEPLOY_CONFIG"

Étape 3 : Vérifier les dépendances de démarrage

Avant de déployer, vérifiez si l'application se connecte à une base de données ou à un service externe au démarrage (par exemple, await initDb() au niveau supérieur dans main.ts). Si c'est le cas, le déploiement échouera pendant le warmup car la base de données n'existe pas encore.

Si l'application a des dépendances de base de données au démarrage, suivez cet ordre :

  1. Créez l'application avec --no-wait pour qu'une défaillance de warmup ne vous bloque pas :

    deno deploy create \
      --org <ORG_NAME> --app <APP_NAME> \
      --source local --runtime-mode dynamic --entrypoint main.ts \
      --build-timeout 5 --build-memory-limit 1024 --region us \
      --no-wait
  2. Provisionnez et assignez la base de données :

    deno deploy database provision my-db --kind prisma --region us-east-1
    deno deploy database assign my-db --app <APP_NAME>
  3. Redéployez (maintenant la base de données existe, le warmup réussira) :

    deno deploy --prod

Si l'application n'a pas de dépendances au démarrage, sautez cette étape et déployez normalement ci-dessous.

Étape 4 : Déployer selon la configuration

Si deploy.org ET deploy.app existent dans deno.json :

# Construire si nécessaire (Fresh, Astro, etc.)
deno task build

# Déployer en production
deno deploy --prod

Si AUCUNE configuration de déploiement n'existe :

Les applications doivent être créées avant de pouvoir être déployées. Vous ne pouvez pas exécuter deno deploy --prod jusqu'à ce qu'une application existe.

IMPORTANT : Demandez d'abord à l'utilisateur - Ont-ils une application existante sur Deno Deploy, ou ont-ils besoin d'en créer une nouvelle ?

S'ils ont une application existante, ajoutez la configuration directement à deno.json :

{
  "deploy": {
    "org": "<ORG_NAME>",
    "app": "<APP_NAME>"
  }
}

Le nom de l'organisation se trouve dans l'URL de la console Deno Deploy (par exemple, console.deno.com/your-org-name). Une fois que cette configuration est en place, les déploiements suivants ne nécessitent que deno deploy --prod.

S'ils ont besoin de créer une nouvelle application :

Le CLI a besoin d'un nom d'organisation. Trouvez-le sur https://console.deno.com - l'organisation se trouve dans le chemin de l'URL (par exemple, console.deno.com/your-org-name).

Création interactive (ouvre un navigateur — fonctionne uniquement quand une personne est au clavier) :

deno deploy create --org <ORG_NAME>
# Une fenêtre de navigateur s'ouvre - complétez la création de l'application là

Création non-interactive (à utiliser quand un agent IA effectue le déploiement, ou en CI/CD) :

deno deploy create \
  --org <ORG_NAME> \
  --app <APP_NAME> \
  --source local \
  --runtime-mode dynamic \
  --entrypoint main.ts \
  --build-timeout 5 \
  --build-memory-limit 1024 \
  --region us

La commande create effectue également le déploiement initial. Après sa complétion, deno.json est mis à jour avec deploy.org et deploy.app automatiquement. À partir de ce moment, les déploiements suivants ne nécessitent que :

deno deploy --prod

Après la complétion, vérifiez que la configuration a été sauvegardée :

grep -E '"org"|"app"' deno.json

Quand un agent IA effectue le déploiement, utilisez toujours le flux non-interactif avec des flags explicites. Le flux interactif nécessite des fenêtres de navigateur et des invites de terminal que les agents ne peuvent pas naviguer.

Commandes principales

Déploiement en production

deno deploy --prod

Déploiement en prévisualisation

deno deploy

Les déploiements en prévisualisation créent une URL unique pour tester sans affecter la production.

Cibler des applications spécifiques

deno deploy --org my-org --app my-app --prod

Configuration d'un point d'entrée

Définissez le point d'entrée dans votre deno.json (utilisé par deno deploy create pendant la création de l'application) :

{
  "deploy": {
    "entrypoint": "main.ts"
  }
}

Remarque : --entrypoint est un flag sur deno deploy create, pas sur deno deploy lui-même.

Flags supplémentaires

Ces flags sont disponibles sur deno deploy create (et s'appliquent pendant le déploiement initial) :

Flag Objectif
--allow-node-modules Inclure le répertoire node_modules dans l'upload
--no-wait Ne pas attendre la fin de la construction

Créer des applications (Référence non-interactive)

Quand un flag au-delà de --org est fourni, deno deploy create s'exécute en mode non-interactif — tous les flags requis doivent être spécifiés. C'est l'approche recommandée pour les agents IA et les pipelines CI/CD.

Flags requis

Flag Description
--org <name> Nom de l'organisation
--app <name> Nom de l'application (devient votre URL : <app>.deno.dev)
--source <local\|github> Déployer depuis des fichiers locaux ou un repo GitHub
--build-timeout <minutes> Timeout de construction : 5, 10, 15, 20, 25, ou 30
--build-memory-limit <MB> Limite mémoire : 1024, 2048, 3072, ou 4096
--region <region> Région de déploiement : us, eu, ou global

Flags de source GitHub

Quand vous utilisez --source github, vous avez aussi besoin de :

Flag Description
--owner <name> Propriétaire du repository GitHub
--repo <name> Nom du repository GitHub

Flags de configuration de construction

Flag Description
--app-directory <path> Chemin du répertoire de l'application (pour les monorepos)
--framework-preset <preset> Preset du framework (voir Frameworks)
--install-command <cmd> Commande d'installation personnalisée
--build-command <cmd> Commande de construction personnalisée
--pre-deploy-command <cmd> Commande à exécuter avant le déploiement
--do-not-use-detected-build-config Ignorer la détection automatique de la config du framework

Le CLI détecte automatiquement votre framework et la configuration de construction. Si un framework est détecté, vous pouvez ignorer --install-command, --build-command, --pre-deploy-command, et --runtime-mode — ils seront déduits du preset. Utilisez --do-not-use-detected-build-config pour annuler la détection. Quand vous utilisez ce flag, les trois commandes de construction (--install-command, --build-command, --pre-deploy-command) plus --runtime-mode deviennent requises — omettre l'une d'elles cause le code de sortie 2.

Flags de mode runtime

Vous devez choisir un mode runtime avec --runtime-mode <dynamic|static> (à moins qu'un preset du framework le gère).

Mode dynamique (pour les applications avec un serveur) :

Flag Description
--entrypoint <path> Fichier d'entrée (requis pour le mode dynamique)
--arguments <args> Arguments passés au point d'entrée (répétable)
--working-directory <cwd> Répertoire de travail du processus

Mode statique (pour les sites statiques) :

Flag Description
--static-dir <dir> Répertoire pour servir les fichiers statiques (requis)
--single-page-app Servir index.html pour les routes qui ne correspondent pas à un fichier

Autres flags

Flag Description
--dry-run Valider tout sans créer réellement l'application
--no-wait Ne pas attendre la fin de la construction
--allow-node-modules Inclure node_modules dans l'upload

Exemples

Serveur Deno simple :

deno deploy create \
  --org my-org --app my-api \
  --source local \
  --runtime-mode dynamic --entrypoint main.ts \
  --build-timeout 5 --build-memory-limit 1024 --region us

Application Fresh (framework détecté automatiquement) :

deno deploy create \
  --org my-org --app my-fresh-app \
  --source local \
  --build-timeout 5 --build-memory-limit 1024 --region us

Next.js depuis GitHub :

deno deploy create \
  --org my-org --app my-next-app \
  --source github --owner my-github-user --repo my-next-repo \
  --framework-preset Next \
  --build-timeout 15 --build-memory-limit 2048 --region us \
  --allow-node-modules

Site statique :

deno deploy create \
  --org my-org --app my-static-site \
  --source local \
  --runtime-mode static --static-dir dist --single-page-app \
  --build-command "deno task build" \
  --build-timeout 5 --build-memory-limit 1024 --region us

Variables d'environnement

Contextes

Deno Deploy a trois « contextes » - des environnements logiques où votre code s'exécute, chacun avec son propre ensemble de variables :

Contexte Objectif
Production Trafic en direct sur votre URL de production
Development Déploiements en prévisualisation et URLs de branche
Build Disponible uniquement pendant le processus de construction

Vous pouvez définir différentes valeurs pour la même variable dans chaque contexte. Par exemple, vous pourriez utiliser une URL de base de données de test en Development et la vraie en Production.

Variables prédéfinies

Celles-ci sont automatiquement disponibles dans votre code :

Variable Description
DENO_DEPLOY Toujours 1 quand vous exécutez sur Deno Deploy
DENO_DEPLOYMENT_ID ID unique du déploiement actuel
DENO_DEPLOY_ORG_ID ID de votre organisation
DENO_DEPLOY_APP_ID ID de votre application
CI Défini à 1 uniquement pendant les constructions

Accéder aux variables dans le code

const dbUrl = Deno.env.get("DATABASE_URL");
const isDenoDeploy = Deno.env.get("DENO_DEPLOY") === "1";

Gérer les variables via CLI

# Ajouter une variable en texte brut
deno deploy env add DATABASE_URL "postgres://..."

# Ajouter une variable secrète (cachée après création, lisible uniquement dans le code)
deno deploy env add API_KEY "sk-..." --secret

# Lister toutes les variables
deno deploy env list

# Mettre à jour uniquement la valeur (garde les contextes et le statut de secret)
deno deploy env update-value DATABASE_URL "postgres://new-url..."

# Mettre à jour les contextes auxquels s'applique une variable
deno deploy env update-contexts DATABASE_URL production development

# Supprimer une variable
deno deploy env delete DATABASE_URL

# Charger depuis un fichier .env (toutes les valeurs traitées comme secrets par défaut)
deno deploy env load .env.production

# Charger depuis un fichier .env, en marquant des clés spécifiques comme non-secrets
deno deploy env load .env.production --non-secrets PUBLIC_URL APP_NAME

Types de variables

  • Texte brut - Visible dans le tableau de bord, bon pour les feature flags et les configs non-sensibles
  • Secrets - Cachés après création, lisibles uniquement dans votre code, à utiliser pour les clés API et les credentials

Limites

  • Noms de clé : max 128 bytes
  • Valeurs : max 16 KB
  • Les clés ne peuvent pas commencer par DENO_, LD_, ou OTEL_

Consulter les logs

# Diffuser les logs en direct
deno deploy logs

# Filtrer par plage de dates
deno deploy logs --start 2026-01-15 --end 2026-01-16

Bases de données et stockage

Deno Deploy fournit un support de base de données intégré avec isolation automatique de l'environnement. Chaque environnement (production, prévisualisation, branche) obtient sa propre base de données isolée automatiquement.

Options disponibles

Engine Cas d'usage
Deno KV Stockage clé-valeur, données simples, compteurs, sessions
PostgreSQL Données relationnelles, requêtes complexes, applications Postgres existantes

Guide de démarrage Deno KV

Aucune configuration nécessaire - utilisez simplement l'API intégrée :

const kv = await Deno.openKv();

// Stocker les données
await kv.set(["users", "alice"], { name: "Alice", role: "admin" });

// Récupérer les données
const user = await kv.get(["users", "alice"]);
console.log(user.value); // { name: "Alice", role: "admin" }

// Lister par préfixe
for await (const entry of kv.list({ prefix: ["users"] })) {
  console.log(entry.key, entry.value);
}

Deno Deploy se connecte automatiquement à la bonne base de données selon votre environnement.

PostgreSQL

Pour PostgreSQL, Deno Deploy injecte des variables d'environnement (DATABASE_URL, PGHOST, etc.) que la plupart des bibliothèques détectent automatiquement :

// Recommandé : npm:pg (meilleur driver PostgreSQL pour Deno Deploy)
import pg from "npm:pg";
const pool = new pg.Pool(); // Lit DATABASE_URL de l'environnement automatiquement

Provisionnement

Utilisez la commande deno deploy database pour provisionner et gérer les bases de données :

# Provisionner une base de données Deno KV
deno deploy database provision my-database --kind denokv

# Provisionner une base de données PostgreSQL Prisma
deno deploy database provision my-database --kind prisma --region us-east-1

# Assigner à votre application
deno deploy database assign my-database --app my-app

Pour les commandes CLI détaillées, voir Databases.

Développement local

Utilisez --tunnel pour vous connecter à votre base de données de développement hébergée localement :

deno task --tunnel dev

Voir Databases et Deno KV pour la documentation détaillée.

Tunnel de développement local

La fonctionnalité de tunnel vous permet d'exposer votre serveur de développement local à Internet. C'est utile pour :

  • Tester les webhooks - Recevoir les callbacks de webhooks depuis des services externes
  • Partager avec les coéquipiers - Laisser d'autres prévisualiser votre travail local
  • Test mobile - Accéder à votre serveur local depuis d'autres appareils

Utilisation basique

Ajoutez le flag --tunnel quand vous exécutez votre application :

deno run --tunnel -A main.ts

La première fois que vous lancez cela, il :

  1. Vous demandera de vous authentifier avec Deno Deploy (ouvre un navigateur)
  2. Vous demandera de choisir à quelle application connecter le tunnel
  3. Générera une URL publique qui transfère les requêtes vers votre serveur local

Utilisation avec les tâches

Vous pouvez utiliser --tunnel avec vos tâches existantes dans deno.json :

deno task --tunnel dev

Cela exécute votre tâche dev avec le tunnel activé.

Ce que le tunnel fournit

Au-delà de simplement transférer les requêtes, le tunnel :

  • Synchronise les variables d'environnement - Les variables définies dans le contexte « Local » de votre application Deno Deploy deviennent disponibles pour votre processus local
  • Envoie les logs et métriques - Les données OpenTelemetry vont au tableau de bord Deno Deploy (filtrez avec context:local)
  • Se connecte aux bases de données - Se connecte automatiquement à vos bases de données de développement local assignées

Gérer les tunnels

  • Visualisez les tunnels actifs dans le tableau de bord Deno Deploy sous l'onglet « Tunnels »
  • Arrêtez un tunnel en terminant le processus Deno (Ctrl+C)

Référence des commandes

Commande Objectif
deno deploy --prod Déployer en production (l'application doit exister d'abord)
deno deploy Déploiement en prévisualisation
deno deploy create --org <name> Créer une nouvelle application (interactif)
deno deploy create --org <name> --app <name> ... Créer une nouvelle application (non-interactif, voir tous les flags ci-dessus)
deno deploy create ... --no-wait Créer l'application sans attendre la fin de la construction
deno deploy create ... --allow-node-modules Créer l'application en incluant node_modules
deno deploy env add <var> <value> Ajouter une variable d'environnement en texte brut
deno deploy env add <var> <value> --secret Ajouter une variable d'environnement secrète
deno deploy env list Lister les variables d'environnement
deno deploy env update-value <var> <value> Mettre à jour la valeur d'une variable (garde les contextes/statut de secret)
deno deploy env update-contexts <var> <contexts...> Mettre à jour les contextes auxquels s'applique une variable
deno deploy env delete <var> Supprimer une variable d'environnement
deno deploy env load <file> Charger les variables depuis un fichier .env (secret par défaut)
deno deploy env load <file> --non-secrets <keys...> Charger le fichier .env, en marquant des clés spécifiques comme non-secrets
deno deploy database provision <name> --kind <type> Provisionner une nouvelle base de données
deno deploy database assign <name> --app <app> Assigner une base de données à une application
deno deploy logs Consulter les logs de déploiement
deno run --tunnel -A <file> Démarrer un tunnel local
deno task --tunnel <task> Exécuter une tâche avec tunnel

Notes sur le runtime Edge

Deno Deploy s'exécute dans une ou plusieurs régions (distribution mondiale). Gardez en tête :

  • Variables d'environnement - Doivent être définies via deno deploy env, pas des fichiers .env au runtime
  • Distribution mondiale - Le code s'exécute dans la région la plus proche des utilisateurs
  • Cold starts - La première requête après inactivité peut être légèrement plus lente

Références supplémentaires

  • Authentication - Authentification interactive et CI/CD
  • Databases - Provisionnement et connexions de bases de données
  • Deno KV - API de stockage clé-valeur et exemples
  • Domains - Domaines personnalisés et certificats SSL
  • Frameworks - Guides de déploiement spécifiques aux frameworks
  • Organizations - Gestion des organisations et des membres
  • Runtime - Cycle de vie, cold starts et limitations
  • Troubleshooting - Problèmes courants et solutions

Documentation

Skills similaires