Comment un build s’exécute
Chaque déploiement est compilé dans un bac à sable isolé : son propre utilisateur Linux, son propre budget mémoire (plafonné par forfait — voir les limites), aucun accès aux autres locataires ni aux services de la plateforme. Les scripts d’installation des dépendances sont désactivés par défaut pour la sécurité de la chaîne d’approvisionnement; si un paquet a réellement besoin de son script de build (p. ex. sharp), autorisez-le explicitement avec une entrée canner.allowedBuildScripts dans votre package.json. Vos node_modules et les caches de cadriciel (comme .next/cache) persistent entre les builds — les recompilations sont rapides.
Le journal de build est diffusé en direct dans le tableau de bord. Quand le build réussit, la nouvelle version démarre, doit répondre à la vérification d’état (répondre sur / — ou votre chemin configuré — en 30 secondes), et seulement ensuite prend le trafic. Une vérification échouée laisse l’ancienne version en service.
Déploiements d’aperçu
Avec GitHub connecté, chaque demande de tirage (PR) obtient son propre aperçu isolé à branche--projet.app.canner.ca, recompilé à chaque poussée sur la branche et nettoyé à la fermeture de la PR. Les aperçus partagent les variables d’environnement du projet, mais jamais son processus de production.
Réessayer, annuler, revenir en arrière
- Réessayer relance un build échoué depuis le même commit ou téléversement — utile après avoir corrigé une variable d’environnement.
- Annuler arrête un build en file d’attente ou en cours.
- Retour en arrière réactive instantanément n’importe quel déploiement réussi antérieur — l’ancien paquet est encore sur disque, donc aucune recompilation. Sous l’onglet Déploiements.
Veille et réveil sur le forfait gratuit
Les applications Starter se mettent en veille après 3 heures sans requête. Le visiteur suivant réveille l’application automatiquement — il attend quelques secondes pendant le démarrage, puis tout est normal. Les forfaits payants (Live et plus) gardent les applications toujours actives — c’est la raison de passer au niveau supérieur quand un vrai public dépend de votre site.
Journaux
L’onglet Journaux diffuse en direct la sortie de votre application (stdout/stderr). Les journaux de build accompagnent chaque déploiement sous l’onglet Déploiements. Si votre application plante au démarrage, le message d’échec de la vérification d’état dans le journal de build inclut la fin du journal d’exécution — c’est le premier endroit où regarder. Pour la signification des messages précis, voir Erreurs courantes de build et de déploiement.