Sites et déploiements

Commencez par choisir si le Cloud doit provisionner un site géré ou déployer une application à partir d'un référentiel. Ces chemins utilisent des contrôles différents et ont des exigences d'accès différentes.

Créer un site géré#

1. Ouvrez Nouveau projet lorsque vous êtes connecté.
2. Choisissez WordPress, PrestaShop ou PRISM. Choisissez le CMS natif uniquement lorsque vous souhaitez un starter PRISM avec gestion de contenu.
3. Entrez un nom de site. Les slugs gérés utilisent de 1 à 28 lettres minuscules, chiffres ou tirets, sans tiret de début ou de fin.
4. Suivez la progression du provisionnement. WordPress et PrestaShop s'installent en arrière-plan ; soumettre le formulaire ne signifie pas qu’ils sont prêts.
5. Enregistrez les informations d'identification du back-office lorsque le résultat est affiché. Les informations d’identification d’installation en arrière-plan sont renvoyées une fois.

Le nom d’hôte de préproduction est <slug>.staging.bext.dev. Cloud vérifie l'allocation de site et l'abonnement de votre compte avant de créer un autre site géré. Un nom détenu par un autre projet géré n'est pas disponible même si vous ne pouvez pas voir ce projet.

Le nom et la structure d'un site géré sont fixes car ils identifient l'installation en direct. Un projet de démarrage PRISM est déjà provisionné et n'accepte pas de déploiement Git ; créez un projet Git distinct pour déployer le code du référentiel.

Déployer à partir d'un référentiel#

Créez un projet avec un framework pris en charge, son URL de référentiel et, si nécessaire, une cible de déploiement existante. Ouvrez le projet pour demander un déploiement et suivez son historique de compilation.

Les compilations du dépôt sur la plateforme gérée sont actuellement réservées aux administrateurs de plateforme. La création d'un projet ou la fourniture d'une URL de référentiel ne supprime pas cette restriction. Les cibles externes sont soumises à leurs propres contrôles de fournisseur et de connexion. Si Cloud refuse un déploiement, utilisez l'explication renvoyée plutôt que de traiter le projet comme déployé avec succès.

Pour demander un déploiement via l'API :

curl -X POST \
  "https://cloud.bext.dev/api/projects/$PROJECT_ID/deploys" \
  -H "Authorization: Bearer $BEXT_CLOUD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"git_ref":"main"}'

PROJECT_ID vient de GET /api/projects. La référence Git doit exister dans le référentiel configuré. Cet exemple demande une compilation ; inspectez l'historique de déploiement pour son résultat :

curl "https://cloud.bext.dev/api/projects/$PROJECT_ID/deploys" \
  -H "Authorization: Bearer $BEXT_CLOUD_TOKEN"

Attendez l'état final, inspectez les erreurs de construction en cas d'échec et vérifiez l'application à son URL servie après le succès. Un déplacement de site, une cible invalide, des variables d'environnement illisibles ou une restriction de plateforme peuvent empêcher un déploiement.

Connecter un domaine#

1. Ajoutez le nom d'hôte à la liste des domaines du projet.
2. Publiez le défi de propriété DNS et les enregistrements d'adresse affichés par Cloud.
3. Exécutez la vérification. Cloud vérifie le contrôle du domaine et si le nom d'hôte pointe vers le serveur attendu.
4. Utilisez le contrôle de publication du site pour sélectionner les domaines vérifiés et le nom d'hôte principal.
5. Vérifiez HTTPS et la réponse de l'application sur le domaine public.

La publication sur votre propre domaine nécessite un plan éligible. Un nom d'hôte résolu sur le serveur ne constitue pas une preuve de propriété suffisante. Les comptes non-administrateurs doivent utiliser des domaines attachés à ce projet, et Cloud revérifie la propriété avant la publication.

Pour MCP, utilisez add_domain, verify_domain, puis publish_site avec dry_run: true pour prévisualiser l'opération. Une publication réelle utilise dry_run: false et confirm égaux au slug exact du site. Voir le Flux de travail MCP.

Restaurer un site Git#

Lorsque des versions Git conservées sont disponibles, Cloud peut réactiver la version précédente. D'autres fournisseurs peuvent rejeter la restauration comme étant indisponible. Un enregistrement de déploiement historique ne garantit pas à lui seul que ses fichiers peuvent être restaurés.

L'outil MCP rollback_site active la version immédiatement précédente, la version Git conservée. Il nécessite l'ID exact du projet comme confirmation ; il ne sélectionne pas de version par ID de déploiement. Après la restauration, vérifiez à nouveau le site et l'historique de déploiement.

Avant de supprimer un site#

Téléchargez toute sauvegarde que vous devez conserver avant de détruire un site géré. La destruction du site peut supprimer son installation en direct ; demander une purge de fichier supprime également ses fichiers. Le projet d'un site géré constitue son enregistrement de propriété. Utilisez donc l'action de destruction de site plutôt que de supprimer cet enregistrement de projet indépendamment.

Pour connaître la disponibilité et la conservation des sauvegardes, consultez Sauvegardes cloud. Pour les échecs de compilation et de routage, commencez par dépannage.