Documentation · Guides

Variables d’environnement et secrets.

La configuration vit hors de votre code. Définissez des variables par projet dans le tableau de bord; elles sont présentes dans votre build et injectées dans votre application — chiffrées au repos dans les deux cas.

Définir des variables

Ouvrez l’onglet Variables d’environnement de votre projet et ajoutez des paires clé/valeur. Pour migrer une application existante, collez votre fichier .env entier dans l’éditeur en lot — il comprend le format standard :

DATABASE_URL=postgres://…
STRIPE_SECRET_KEY=sk_live_…
RESEND_API_KEY=re_…

Les changements s’appliquent au prochain déploiement — redéployez après modification pour que le build et le processus en cours voient tous deux les nouvelles valeurs.

Variables sensibles

Marquez une variable sensible et sa valeur devient en écriture seule : elle atteint toujours votre application normalement, mais le tableau de bord ne l’affiche plus jamais. À utiliser pour les clés API, les jetons et tout ce que vous ne voudriez pas voir par-dessus votre épaule.

Portées

Chaque variable a une portée qui décide quels déploiements et quelles phases la reçoivent :

  • production : les déploiements de production seulement (le build, la commande de mise en production et l’application en marche).
  • aperçu : les aperçus de demandes de tirage seulement.
  • toutes : production et aperçus.
  • exécution seulement : l’application en marche, en production. Jamais un build, la commande de mise en production ni un aperçu. Pour les secrets que votre build n’a pas à voir, comme la clé d’un fournisseur de paiement.

Build ou exécution

Les variables sont présentes pendant le build et à l’exécution, sauf celles à portée exécution seulement. La distinction qui compte est la règle d’exposition au navigateur de votre cadriciel :

  • Next.js — le code navigateur ne voit que NEXT_PUBLIC_*, intégré au build.
  • Vite — le code navigateur ne voit que VITE_* via import.meta.env, intégré au build.
  • Serveurs (Node, Python, Go, …) — lisent tout depuis l’environnement à l’exécution; aucune règle de préfixe.

Variables que Canner définit pour vous

  • PORT — le port sur lequel votre serveur doit écouter.
  • DATABASE_URL — définie automatiquement quand vous provisionnez une base Postgres.
  • NODE_ENV=production pour les builds et exécutions Node.

Les aperçus ne reçoivent que les variables à portée toutes ou aperçu, mais partagent la base de données du projet : un aperçu exécute le code d’une demande de tirage sur la base de production. Si un aperçu a besoin de valeurs différentes (une API de préproduction, par exemple), ou si le projet détient des identifiants réels, séparez-le dans son propre projet. L’arrangement simple : un projet de production dont les aperçus des demandes de tirage sont désactivés (réglages du projet, ou previews_enabled: false dans l’API), avec sa propre base de données et ses propres variables, et un projet de préproduction, qui peut être relié au même dépôt, où les aperçus restent actifs avec des identifiants d’essai et une base de préproduction. Désactiver les aperçus arrête les nouveaux aperçus et déploiements de branche; vous pouvez aussi supprimer ceux qui sont déjà en cours.