Ce qui se passe réellement entre git push et votre application en ligne — et les leviers dont vous disposez quand ça tourne mal.

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. Si elle échoue à la vérification d’état, elle est arrêtée et le retour arrière automatique décide de la suite.

Commande de mise en production

Une commande de mise en production s’exécute une fois par déploiement en production : après une compilation réussie, et avant le démarrage de la nouvelle version. C’est l’endroit pour les migrations et le peuplement de la base de données — npx prisma migrate deploy, drizzle-kit migrate, php artisan migrate --force, python manage.py migrate. Définissez-la dans Paramètres → Compilation.

Elle s’exécute avec l’environnement de votre application, y compris DATABASE_URL. Si votre base de données donne à l’application une connexion limitée, activez Connexion propriétaire pour les migrations dans les paramètres d’accès de la base : la chaîne de connexion du propriétaire est alors disponible ici sous DATABASE_URL_MIGRATE. C’est une connexion de session : les outils de migration qui utilisent des verrous consultatifs fonctionnent. Ni les compilations ni l’application en marche ne la reçoivent. Les variables à portéeexécution seulement ne sont pas non plus dans la commande de mise en production.
En cas d’échec, le déploiement s’arrête et votre version actuelle reste en ligne.
Elle s’exécute seule : une commande qui s’arrête pour poser une question oui/non (Would you like to proceed? (y/N)) ne peut pas recevoir de réponse de la compilation. Après environ 20 secondes de silence devant une question, la page du déploiement l’affiche et, là où les réponses sont activées, propose Oui et Non; si personne n’est là, elle s’arrête après 5 minutes en indiquant ce qu’elle demandait. Pour éviter la question à chaque déploiement, donnez à la commande son option non interactive (--force pour prisma migrate reset et artisan migrate, --accept-data-loss pour prisma db push, --noinput pour collectstatic de Django) ou envoyez la réponse par un tube : printf 'y' | votre-commande.
Elle ne s’exécute jamais lors des déploiements d’aperçu, puisque ceux-ci partagent votre base de données de production.

Gardez les migrations hors de la commande de compilation : elles s’y exécuteraient avant qu’on sache si la compilation a réussi, et à chaque déploiement d’aperçu.

Des fichiers qui survivent aux déploiements

Chaque déploiement repart d’une copie neuve de votre application : un fichier qu’elle écrit à côté de son propre code est donc remplacé au déploiement suivant. Pour les fichiers à conserver, utilisez le répertoire de données : son chemin est dans CANNER_DATA_DIR, il appartient à votre application seule, et rien n’y change quand vous déployez.

// Node
const db = new Database(path.join(process.env.CANNER_DATA_DIR ?? '.', 'app.sqlite'));

# Python
db = sqlite3.connect(os.path.join(os.environ.get("CANNER_DATA_DIR", "."), "app.db"))

Il compte dans le stockage de votre organisation, avec les bases de données, les sauvegardes et le stockage d’objets.
Il est sauvegardé chaque nuit et supprimé seulement avec le projet.
Production seulement : les déploiements d’aperçu n’en ont pas, pour qu’un aperçu ne puisse pas toucher aux fichiers de production.
Une base SQLite que votre application garde déjà à côté de son code (par exemple data/app.sqlite) est copiée dans chaque nouveau déploiement pendant que l’application est arrêtée; elle n’est donc pas perdue — sauf si le nouveau déploiement contient un fichier au même chemin, qui a alors priorité. Le répertoire de données reste sa meilleure place.

Pour des données partagées entre plusieurs processus ou qui exigent une récupération à un instant précis, utilisez plutôt une base de données.

Commande de démarrage

Canner démarre votre application avec la commande qu’il détecte : votre script start, ou le serveur propre au framework. Pour en utiliser une autre, indiquez une commande de démarrage dans Paramètres → Compilation. Elle remplace la commande détectée dès votre prochain déploiement.

C’est une seule ligne, exécutée par sh -c depuis le répertoire de votre application; NODE_ENV=production node dist/index.js et pnpm migrate && node dist/server.js fonctionnent donc tous deux.
Écoutez sur le port de $PORT; Canner y met le numéro. Toute autre $VARIABLE provient de l’environnement de votre projet.
Elle s’exécute exactement là où s’exécute votre script start, sous l’utilisateur propre à votre projet : elle n’atteint donc pas plus que votre application. N’y mettez pas de secrets : la commande figure dans votre journal de déploiement. Utilisez des variables d’environnement.
Videz le champ pour revenir à la commande détectée.

Retour arrière automatique

Quand un déploiement en production ne démarre pas, Canner l’arrête. Avec le retour arrière automatique activé (par défaut), il recompile ensuite votre dernier bon commit et le déploie : le site revient à la version précédente. Désactivez-le avec l’interrupteur Retour arrière automatique de la vue d’ensemble du projet, et un déploiement raté reste arrêté jusqu’au prochain déploiement.

Désactivez-le quand une migration a déjà modifié la base de données d’une façon que la version précédente ne supporte pas : recompiler l’ancien commit échouerait de nouveau.
Il s’applique aux déploiements depuis GitHub. Ceux du CLI ou d’un téléversement n’ont aucun commit antérieur à recompiler et restent arrêtés dans les deux cas.
Une commande de mise en production qui échoue est un cas distinct : elle arrête le déploiement avant le démarrage de la nouvelle version, et la version actuelle reste en ligne.

Déploiements d’aperçu

Avec GitHub connecté, chaque demande de tirage (PR) obtient son propre aperçu isolé à branche--projet.canner.app, 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 recompile n’importe quel déploiement réussi antérieur à partir de son commit et le déploie comme un nouveau; le commit doit donc encore se trouver dans le dépôt. 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.

Secrets dans les journaux de requêtes de Canner

Les journaux de requêtes de Canner (le journal d’accès du mandataire et le journal de requêtes de la plateforme) remplacent la valeur de ces paramètres d’URL par REDACTED, de sorte qu’une redirection OAuth comme /callback?code=…&state=… n’est jamais inscrite. L’URL elle-même, ce que voient les visiteurs et ce que reçoit votre application ne changent pas, et la sortie de journal de votre application n’est pas touchée. La correspondance ignore la casse et l’encodage en pourcentage; tout autre paramètre est journalisé tel quel.

code : le code d’autorisation OAuth que renvoie un fournisseur de connexion ou de paiement.
state : la valeur d’état OAuth qui relie la redirection à la session qui l’a lancée.
token, access_token, id_token, refresh_token : jetons porteur, d’accès, d’identité et de rafraîchissement.
client_secret : un secret client OAuth.
password : un mot de passe envoyé dans une URL.
api_key, apikey : des clés d’API.
signature, sig : signatures de webhook, de requête et d’URL signée.

Builds, aperçus et retours en arrière.