Déployer sur Render

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

Cette skill 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 également exécuter une image Docker préconstruite en utilisant runtime: image, mais render.yaml doit toujours se trouver dans un repo Git.

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

• Créer/pousser un remote Git (peut être minimal si seul le Blueprint est nécessaire), soit
• Utiliser le Dashboard Render/l'API pour déployer une image Docker préconstruite (MCP ne peut pas créer de services basés sur des images).

Prérequis

• 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 timeout appropriées.

Quand utiliser cette skill

Activez cette skill 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 jobs cron ou d'autres ressources Render

Chemin heureux (Nouveaux utilisateurs)

Utilisez cette courte séquence de prompts avant une analyse approfondie pour réduire les frictions :

1. Demandez s'ils veulent déployer depuis un repo Git ou une image Docker préconstruite.
2. Demandez si Render doit provisionner tout ce dont l'app a besoin (basé sur ce qui semble probable d'après la description de l'utilisateur) ou seulement l'app tandis qu'ils apportent leur propre infrastructure. Si les dépendances ne sont pas claires, posez une brève question de suivi pour confirmer s'ils ont besoin d'une base de données, de workers, cron ou d'autres services.

Ensuite, procédez à la méthode appropriée ci-dessous.

Choisir votre chemin source

Chemin Repo Git : Requis pour Blueprint et Création Directe. Le repo doit être poussé sur GitHub, GitLab ou Bitbucket.

Chemin Image Docker Préconstruite : Supporté par Render via les services basés sur des images. Ceci n'est pas supporté par MCP ; utilisez le Dashboard/l'API. Demandez :

• URL de l'image (registre + tag)
• Authentification au 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'images du Dashboard Render ou demandez-lui d'ajouter un remote Git (pour pouvoir utiliser un Blueprint avec runtime: image).

Choisir votre méthode de déploiement (Repo Git)

Les deux méthodes requièrent un repo Git poussé sur GitHub, GitLab ou Bitbucket. (Si vous utilisez runtime: image, le repo peut être minimal et contenir seulement render.yaml.)

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 une question uniquement si l'intention de déploiement n'est pas claire (ex : DB, workers, cron).

Utilisez la Création Directe (MCP) quand TOUS les points sont vrais :

• Service unique (une app web ou un site statique)
• Pas de service worker/cron séparé
• Pas de base de données attachée ou Key Value
• Seulement des variables d'env simples (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.

Utilisez Blueprint quand N'IMPORTE QUEL point est vrai :

• Plusieurs services (web + worker, API + frontend, etc.)
• Des bases de données, Redis/Key Value ou autres datastores sont requis
• Des jobs cron, des workers en arrière-plan ou des services privés
• Vous voulez une IaC reproductible ou un render.yaml commité au repo
• Setup monorepo ou multi-env qui nécessite une configuration cohérente

En cas de doute, posez une brève question de clarification, mais par défaut préférez Blueprint pour la sécurité. Pour un service unique, préférez fortement la Création Directe via MCP et guidez la configuration de MCP si nécessaire.

Vérification des prérequis

Quand vous commencez un déploiement, vérifiez ces prérequis 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 repo doit être poussé sur GitHub/GitLab/Bitbucket. Les Blueprints qui référencent une image préconstruite nécessitent toujours un repo Git avec render.yaml.

git remote -v

• Si aucun remote n'existe, arrêtez-vous et demandez à l'utilisateur de créer/pousser un remote ou de passer au 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 leur disponibilité en essayant :

list_services()

Si les outils MCP sont disponibles, vous pouvez sauter 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 MCP (si MCP n'est pas configuré)

Si list_services() échoue parce que MCP n'est pas configuré, demandez s'il veut configurer MCP (préféré) ou continuer avec le fallback CLI. S'il choisit MCP, demandez quel outil IA il utilise, puis fournissez les instructions correspondantes ci-dessous. Utilisez toujours sa 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 réessayez 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 réessayez 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 réessayez list_services().

Autres outils

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

Sélection de l'espace de travail

Après que MCP soit configuré, demandez à l'utilisateur de définir l'espace de travail Render actif avec un prompt comme :

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

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

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

# Vérifier 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 demandez explicitement à l'utilisateur de s'authentifier :

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

• Clé API (CLI) : export RENDER_API_KEY="rnd_xxxxx" (Obtenez à https://dashboard.render.com/u/*/settings#api-keys)
• Connexion : render login (Ouvre le navigateur pour OAuth)

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

Vérifiez l'espace de travail actif :

get_selected_workspace()

Ou via la CLI :

render workspace current -o json

Pour lister les espaces de travail disponibles :

list_workspaces()

Si l'utilisateur a besoin de changer d'espace de travail, il doit le faire via le Dashboard ou la CLI (render workspace set).

Une fois les prérequis satisfaits, procédez au flux de déploiement.

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

Flux Blueprint

Étape 1 : Analyser la base de code

Analysez la base de code pour déterminer le framework/runtime, les commandes de build et de démarrage, les variables d'env requises, les datastores 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'app a besoin
• Marquez les secrets avec sync: false (l'utilisateur les remplit au Dashboard)
• 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 au Dashboard

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

Types de service :

• web : Services HTTP, APIs, applications web (publiquement accessibles)
• worker : Processeurs de jobs en arrière-plan (pas publiquement accessibles)
• cron : Tâches planifiées qui s'exécutent selon une planification 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 templates : assets/

Étape 2.5 : Prochaines étapes 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 la validation immédiatement quand la CLI est disponible :

1. Authentifier (CLI) : exécuter render whoami -o json (si non connecté, exécuter render login ou définir RENDER_API_KEY)
2. Valider (recommandé) : exécuter 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 Dashboard : Utilisez le deeplink Blueprint et complétez 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 ; posez une question uniquement si la CLI manque :

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

Corrigez les erreurs de validation avant de continuer. 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 repo avant de déployer.

Assurez-vous que le fichier render.yaml est commité et poussé vers votre remote Git :

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

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

Pourquoi c'est important : Le deeplink Dashboard lira le render.yaml depuis votre repo. 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 est dans votre repo distant avant de procéder à l'étape suivante.

Étape 5 : Générer le deeplink

Obtenez l'URL du repo 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 :

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

Formatez le deeplink Dashboard en utilisant l'URL du repo 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 vers son repo avant de cliquer sur le deeplink. Si le fichier n'est pas dans le repo, Render ne peut pas lire la configuration Blueprint et le déploiement échouera.

Fournissez le deeplink à l'utilisateur avec ces instructions :

1. Vérifier que render.yaml est fusionné - Confirmez que le fichier existe dans votre repo sur GitHub/GitLab/Bitbucket
2. Cliquez sur le deeplink pour ouvrir le Dashboard Render
3. Complétez OAuth du fournisseur Git si demandé
4. Nommez le Blueprint (ou utilisez le défaut depuis render.yaml)
5. Remplissez les variables d'env secrètes (marquées avec sync: false)
6. Vérifiez la configuration des services et des bases de données
7. Cliquez sur « Apply » pour déployer

Le déploiement commencera automatiquement. Les utilisateurs peuvent surveiller la progression au Dashboard Render.

Étape 7 : Vérifier le déploiement

Après que l'utilisateur déploie via Dashboard, vérifiez que tout fonctionne.

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

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

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

Vérifier les erreurs runtime (attendre 2-3 minutes après le déploiement) :

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

Vérifier les métriques de santé du service :

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

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

Méthode 2 : Création de service direct (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 la création directe

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

Prérequis pour la création directe

Le repo doit être poussé vers un fournisseur Git. Render clone votre repo pour construire et déployer les services.

git remote -v  # Vérifier que le remote 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 remote, arrêtez-vous et demandez à l'utilisateur de créer/pousser un remote ou de passer au déploiement d'image Docker.

Note : MCP ne supporte pas la création de services basés sur des images. Utilisez le Dashboard/l'API pour les déploiements d'images Docker préconstruites.

Flux de création directe

Utilisez les étapes concises ci-dessous et reportez-vous à 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 build/démarrage, les variables d'env et les datastores.

Étape 2 : Créer des ressources via MCP

Créez le service (web ou static) et les bases de données ou key-value stores requis. Voir references/direct-creation.md.

Si MCP retourne une erreur concernant les identifiants Git manquants ou l'accès au repo, arrêtez-vous et guidez l'utilisateur pour connecter son fournisseur Git au Dashboard Render, puis réessayez.

Étape 3 : Configurer les variables d'env

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

Rappelez à l'utilisateur que les secrets peuvent être définis au Dashboard 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 logs 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 cela court et répétable. Si l'une des vérifications échoue, corrigez-la avant de redéployer.

1. Confirmez que le dernier déploiement est live et sert du trafic
2. Frappez le endpoint de santé (ou racine) et vérifiez une réponse 200
3. Scannez les logs d'erreur 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 échoue au démarrage ou 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 (timeouts, erreurs DNS, réinitialisations de connexion), 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 sandbox bloque les requêtes sortantes.

Exemple de guidance pour l'utilisateur :

Le déploiement a besoin d'un accès réseau escaladé pour déployer vers Render. Je peux relancer la commande avec des permissions escaladées—veux-tu que je procède ?

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