render-deploy

Déployez des applications sur Render en analysant les bases de code, en générant des Blueprints render.yaml, et en fournissant des deeplinks Dashboard. À utiliser lorsque l'utilisateur souhaite déployer, héberger, publier ou configurer son application sur la plateforme cloud de Render.

npx skills add https://github.com/openai/skills --skill render-deploy

Déployer sur Render

Render supporte les services sauvegardés par Git et les services d'images Docker préconstruites.

Cette compétence couvre les flux sauvegardés par Git :

  1. Méthode Blueprint - Générer render.yaml pour les déploiements Infrastructure-as-Code
  2. Création Directe - Créer des services instantanément via les outils MCP

Les Blueprints peuvent aussi exécuter une image Docker préconstruite en utilisant runtime: image, mais render.yaml doit toujours résider dans un dépôt Git.

S'il n'y a pas de contrôle distant Git, arrêtez-vous et demandez à l'utilisateur soit de :

  • Créer/pousser un contrôle distant Git (peut être minimal si seul le Blueprint est nécessaire), soit
  • Utiliser le Tableau de bord Render/l'API pour déployer une image Docker préconstruite (MCP ne peut pas créer de services sauvegardés par image).

Conditions préalables

  • Quand le sandboxing bloque les appels réseau de déploiement, relancez avec sandbox_permissions=require_escalated.
  • Le déploiement peut prendre quelques minutes. Utilisez des valeurs de délai d'expiration appropriées.

Quand utiliser cette compétence

Activez cette compétence quand les utilisateurs veulent :

  • Déployer une application sur Render
  • Créer un fichier Blueprint render.yaml
  • Configurer le déploiement Render pour leur projet
  • Héberger ou publier leur application sur la plateforme cloud de Render
  • Créer des bases de données, des tâches cron ou d'autres ressources Render

Chemin heureux (Nouveaux utilisateurs)

Utilisez cette courte séquence d'invites avant une analyse approfondie pour réduire les frictions :

  1. Demandez s'ils veulent déployer à partir d'un dépôt Git ou d'une image Docker préconstruite.
  2. Demandez si Render devrait approvisionner tout ce dont l'application a besoin (en fonction de ce qui semble probable d'après la description de l'utilisateur) ou seulement l'application tandis qu'ils apportent leur propre infra. Si les dépendances ne sont pas claires, posez un suivi court pour confirmer s'ils ont besoin d'une base de données, de workers, de cron ou d'autres services.

Puis procédez avec la méthode appropriée ci-dessous.

Choisir votre chemin source

Chemin Dépôt Git : Requis pour le Blueprint et la Création Directe. Le dépôt doit être poussé sur GitHub, GitLab ou Bitbucket.

Chemin Image Docker Préconstruite : Supporté par Render via les services sauvegardés par image. Ceci n'est pas supporté par MCP ; utilisez le Tableau de bord/l'API. Demandez :

  • URL d'image (registre + tag)
  • Authentification du registre (si privé)
  • Type de service (web/worker) et port

Si l'utilisateur choisit une image Docker, guidez-le vers le flux de déploiement d'image du Tableau de bord Render ou demandez-lui d'ajouter un contrôle distant Git (pour que vous puissiez utiliser un Blueprint avec runtime: image).

Choisir votre méthode de déploiement (Dépôt Git)

Les deux méthodes nécessitent un dépôt Git poussé sur GitHub, GitLab ou Bitbucket. (Si vous utilisez runtime: image, le dépôt peut être minimal et contenir seulement render.yaml.)

Méthode Meilleur pour Avantages
Blueprint Applications multi-services, flux IaC Contrôlé en version, reproductible, supporte les configurations complexes
Création Directe Services uniques, déploiements rapides Création instantanée, pas de fichier render.yaml nécessaire

Heuristique de sélection de méthode

Utilisez cette règle de décision par défaut sauf si l'utilisateur demande une méthode spécifique. Analysez d'abord la base de code ; posez la question seulement si l'intention de déploiement n'est pas claire (par ex., BD, workers, cron).

Utiliser Création Directe (MCP) quand TOUS sont vrais :

  • Service unique (une application web ou un site statique)
  • Pas de services worker/cron séparés
  • Pas de bases de données attachées ou Key Value
  • Variables env simples seulement (pas de groupes d'env partagés) Si ce chemin convient et MCP n'est pas encore configuré, arrêtez-vous et guidez la configuration de MCP avant de procéder.

Utiliser Blueprint quand N'IMPORTE LEQUEL est vrai :

  • Services multiples (web + worker, API + frontend, etc.)
  • Des bases de données, Redis/Key Value ou autres entrepôts de données sont requis
  • Tâches cron, workers en arrière-plan ou services privés
  • Vous voulez une IaC reproductible ou un render.yaml commité au dépôt
  • Configuration monorepo ou multi-env qui nécessite une configuration cohérente

Si vous n'êtes pas sûr, posez une question de clarification rapide, mais par défaut utilisez Blueprint pour la sécurité. Pour un service unique, préférez fortement Création Directe via MCP et guidez la configuration de MCP si nécessaire.

Vérification des conditions préalables

Au démarrage d'un déploiement, vérifiez ces exigences dans l'ordre :

1. Confirmer le chemin source (Git vs Docker)

Si vous utilisez des méthodes basées sur Git (Blueprint ou Création Directe), le dépôt doit être poussé sur GitHub/GitLab/Bitbucket. Les Blueprints qui font référence à une image préconstruite nécessitent toujours un dépôt Git avec render.yaml.

git remote -v
  • Si aucun contrôle distant n'existe, arrêtez-vous et demandez à l'utilisateur de créer/pousser un contrôle distant ou de basculer vers le déploiement d'image Docker.

2. Vérifier la disponibilité des outils MCP (Préféré pour service unique)

Les outils MCP offrent la meilleure expérience. Vérifiez la disponibilité en essayant :

list_services()

Si les outils MCP sont disponibles, vous pouvez ignorer l'installation de CLI pour la plupart des opérations.

3. Vérifier l'installation de Render CLI (pour la validation Blueprint)

render --version

Si non installé, proposez d'installer :

  • macOS : brew install render
  • Linux/macOS : curl -fsSL https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh | sh

4. Configuration de MCP (si MCP n'est pas configuré)

Si list_services() échoue parce que MCP n'est pas configuré, demandez s'ils veulent configurer MCP (préféré) ou continuer avec le fallback CLI. S'ils choisissent MCP, demandez quel outil d'IA ils utilisent, puis fournissez les instructions correspondantes ci-dessous. Utilisez toujours leur clé API.

Cursor

Guidez l'utilisateur à travers ces étapes :

  1. Obtenez une clé API Render :

    https://dashboard.render.com/u/*/settings#api-keys

  2. Ajoutez ceci à ~/.cursor/mcp.json (remplacez <YOUR_API_KEY>) :

    {
"mcpServers": {
 "render": {
   "url": "https://mcp.render.com/mcp",
   "headers": {
     "Authorization": "Bearer <YOUR_API_KEY>"
   }
 }
}
}

  3. Redémarrez Cursor, puis relancez list_services().

Claude Code

Guidez l'utilisateur à travers ces étapes :

  1. Obtenez une clé API Render :

    https://dashboard.render.com/u/*/settings#api-keys

  2. Ajoutez le serveur MCP avec Claude Code (remplacez <YOUR_API_KEY>) :

    claude mcp add --transport http render https://mcp.render.com/mcp --header "Authorization: Bearer <YOUR_API_KEY>"

  3. Redémarrez Claude Code, puis relancez list_services().

Codex

Guidez l'utilisateur à travers ces étapes :

  1. Obtenez une clé API Render :

    https://dashboard.render.com/u/*/settings#api-keys

  2. Définissez-la dans leur shell :

    export RENDER_API_KEY="<YOUR_API_KEY>"

  3. Ajoutez le serveur MCP avec la CLI Codex :

    codex mcp add render --url https://mcp.render.com/mcp --bearer-token-env-var RENDER_API_KEY

  4. Redémarrez Codex, puis relancez list_services().

Autres outils

Si l'utilisateur utilise une autre application d'IA, dirigez-le vers la documentation Render MCP pour les étapes de configuration de cet outil et la méthode d'installation.

Sélection de l'espace de travail

Après la configuration de MCP, demandez à l'utilisateur de définir l'espace de travail Render actif avec une invite comme :

Définis mon espace de travail Render à [WORKSPACE_NAME]

5. Vérifier l'authentification (fallback CLI uniquement)

Si MCP n'est pas disponible, utilisez plutôt la CLI et vérifiez que vous pouvez accéder à votre compte :

# Vérifiez si l'utilisateur est connecté (utilisez -o json pour le mode non-interactif)
render whoami -o json

Si render whoami échoue ou retourne des données vides, la CLI n'est pas authentifiée. La CLI ne demandera pas toujours automatiquement, donc invitez explicitement l'utilisateur à s'authentifier :

Si aucune des deux n'est configurée, demandez à l'utilisateur quelle méthode il préfère :

6. Vérifier le contexte de l'espace de travail

Vérifiez l'espace de travail actif :

get_selected_workspace()

Ou via CLI :

render workspace current -o json

Pour lister les espaces de travail disponibles :

list_workspaces()

Si l'utilisateur a besoin de basculer les espaces de travail, il doit le faire via le Tableau de bord ou la CLI (render workspace set).

Une fois les conditions préalables satisfaites, procédez avec le flux de déploiement.

Méthode 1 : Déploiement Blueprint (Recommandé pour les applications complexes)

Flux de travail Blueprint

Étape 1 : Analyser la base de code

Analysez la base de code pour déterminer le framework/runtime, les commandes de construction et de démarrage, les variables d'env requises, les entrepôts de données et la liaison de port. Utilisez les listes de contrôle détaillées dans references/codebase-analysis.md.

Étape 2 : Générer render.yaml

Créez un fichier Blueprint render.yaml en suivant la spécification Blueprint.

Spécification complète : references/blueprint-spec.md

Points clés :

  • Utilisez toujours plan: free sauf si l'utilisateur spécifie autrement
  • Incluez TOUTES les variables d'env dont l'application a besoin
  • Marquez les secrets avec sync: false (l'utilisateur les remplit dans le Tableau de bord)
  • Utilisez le type de service approprié : web, worker, cron, static ou pserv
  • Utilisez le runtime approprié : references/runtimes.md

Structure de base :

services:
  - type: web
    name: my-app
    runtime: node
    plan: free
    buildCommand: npm ci
    startCommand: npm start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: postgres
          property: connectionString
      - key: JWT_SECRET
        sync: false  # L'utilisateur remplit dans le Tableau de bord

databases:
  - name: postgres
    databaseName: myapp_db
    plan: free

Types de service :

  • web : Services HTTP, API, applications web (accessibles publiquement)
  • worker : Processeurs de tâches en arrière-plan (non accessibles publiquement)
  • cron : Tâches planifiées qui s'exécutent selon un calendrier cron
  • static : Sites statiques (HTML/CSS/JS servis via CDN)
  • pserv : Services privés (internes uniquement, au sein du même compte)

Détails des types de service : references/service-types.md Options de runtime : references/runtimes.md Exemples de modèles : assets/

Étape 2.5 : Étapes suivantes immédiates (Toujours fournir)

Après la création de render.yaml, donnez toujours à l'utilisateur une courte liste de contrôle explicite et exécutez immédiatement la validation quand la CLI est disponible :

  1. S'authentifier (CLI) : exécutez render whoami -o json (si pas connecté, exécutez render login ou définissez RENDER_API_KEY)
  2. Valider (recommandé) : exécutez render blueprints validate
    • Si la CLI n'est pas installée, proposez de l'installer et fournissez la commande.
  3. Commiter + pousser : git add render.yaml && git commit -m "Add Render deployment configuration" && git push origin main
  4. Ouvrir le Tableau de bord : Utilisez le lien profond Blueprint et complétez l'OAuth Git si demandé
  5. Remplir les secrets : Définissez les variables d'env marquées sync: false
  6. Déployer : Cliquez sur "Apply" et surveillez le déploiement

Étape 3 : Valider la configuration

Validez le fichier render.yaml pour attraper les erreurs avant le déploiement. Si la CLI est installée, exécutez les commandes directement ; invitez seulement l'utilisateur si la CLI est manquante :

render whoami -o json  # Assurez-vous que la CLI est authentifiée (ne demandera pas toujours)
render blueprints validate

Corrigez les erreurs de validation avant de procéder. Problèmes courants :

  • Champs requis manquants (name, type, runtime)
  • Valeurs de runtime invalides
  • Syntaxe YAML incorrecte
  • Références de variables d'env invalides

Guide de configuration : references/configuration-guide.md

Étape 4 : Commiter et pousser

IMPORTANT : Vous devez fusionner le fichier render.yaml dans votre dépôt avant de déployer.

Assurez-vous que le fichier render.yaml est commité et poussé sur votre contrôle distant Git :

git add render.yaml
git commit -m "Add Render deployment configuration"
git push origin main

S'il n'y a pas encore de contrôle distant Git, arrêtez-vous ici et guidez l'utilisateur pour créer un dépôt GitHub/GitLab/Bitbucket, l'ajouter comme origin et le pousser avant de continuer.

Pourquoi c'est important : Le lien profond du Tableau de bord lira le render.yaml à partir de votre dépôt. Si le fichier n'est pas fusionné et poussé, Render ne trouvera pas la configuration et le déploiement échouera.

Vérifiez que le fichier se trouve dans votre dépôt distant avant de procéder à l'étape suivante.

Étape 5 : Générer le lien profond

Obtenez l'URL du dépôt Git :

git remote get-url origin

Cela retournera une URL de votre fournisseur Git. Si l'URL est au format SSH, convertissez-la en HTTPS :

Format SSH Format HTTPS
git@github.com:user/repo.git https://github.com/user/repo
git@gitlab.com:user/repo.git https://gitlab.com/user/repo
git@bitbucket.org:user/repo.git https://bitbucket.org/user/repo

Motif de conversion : Remplacez git@<host>: par https://<host>/ et supprimez le suffixe .git.

Formatez le lien profond du Tableau de bord en utilisant l'URL du dépôt HTTPS :

https://dashboard.render.com/blueprint/new?repo=<REPOSITORY_URL>

Exemple :

https://dashboard.render.com/blueprint/new?repo=https://github.com/username/repo-name

Étape 6 : Guider l'utilisateur

CRITIQUE : Assurez-vous que l'utilisateur a fusionné et poussé le fichier render.yaml sur son dépôt avant de cliquer sur le lien profond. Si le fichier n'est pas dans le dépôt, Render ne peut pas lire la configuration Blueprint et le déploiement échouera.

Fournissez le lien profond à l'utilisateur avec ces instructions :

  1. Vérifiez que render.yaml est fusionné - Confirmez que le fichier existe dans votre dépôt sur GitHub/GitLab/Bitbucket
  2. Cliquez sur le lien profond pour ouvrir le Tableau de bord Render
  3. Complétez l'OAuth du fournisseur Git si demandé
  4. Nommez le Blueprint (ou utilisez celui par défaut de render.yaml)
  5. Remplissez les variables d'env secrets (marquées avec sync: false)
  6. Examinez les services et la configuration des bases de données
  7. Cliquez sur "Apply" pour déployer

Le déploiement commencera automatiquement. Les utilisateurs peuvent surveiller la progression dans le Tableau de bord Render.

Étape 7 : Vérifier le déploiement

Après que l'utilisateur déploie via le Tableau de bord, vérifiez que tout fonctionne.

Vérifiez le statut du déploiement via MCP :

list_deploys(serviceId: "<service-id>", limit: 1)

Recherchez status: "live" pour confirmer le déploiement réussi.

Vérifiez les erreurs d'exécution (attendez 2-3 minutes après le déploiement) :

list_logs(resource: ["<service-id>"], level: ["error"], limit: 20)

Vérifiez les métriques d'intégrité du service :

get_metrics(
  resourceId: "<service-id>",
  metricTypes: ["http_request_count", "cpu_usage", "memory_usage"]
)

Si des erreurs sont trouvées, passez à la section Vérification post-déploiement et triage basique ci-dessous.

Méthode 2 : Création de service directe (Déploiements rapides de service unique)

Pour les déploiements simples sans Infrastructure-as-Code, créez les services directement via les outils MCP.

Quand utiliser Création Directe

  • Service web unique ou site statique
  • Prototypes ou démos rapides
  • Quand vous n'avez pas besoin d'un fichier render.yaml dans votre dépôt
  • Ajouter des bases de données ou des tâches cron aux projets existants

Conditions préalables pour Création Directe

Le dépôt doit être poussé sur un fournisseur Git. Render clone votre dépôt pour construire et déployer des services.

git remote -v  # Vérifiez que le contrôle distant existe
git push origin main  # Assurez-vous que le code est poussé

Fournisseurs supportés : GitHub, GitLab, Bitbucket

S'il n'y a pas de contrôle distant, arrêtez-vous et demandez à l'utilisateur de créer/pousser un contrôle distant ou de basculer vers le déploiement d'image Docker.

Note : MCP ne supporte pas la création de services sauvegardés par image. Utilisez le Tableau de bord/l'API pour les déploiements d'image Docker préconstruite.

Flux de travail de création directe

Utilisez les étapes concises ci-dessous, et consultez references/direct-creation.md pour les exemples complets de commandes MCP et la configuration de suivi.

Étape 1 : Analyser la base de code

Utilisez references/codebase-analysis.md pour déterminer le runtime, les commandes de construction/démarrage, les variables d'env et les entrepôts de données.

Étape 2 : Créer les ressources via MCP

Créez le service (web ou statique) et toutes les bases de données ou magasins de clés-valeurs requis. Voir references/direct-creation.md.

Si MCP retourne une erreur concernant les identifiants Git manquants ou l'accès au dépôt, arrêtez-vous et guidez l'utilisateur pour connecter son fournisseur Git dans le Tableau de bord Render, puis relancez.

Étape 3 : Configurer les variables d'env

Ajoutez les variables d'env requises via MCP après la création. Voir references/direct-creation.md.

Rappelez à l'utilisateur que les secrets peuvent être définis dans le Tableau de bord s'il préfère ne pas les passer via MCP.

Étape 4 : Vérifier le déploiement

Vérifiez le statut du déploiement, les journaux et les métriques. Voir references/direct-creation.md.

Pour la découverte de services, les détails de configuration, les commandes rapides et les problèmes courants, voir references/deployment-details.md.

Vérification post-déploiement et triage basique (Toutes les méthodes)

Gardez ceci court et répétable. Si une vérification échoue, corrigez-la avant de redéployer.

  1. Confirmez que le dernier déploiement est live et sert du trafic
  2. Accédez au point de terminaison de santé (ou racine) et vérifiez une réponse 200
  3. Analysez les journaux d'erreurs récents pour une signature d'échec claire
  4. Vérifiez les variables d'env requises et la liaison de port (0.0.0.0:$PORT)

Liste de contrôle détaillée et commandes : references/post-deploy-checks.md

Si le service ne démarre pas ou que les vérifications de santé expirent, utilisez le guide de triage basique : references/troubleshooting-basics.md

Dépannage

Accès réseau escaladé

Si le déploiement échoue en raison de problèmes réseau (délais d'expiration, erreurs DNS, connexions réinitialisées), relancez le déploiement avec des permissions escaladées (utilisez sandbox_permissions=require_escalated). Le déploiement nécessite un accès réseau escaladé quand le sandboxing bloque les requêtes sortantes.

Exemple de conseils à l'utilisateur :

Le déploiement nécessite un accès réseau escaladé pour déployer sur Render. Je peux relancer la commande avec des permissions escaladées—tu veux que je continue ?

Facultatif : Si vous avez besoin de diagnostics plus approfondis (vérifications de métriques/BD/catalogue d'erreurs), suggérez d'installer la compétence render-debug. Elle n'est pas requise pour le flux de déploiement principal.