Git est le moyen le plus rapide de faire tourner un service sur Qeda : poussez votre code, connectez le dépôt une fois, et chaque déploiement suivant se fait en quelques clics. Qeda essaie d'abord de détecter votre stack automatiquement avec Cloud Native Buildpacks — si votre dépôt a déjà un Dockerfile, il le build à la place.
Connecter votre compte GitHub
La première fois que vous déployez depuis GitHub, Qeda vous demande de connecter votre compte via la Qeda GitHub App. Cela arrive une fois par compte, pas une fois par projet — chaque projet suivant réutilise la même connexion.
Remarque. Si un dépôt que vous attendiez n'apparaît pas, c'est que la GitHub App n'y a pas encore accès — utilisez « Add repositories » pour en accorder davantage côté GitHub, sans refaire toute la connexion.
Choisir un dépôt
Une fois connecté, vous obtenez une liste recherchable de tous les dépôts visibles par la GitHub App — compte personnel et toute organisation dont vous êtes membre, interchangeables depuis le menu déroulant au-dessus de la liste. Une icône de cadenas marque les dépôts privés ; un globe marque les dépôts publics.
Détection automatique de la stack
Sélectionner un dépôt déclenche la détection : Qeda cherche package.json, requirements.txt, un Dockerfile et go.mod pour déterminer ce qu'il est — Node.js, Python, Go, Rust, Docker, ou un site statique — avant même de construire quoi que ce soit.
Remarque. Si la détection ne peut pas déterminer avec certitude de quoi il s'agit, un écran de configuration demande une commande de build, une commande de démarrage et un port avant de continuer. Sinon, Qeda déploie immédiatement — ces valeurs peuvent toujours être ajustées après coup depuis l'onglet Settings du service.
Suivre le build
Une fois la détection terminée, le build démarre immédiatement : un badge de statut en direct (Building → Deploying) à côté d'un flux en temps réel du log de build — la même sortie que produit le builder de la plateforme, pas une barre de progression simulée.
« View Project » vous emmène sur le canevas du projet, où le nouveau service apparaît désormais comme sa propre carte avec un badge de statut en direct. Chaque push suivant sur la branche connectée peut être redéployé de la même façon depuis l'onglet History du service, sans repasser par la sélection du dépôt.
Utiliser un Dockerfile à la place
Si votre dépôt a un Dockerfile, Qeda le build directement au lieu de deviner un buildpack — aucune étape supplémentaire de votre côté. Si un dépôt a à la fois une stack reconnaissable et un Dockerfile, l'onglet Settings du service a un menu déroulant Builder (Auto / Dockerfile / Railpack, ignore Dockerfile) pour forcer l'un ou l'autre ; passer sur Dockerfile révèle un champ de chemin pour un emplacement non standard.
Si un déploiement échoue
Un build échoué ou un service qui ne devient jamais healthy affiche un panneau d'échec dédié sur le canevas du projet : quelle étape a échoué, les dernières lignes du log concerné, et un diagnostic tiré des propres événements de déploiement de la plateforme — pas juste un point rouge sans explication. « Fix & redeploy from latest commit » relance le build une fois le problème sous-jacent corrigé dans le dépôt.