Configuration

Tout se règle dans un seul fichier, .env, copié depuis le .env.example que le dépôt livre. Docker Compose place cette copie à son rang dans la séquence ; cette page est ce qui va dans le fichier.

Les trois secrets

Trois valeurs sont livrées vides et doivent être posées avant le premier démarrage. La pile refuse de monter tant que l’une d’elles est vide, nommant en une seule passe chaque variable vide et la commande qui la remplit.

Elles sont livrées vides plutôt que pré-générées à dessein. Un fichier d’exemple qui porterait de vraies clés est un jeu de clés public et identique sur chaque installation, et quiconque oublie de les remplacer tourne avec celles-là.

openssl rand -hex 24        # à coller après POSTGRES_PASSWORD=
openssl rand -hex 32        # à coller après JWT_ACCESS_SECRET=
openssl rand -base64 32     # à coller après SECRET_ENCRYPTION_KEY=

Variable	À quoi elle sert	Contrainte
POSTGRES_PASSWORD	le mot de passe de la base de données	lettres et chiffres seulement
JWT_ACCESS_SECRET	signe le jeton de session	au moins 16 caractères
SECRET_ENCRYPTION_KEY	chiffre votre secret 2FA et les clés API de fournisseurs enregistrées	doit se décoder en exactement 32 octets

SECRET_ENCRYPTION_KEY se génère une fois et jamais plus

C’est la clé AES-256-GCM avec laquelle sont chiffrées les colonnes de la base qui portent votre secret 2FA et vos clés API de fournisseurs, et l’application n’en garde aucune seconde copie. La changer ne rechiffre pas ces colonnes, elle les laisse scellées sous une clé qui n’existe plus. Sauvegardez la valeur là où vous gardez la sauvegarde de la base : Restaurer sous une autre clé dit ce qu’une restauration rend sans elle.

Un export JSON scellé par une phrase de passe n’est délibérément pas lié à cette clé : le fichier porte ses propres paramètres de dérivation, si bien qu’il survit à une clé que vous n’avez plus.

Deux choses sur le mot de passe de la base de données. Il est interpolé tel quel dans l’URL de connexion, si bien qu’un /, un ? ou un # dedans rend cette URL impossible à analyser et l’application ne démarre jamais. Et il est lu une fois et une seule, à la création du répertoire de la base : le changer plus tard ferme à l’application la porte de sa propre base au lieu de changer quoi que ce soit.

Le reste du fichier

Variable	Défaut	Ce qu’elle décide
WEB_PORT	8080	le port sur lequel toute l’application est atteinte
BIND_ADDRESS	0.0.0.0	sur quelles interfaces de l’hôte ce port est publié ; 127.0.0.1 le garde sur la machine
PUBLIC_URL	http://localhost:8080	l’adresse à partir de laquelle sont construits les liens de réinitialisation, et l’origine du cookie
COOKIE_SECURE	false	marque le cookie de session comme réservé à HTTPS ; à poser derrière un proxy qui termine TLS
TRUSTED_PROXY_HOPS	0	combien de vos reverse proxies se tiennent devant (voir Derrière un proxy)
REGISTRATION_ENABLED	true	si l’inscription publique est ouverte, en recours seulement
DEMO_SEED_ENABLED	false	installe au démarrage le compte de démonstration en lecture seule
ACCESS_TOKEN_TTL	15m	combien de temps vit un jeton de session avant d’être rafraîchi
REFRESH_TOKEN_TTL_DAYS	7	combien de temps une session survit sans être utilisée
COINGECKO_DEMO_KEY, OPENFIGI_API_KEY	vide	clés d’intégration gratuites facultatives ; les deux sources fonctionnent sans

Les deux dernières appartiennent à l’exploitant et se posent ici seulement : l’écran des réglages n’a de champ ni pour l’une ni pour l’autre. REGISTRATION_ENABLED et DEMO_SEED_ENABLED sont des recours : les interrupteurs équivalents dans Réglages → Administration sont enregistrés dans la base et l’emportent sur ces valeurs dès que l’un ou l’autre est utilisé une première fois.