Configuration
Remplir le .env par étapes, en comprenant ce que chaque groupe de variables active.
Le .env généré vient de node_modules/@lrvo/core/.env.example. Cette page le parcourt par ordre de nécessité : ce qu'il faut pour démarrer, puis ce que chaque service ajoute.
La référence exhaustive est dans Variables d'environnement.
Le minimum
Trois variables suffisent à faire tourner l'application.
NEXT_PUBLIC_URL=http://localhost:3000
LRVO_NAME=Mon site
LRVO_DATABASE_URL=postgres://user:password@localhost:5432/mon_projetNEXT_PUBLIC_URL n'est pas optionnel. C'est l'origine publique du site, utilisée pour les liens dans les courriels, le canonical SEO, les assets des PDF, et la vérification CSRF. Sans elle, les requêtes mutantes sont refusées.
En développement, NEXT_PUBLIC_URL_DEV prend le pas quand NODE_ENV=development, ce qui permet de garder l'URL de production dans le même fichier.
Base de données
LRVO_DATABASE_URL=postgres://user:password@host:5432/mon_projet
LRVO_DATABASE_URL_DEV=postgres://user:password@localhost:5432/mon_projet_devTLS
Le comportement par défaut est strict en production et permissif ailleurs. Trois surcharges existent, évaluées dans cet ordre :
| Variable | Effet |
|---|---|
LRVO_DB_SSL_DISABLED=true | Pas de TLS. Liens locaux de confiance uniquement. |
LRVO_DB_SSL_NO_VERIFY=true | TLS actif, certificat non vérifié. Chiffre le trafic et tolère un certificat auto-signé sur réseau privé. |
LRVO_DB_SSL_CA=… | TLS strict, épinglé sur l'autorité fournie. PEM inline, ou chemin de fichier. |
En local sans TLS, poser LRVO_DB_SSL_DISABLED=true. En production derrière un réseau privé, préférer LRVO_DB_SSL_CA à LRVO_DB_SSL_NO_VERIFY : le second chiffre mais n'authentifie pas le serveur.
L'URL fournie par un serveur PostgreSQL managé se termine souvent par ?sslmode=allow. Rien à retirer à la main : le core le fait, et le mode sert de valeur par défaut si aucune des trois variables n'est posée. Voir Paramètres TLS dans l'URL.
Régional
LRVO_TIMEZONE=America/Toronto
LRVO_DATE_FORMAT=YYYY-MM-DD
LRVO_CURRENCY=CAD
LRVO_CURRENCY_SYMBOL=$
LRVO_SUPPORT_EMAIL=[email protected]LRVO_TIMEZONE est aussi le fuseau par défaut des tâches planifiées.
La plateforme travaille avec une devise unique. Il n'y a pas de conversion ni de devise par ligne.
Derrière un reverse proxy
LRVO_TRUST_PROXY=trueÀ activer uniquement derrière un proxy vérifié. La variable autorise la lecture des en-têtes de proxy pour déterminer l'IP du client, ce qui conditionne la limitation de débit.
Sa valeur est le nombre de proxys que traverse une requête avant d'atteindre l'application. true vaut 1. Derrière deux proxys, Cloudflare puis nginx par exemple, écrire LRVO_TRUST_PROXY=2. Le compte doit être exact : trop bas, tous les visiteurs partagent le compteur du proxy amont, trop haut, l'adresse lue redevient falsifiable. Le détail est dans Déploiement.
Sans proxy devant, n'importe quel client pourrait forger un X-Forwarded-For variable et contourner la limitation. Quand l'IP reste indéterminable, la limitation est suspendue et un avertissement opérateur est émis une seule fois.
Laisser à false en développement local.
Courriel
LRVO_EMAIL_PROVIDER=resend
LRVO_EMAIL_RESEND_APIKEY=re_…
LRVO_EMAIL_FROM_ADDRESS=[email protected]
LRVO_EMAIL_FROM_NAME="Mon site"
LRVO_EMAIL_LOGO=https://exemple.com/logo.png
LRVO_EMAIL_LOGO_URL=https://exemple.comAvec un relais SMTP au lieu de Resend, les trois premières lignes deviennent :
LRVO_EMAIL_PROVIDER=smtp
LRVO_EMAIL_SMTP_HOST=mail.exemple.com
LRVO_EMAIL_SMTP_PORT=587
LRVO_EMAIL_SMTP_USER=[email protected]
LRVO_EMAIL_SMTP_PASSWORD=…Sans fournisseur de courriel configuré, l'inscription fonctionne mais le courriel de vérification ne part pas. En développement, Resend n'envoie qu'aux adresses vérifiées tant que le domaine ne l'est pas ; un relais SMTP local échappe à cette limite.
Voir Envoyer un courriel.
Stockage
LRVO_STORAGE_PROVIDER=backblaze
LRVO_STORAGE_ENDPOINT=s3.<region>.backblazeb2.com
LRVO_STORAGE_REGION=<region>
LRVO_STORAGE_BUCKET=mon-bucket
LRVO_STORAGE_ACCESS_KEY=
LRVO_STORAGE_SECRET_KEY=Un seul jeu de variables sert les deux providers. Backblaze B2 est le fournisseur par défaut : son endpoint prend la forme s3.<region>.backblazeb2.com et LRVO_STORAGE_REGION y est obligatoire. Pour Cloudflare R2, poser LRVO_STORAGE_PROVIDER=r2, un endpoint de la forme <accountId>.r2.cloudflarestorage.com, et laisser LRVO_STORAGE_REGION vide, qui vaut alors auto.
Sans configuration, tout ce qui touche aux fichiers échoue : photo de profil, médiathèque, pièces jointes.
Authentification
LRVO_AUTH_REDIRECT_AFTER_LOGIN=/admin
LRVO_AUTH_SESSION_COOKIE_NAME=lrvo_sessionChanger le nom du cookie invalide toutes les sessions en cours.
Chiffrement
LRVO_ENCRYPTION_KEY=Requise dès qu'un module chiffre des secrets en base. npx @lrvo/start la remplit à la création du projet : il n'y a rien à saisir. Sur un projet monté à la main, ou si la ligne est restée vide, générer une clé :
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"Traiter cette clé comme permanente. Il n'y a pas de versionnage : la changer rend illisible tout ce qui a été chiffré avec l'ancienne. Voir Chiffrer des secrets.
Paiements
STRIPE_SECRET_KEY=sk_…
STRIPE_PUBLISHABLE_KEY=pk_…
STRIPE_WEBHOOK_SECRET=whsec_…Tant que les deux premières sont absentes, isEnabled() retourne false et l'interface de paiement peut se masquer proprement.
Récupérer les deux clés
Elles sont dans le tableau de bord Stripe, sous Développeurs → Clés d'API. La bascule Mode test, en haut du tableau de bord, décide desquelles il s'agit : les clés de test commencent par sk_test_ et pk_test_, celles de production par sk_live_ et pk_live_.
La clé publique s'affiche telle quelle. La clé secrète se révèle d'un clic en mode test, mais seulement à sa création en mode production : si elle est perdue, en générer une nouvelle plutôt que de chercher à relire l'ancienne.
Les deux jeux ne se mélangent pas. Une session créée avec une clé de test n'est pas lisible avec une clé de production, et l'erreur ne se voit qu'au premier paiement réel.
Créer le webhook
STRIPE_WEBHOOK_SECRET n'est pas une clé de compte : elle appartient à un endpoint précis. Il faut donc créer l'endpoint avant de pouvoir remplir la variable.
Dans Développeurs → Webhooks → Ajouter un endpoint :
| Champ | Valeur |
|---|---|
| URL | https://exemple.ca/lrvo/api/payments/stripe/webhook |
| Événements | checkout.session.completed au minimum, plus charge.refunded si les remboursements doivent être enregistrés. |
Il n'y a aucun fichier à créer. L'endpoint fait partie du core, au même titre que /lrvo/api/health : il est servi dès que le routeur est monté. Il vérifie la signature, puis remet l'événement à qui s'y est abonné. Le module de facturation s'abonne tout seul ; pour traiter un événement dans le code du projet, voir Accepter des paiements.
Le secret de signature s'affiche ensuite sur la page de l'endpoint, sous Signing secret. C'est celui-là qui va dans STRIPE_WEBHOOK_SECRET.
Un endpoint par mode. Le mode test et le mode production tiennent chacun leur liste de webhooks, avec leur propre secret. Un secret de test posé en production fait échouer toutes les vérifications de signature.
Vérifier en local
Le CLI Stripe génère son propre secret, distinct de celui du tableau de bord :
stripe listen --forward-to localhost:3000/lrvo/api/payments/stripe/webhookLa commande affiche un whsec_… à poser dans le .env de développement. Confondre les deux fait échouer la vérification de signature sans autre symptôme qu'un 400.
SEO
LRVO_SEO=true
LRVO_SEO_SEPARATOR=-
LRVO_SEO_TITLE_TEMPLATE=%title% %sep% %sitename%Le flag active la zone SEO dans les éditeurs de contenu et la génération des balises <head>. Voir SEO et métadonnées.
Développement
LRVO_DEVKIT=false
NEXT_TELEMETRY_DISABLED=1LRVO_DEVKIT=true expose /admin/devkit/components et /admin/devkit/icons : la galerie des composants partagés et le catalogue d'icônes. Utile pour vérifier un rendu dans les deux thèmes. Il affiche aussi la tuile Liens rapides du tableau de bord, qui mène à cette documentation. À laisser à false en production.
Modules
Chaque module installé porte sa variable d'activation.
LRVO_MODULE_MEDIAS=trueUn module installé mais non activé n'enregistre rien : ni page d'admin, ni entrée de sidebar, ni route API. C'est ce qui permet d'activer un module par environnement.
Ses autres variables sont déclarées dans son manifeste et documentées dans Modules. Une variable requise absente produit un avertissement au boot, sans faire tomber le serveur.
Règle de maintenance
Toute variable ajoutée, renommée ou supprimée dans le code doit être reflétée dans le catalogue src/core/doctor/env.js et dans la référence. Le build échoue tant que ce n'est pas fait.
.env.example est un fichier différent : le modèle de démarrage copié dans un nouveau projet, volontairement réduit à ce qu'il faut remplir pour que le site tourne. Une variable peut donc exister au catalogue sans figurer au modèle, et c'est le cas de tout ce qui a une valeur par défaut satisfaisante. La référence reste l'endroit où les trouver toutes.
Rappel
Les variables LRVO_* sont serveur uniquement. Seules les NEXT_PUBLIC_* existent dans le bundle navigateur. Un composant client qui lit une variable LRVO_* reçoit undefined sans erreur, et un flag booléen se comporte alors comme désactivé en silence.
Étape suivante
Base de données initialise le schéma et montre les premières requêtes.