Variables d'environnement

Où se trouvent les paramètres

Créez le fichier de chaque application à partir du .env.example situé à côté, qui documente chaque variable : cp .env.example .env. Les exemples fonctionnent tels quels pour un lancement local, et le démarrage avec Docker Compose n'a besoin d'aucun fichier.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier du site, et chaque valeur y est facultative. Les valeurs NEXT_PUBLIC_* sont lues quand le site est construit et sont publiques, elles ne contiennent donc jamais de secret ; API_INTERNAL_URL est lue par le serveur du site lui-même. Sans le fichier, le site fonctionne sur ses données d'exemple intégrées. Pour utiliser une API, créez-le à partir de .env.example, qui en désigne une sur http://localhost:8000 : cp .env.example .env. Avec Docker, passez les valeurs NEXT_PUBLIC_* en --build-arg et API_INTERNAL_URL avec -e.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier du tableau de bord, lu quand le tableau de bord est construit et, pour PORT, quand yarn dev ou yarn start démarre. Chaque valeur y est publique, il ne contient donc jamais de secret : les clés de fournisseur et de paiement vivent dans le .env de l'API. Sans le fichier, le tableau de bord fonctionne sur ses données d'exemple intégrées. Pour utiliser une API, créez-le à partir de .env.example, qui en désigne une sur http://localhost:8000 : cp .env.example .env. Avec Docker, passez les mêmes valeurs en --build-arg.

Où se trouvent les paramètres

Un seul fichier, .env dans le dossier de l'API, lu par l'API avec yarn dev, yarn start:prod et yarn seed. Il contient des secrets : ne le versionnez jamais. Créez-le à partir de .env.example, qui documente chaque variable et fonctionne tel quel pour un lancement local : cp .env.example .env.

L'image Docker définit ses propres valeurs par défaut, si bien que docker run fonctionne sans fichier : NODE_ENV=production, SQLite sur /data/database.sqlite, fichiers téléversés dans /data/uploads, CORS_ORIGIN pour les deux frontends locaux, FRONTEND_URL et DASHBOARD_URL réglés sur http://localhost:3031, WEBSITE_URL=http://localhost:3030, PUBLIC_API_URL=http://localhost:8000 et PUBLIC_MEDIA_URL=http://localhost:8000/media. Remplacez n'importe laquelle avec -e.

Paramètres essentiels de l'API

L'API vérifie JWT_SECRET et, en production, CORS_ORIGIN avant de démarrer. Si l'un manque ou est inutilisable, elle s'arrête avec une ligne commençant par The API cannot start: qui dit quoi corriger.

Générez votre propre JWT_SECRET avec :

node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

Chaque fonctionnalité facultative ci-dessous est désactivée tant que ses variables dans .env.example restent vides.

Paiements

Deux parcours encaissent de l'argent. La page Billing du tableau de bord change la formule d'abonnement d'un espace de travail, et le paiement du site vend les licences. Tous deux ne prennent les données de carte que sur la page de Stripe ou de PayPal (un passage à une formule supérieure est facturé sur la carte que Stripe détient déjà) : elles ne sont donc jamais saisies sur votre site, et tous deux fonctionnent sans aucun compte grâce à des paiements test intégrés qui ne débitent personne. Utilisez d'abord des clés de test : elles ne déplacent aucun argent.

STRIPE_SECRET_KEY=sk_test_your_key
STRIPE_WEBHOOK_SECRET=whsec_your_secret
BILLING_PROVIDER=
BILLING_GRACE_DAYS=7
PAYPAL_CLIENT_ID=your-client-id
PAYPAL_CLIENT_SECRET=your-client-secret
PAYPAL_ENV=sandbox

Sur votre ordinateur, Stripe ne peut pas atteindre le webhook : les pages de retour demandent donc elles-mêmes la session à Stripe, et un paiement test aboutit quand même. Une formule ou une licence n'est comptée comme payée qu'une fois que l'API l'a vérifiée auprès du fournisseur, jamais à partir de la seule adresse de retour. Northstack n'applique aucune taxe de lui-même : configurez la fiscalité de votre pays avant d'encaisser de vrais paiements.

• Facturation des abonnements
• Le paiement des licences

E-mail

Les invitations, les réinitialisations de mot de passe, les reçus de licence, les e-mails de facturation et le résumé hebdomadaire sont envoyés par SMTP dès que SMTP_HOST est défini, chacun dans la langue du destinataire (celle de l'espace de travail quand il n'en a choisi aucune). Jusque-là, chaque message est écrit dans le journal de l'API à la place, liens compris, pour qu'une installation locale puisse les suivre (avec Docker : docker compose logs api).

SMTP_HOST=smtp.your-provider.com
SMTP_PORT=587
SMTP_SECURE=false
SMTP_USER=your-smtp-user
SMTP_PASSWORD=your-smtp-secret
SMTP_FROM=Northstack <no-reply@your-domain.com>
CONTACT_INBOX=hello@your-domain.com

SMTP_SECURE=true convient à un serveur qui parle TLS dès le premier octet, généralement sur le port 465. CONTACT_INBOX est l'adresse vers laquelle sont transférés les messages du formulaire de contact du site ; vide, ils ne restent que dans la base.

Utiliser MySQL au lieu de SQLite

Créez une base de données vide, puis définissez le pilote et la connexion dans le .env de l'API :

DB_TYPE=mysql
DB_HOST=localhost
DB_PORT=3306
DB_USERNAME=root
DB_PASSWORD=your-database-secret
DB_DATABASE=northstack

Puis lancez yarn seed, qui crée les tables et les données d'exemple. L'API en cours d'exécution ne crée et ne met à jour les tables elle-même que si NODE_ENV=development : avec NODE_ENV=production, lancez donc une fois yarn admin:create:prod après yarn build pour les tables et votre premier admin de la plateforme (yarn seed:prod pour une installation d'exemple), et yarn schema:prod après chaque mise à jour. L'image Docker crée seule la base sur SQLite uniquement : sur MySQL, lancez vous-même une fois node dist/database/create-admin.js (ou node dist/database/seeder.js) dans le conteneur.

Fichiers téléversés et médias

L'API sert elle-même les fichiers de marque du kit sur /media. Les fichiers et images de projet téléversés depuis le tableau de bord, 10 Mo au maximum chacun, sont stockés sur le disque de l'API sous MEDIA_UPLOAD_DIR et servis sur /media/uploads/…, sauf si un bucket est défini.

PUBLIC_MEDIA_URL=http://localhost:8000/media
MEDIA_UPLOAD_DIR=./public/media/uploads

PUBLIC_MEDIA_URL est l'adresse à laquelle un navigateur atteint /media. Sur un serveur, pointez MEDIA_UPLOAD_DIR vers un stockage persistant ; avec Docker, il est dans le volume de données, et le conteneur y déplace seul un dossier relatif. L'API envoie chaque fichier là-bas avec nosniff, et un fichier qui n'est ni une image, ni un PDF, ni du texte brut, ni de l'audio ou de la vidéo en téléchargement.

Pour envoyer les fichiers téléversés vers un bucket Cloudflare R2, définissez les cinq variables. Avec moins de cinq, les fichiers restent sur le disque. Le journal de l'API indique le stockage utilisé au démarrage : Media storage: R2 bucket suivi du nom du bucket, ou Media storage: local folder suivi du dossier.

R2_ACCESS_KEY_ID=your-r2-access-key-id
R2_SECRET_ACCESS_KEY=your-r2-secret-access-key
R2_ENDPOINT=https://your-account-id.r2.cloudflarestorage.com
R2_BUCKET_NAME=your-bucket-name
R2_PUBLIC_URL=https://your-public-url.r2.dev

Site et tableau de bord

Chaque valeur NEXT_PUBLIC_* est compilée dans le JavaScript que charge le navigateur, et quiconque ouvre la page peut la lire. N'y mettez jamais de secret, et reconstruisez (ou redémarrez yarn dev) après en avoir changé une. Avec Docker, passez-les en --build-arg.

NEXT_PUBLIC_API_BASE_URL détermine d'où viennent les données de chaque frontend. Vide, ou sans aucun .env, l'application fonctionne sur ses données d'exemple intégrées et n'appelle aucune API. Définie avec l'adresse de l'API /api comprise (http://localhost:8000/api dans .env.example et dans les images Docker), elle utilise cette API, et ne prend le relais avec les données d'exemple dans le navigateur que tant que cette API ne répond pas.

• Les données d'exemple

Les paramètres du site

Le port du site est 3030, écrit dans les scripts de son package.json. Pour un autre, lancez yarn next dev -p 3040 (ou yarn next start -p 3040 après yarn build).

Les paramètres du tableau de bord

Aucune clé de fournisseur d'IA ou de paiement n'a sa place ici : une valeur NEXT_PUBLIC_* est visible par quiconque ouvre la page. Un fournisseur pour lequel l'API n'a pas de clé peut quand même être utilisé avec une clé que le lecteur ajoute dans l'assistant lui-même.

Options de Docker Compose

Rien n'est à définir pour une exécution en local. Pour changer quelque chose, placez-le dans un fichier .env à côté de docker-compose.yml et relancez docker compose up --build : les frontends intègrent ces valeurs à la compilation.

Changez un port quand un autre programme l'utilise déjà, par exemple ADMIN_PORT=3041. Le CORS_ORIGIN, FRONTEND_URL, DASHBOARD_URL, WEBSITE_URL, PUBLIC_API_URL et PUBLIC_MEDIA_URL de l'API, ainsi que les adresses d'API, de site et de tableau de bord des frontends, sont tous construits à partir des ports et des trois adresses, et suivent donc d'eux-mêmes.

• Un port est déjà utilisé

Le conteneur de l'API lit aussi back-end/.env s'il existe : les clés facultatives (Stripe, PayPal, e-mail, R2, IA, MCP) se règlent donc au même endroit pour yarn dev comme pour Docker. docker-compose.yml l'emporte pour les valeurs qui diffèrent dans un conteneur : NODE_ENV=production, le port, le chemin de la base, le dossier des fichiers téléversés et les adresses ci-dessus. Sans JWT_SECRET à vous, ou avec celui de l'exemple, l'API en génère un et le garde dans le volume de données. La base et les fichiers téléversés vivent dans le volume northstack-data.

Clés de l'assistant IA

Le serveur MCP

Mode démo