# Modifier le fichier d'environnement .env de votre site
> Modifiez le .env d'un site dans Vimonto Deploy : chiffré, écrit dans shared/.env, fusionné avec .env.example au premier déploiement, avec un historique.
L'**environnement** d'un site est son fichier `.env` : les réglages et secrets que votre application lit à l'exécution, comme la clé de l'application, le mot de passe de la base de données et les clés d'API. Dans Vimonto Deploy, vous le modifiez sur la page **Environnement** du site. Il est stocké chiffré et écrit sur le serveur sous la forme d'un seul fichier partagé par toutes les releases.
Comme le `.env` se trouve en dehors des releases, il reste le même d'un déploiement à l'autre, et vous ne mettez jamais de secrets dans votre dépôt. Chaque version enregistrée est conservée : vous pouvez voir ce qui a changé et restaurer une version précédente.
## Où le .env est-il stocké ?
Sur le serveur, le `.env` se trouve dans `shared/.env` dans le répertoire du site, par exemple `/home/vimonto/shop.example.com/shared/.env`. Il appartient à l'utilisateur du site, et seul cet utilisateur (et son groupe) peut le lire.
À chaque déploiement, la release reçoit un lien vers ce fichier : `releases/{release}/.env` pointe vers `shared/.env`. Pour un [monorepo](https://ops.vimonto.com/docs/fr/sites/create-a-site#déployer-un-monorepo), le lien est placé dans le répertoire racine de l'application au sein de la release. Toutes les releases lisent donc le même fichier, et un [rollback](https://ops.vimonto.com/docs/fr/sites/deployments#revenir-à-une-release-antérieure) ne modifie pas vos réglages.
Dans Vimonto Deploy, le contenu est stocké chiffré dans la base de données. Ce que vous enregistrez sur la page Environnement est ce qui est écrit sur le serveur.
## Afficher et modifier le .env
1. Ouvrez le site et allez dans **Environnement**.
2. Les clés sont visibles, mais les valeurs sont masquées et floutées. Cliquez sur **Afficher** pour charger le vrai contenu dans l'éditeur.
3. Faites vos modifications et cliquez sur **Enregistrer et écrire**, ou appuyez sur ⌘ S (Ctrl S).
L'enregistrement écrit immédiatement le fichier sur le serveur, sous forme de tâche en arrière-plan que vous pouvez suivre dans l'en-tête du site. L'enregistrement n'est possible qu'après **Afficher** : vous n'écrasez donc jamais un fichier que vous n'avez pas vu.
> [!NOTE]
> Le `.env` contient des mots de passe et des clés : seules les personnes qui peuvent gérer les sites le voient. Les autres membres de l'organisation voient **Uniquement pour les personnes autorisées à modifier le site**. Consultez [membres et rôles](https://ops.vimonto.com/docs/fr/organization/members-and-roles). Chaque **Afficher** est enregistré dans le [journal d'audit](https://ops.vimonto.com/docs/fr/organization/audit-log).
### Rafraîchir le cache de configuration et redémarrer les workers à l'enregistrement
Certains éléments ne lisent le `.env` qu'à leur démarrage, ou depuis un cache. Pour un site Laravel, et pour tout site avec des processus ou des [fonctionnalités de site](https://ops.vimonto.com/docs/fr/sites/site-features), **Enregistrer et écrire** ouvre d'abord **Enregistrer le .env** avec deux options :
| Option | Effet |
|---|---|
| **Rafraîchir le cache de configuration** | Sites Laravel uniquement. Exécute `php artisan config:cache` dans la release en ligne, pour qu'une configuration en cache ne conserve pas les anciennes valeurs. |
| **Redémarrer les workers** | Les queue workers Laravel terminent leur job et redémarrent (`queue:restart`) ; Horizon, Reverb et les autres processus du site redémarrent aussi, pour lire les nouvelles valeurs. |
Les deux sont activées la première fois. Vimonto Deploy retient vos choix pour ce site, pour vous, et les utilise comme valeurs par défaut la fois suivante. Cliquez sur **Enregistrer et écrire** dans la fenêtre pour enregistrer. Les autres sites s'enregistrent directement, sans cette fenêtre.
## Voir et restaurer les versions précédentes
Chaque `.env` enregistré devient une version, quelle que soit la personne ou la chose qui l'a modifié : vous sur cette page, la création du site, le premier déploiement qui l'a construit sur `.env.example`, une [fonctionnalité de site](https://ops.vimonto.com/docs/fr/sites/site-features) qui a défini ses clés, ou une restauration. Cliquez sur **Historique** pour les voir, de la plus récente à la plus ancienne. Les 50 versions les plus récentes de chaque site sont conservées.
Chaque version indique son origine (**Site créé**, **Construit sur .env.example**, **Copié d'un autre site**, **Modifié** ou **Restauré**), qui l'a enregistrée (**Système** pour les modifications faites par Vimonto Deploy lui-même) et quand, ainsi que les clés modifiées : `+` ajoutée, `−` supprimée et `~` modifiée. Les valeurs ne sont affichées qu'après avoir cliqué sur **Afficher** ; avant cela, vous ne voyez que les clés.
Pour revenir à une version précédente, cliquez sur **Restaurer** à côté de celle-ci et confirmez. Son contenu remplace le `.env` actuel et est écrit sur le serveur. La version que vous remplacez reste dans l'historique : une restauration peut donc être annulée de la même façon. Une restauration ne rafraîchit pas le cache de configuration et ne redémarre pas les workers ; redéployez, ou enregistrez encore une fois avec ces options, si votre application en a besoin.
## Que contient le .env d'un nouveau site ?
Pour les sites Laravel et Statamic, Vimonto Deploy écrit un `.env` de production à la création du site :
| Clé | Valeur |
|---|---|
| `APP_NAME` | La première partie du domaine. |
| `APP_ENV`, `APP_DEBUG` | `production` et `false`. |
| `APP_KEY` | Une clé nouvellement générée. |
| `APP_URL` | `http://` et le domaine du site. |
| `APP_LOCALE`, `APP_FALLBACK_LOCALE` | `en`. |
| `LOG_CHANNEL`, `LOG_LEVEL` | `daily` et `error`. |
| `DB_CONNECTION`, `DB_HOST`, `DB_PORT`, `DB_DATABASE`, `DB_USERNAME`, `DB_PASSWORD` | La base de données connectée à la création du site, le cas échéant. |
| `SESSION_DRIVER`, `CACHE_STORE`, `QUEUE_CONNECTION` | `redis` sur un serveur d'application (qui dispose de Redis), sinon `database`. |
| `REDIS_HOST`, `REDIS_PORT` | `127.0.0.1` et `6379`. |
| `MAIL_MAILER` | `log`, jusqu'à ce que vous configuriez un service d'e-mail. |
Quand la base de données utilise l'utilisateur de base de données propre au serveur et que Vimonto Deploy ne connaît plus son mot de passe, `DB_PASSWORD` est laissé vide, avec un commentaire qui vous demande de le renseigner.
Les autres sites démarrent sans `.env`. Vous pouvez en écrire un sur la page Environnement dès que votre application en a besoin. Un site sur un load balancer n'a pas de page Environnement : définissez le `.env` du site sur chaque serveur d'application placé derrière.
### Fusion avec .env.example au premier déploiement
Si votre dépôt contient un `.env.example`, le premier déploiement reconstruit le `.env` à partir de celui-ci. Le résultat suit les clés, l'ordre et les commentaires de l'exemple, avec les valeurs générées par Vimonto Deploy renseignées (y compris là où l'exemple a la clé en commentaire, comme Laravel le fait pour `DB_HOST`). Les clés générées absentes de l'exemple sont ajoutées à la fin.
Ainsi, les clés propres à votre application, comme `VITE_*` ou `AWS_*`, sont déjà en place et n'attendent que vos valeurs. Jusqu'au premier déploiement, la page Environnement affiche **Complété au premier déploiement**. La fusion n'a lieu qu'une fois, avant l'exécution du script de déploiement, et apparaît dans l'historique sous **Construit sur .env.example** ; ensuite, le `.env` est exactement ce que vous en faites.
## Faut-il vider le cache de configuration après avoir modifié le .env ?
Les applications Laravel qui mettent leur configuration en cache (`php artisan optimize` ou `config:cache`, comme le fait le script de déploiement par défaut) ne relisent pas le `.env` d'elles-mêmes. Laissez **Rafraîchir le cache de configuration** activé lors de l'enregistrement, et Vimonto Deploy exécute `php artisan config:cache` pour vous. Sinon, redéployez, pour que le script de déploiement mette en cache les nouvelles valeurs.
> [!TIP]
> Les valeurs utilisées par votre build frontend, comme `VITE_APP_NAME`, sont figées au moment du build. Redéployez après les avoir modifiées.
## Quelles fonctionnalités modifient le .env ?
Certaines [fonctionnalités de site](https://ops.vimonto.com/docs/fr/sites/site-features) ont besoin de réglages dans le `.env`, par exemple Horizon (`QUEUE_CONNECTION=redis`), Reverb (`BROADCAST_CONNECTION` et les clés `REVERB_*`) et Nightwatch (`NIGHTWATCH_TOKEN`). Leur fenêtre affiche exactement les clés qu'elles définissent avant que vous ne les activiez.
Quand une fonctionnalité est activée, les clés qui existent déjà reçoivent leur nouvelle valeur sur place, et les clés manquantes sont ajoutées à la fin sous un commentaire portant le nom de la fonctionnalité. Tout le reste du fichier reste inchangé, et la modification est conservée dans l'historique. Pour les sites Laravel avec une configuration en cache, le cache est reconstruit ensuite. Désactiver une fonctionnalité laisse ses clés dans le `.env`.
## Questions fréquentes
### Le .env est-il inclus dans mon dépôt ?
Non, et il ne doit pas l'être. Le `.env` est conservé par Vimonto Deploy et écrit dans `shared/.env` sur le serveur. Gardez plutôt dans votre dépôt un `.env.example` sans secrets.
### L'enregistrement du .env redémarre-t-il mon application ?
Seulement ce que vous choisissez dans la fenêtre d'enregistrement. PHP lit le fichier à la requête suivante, sauf si la configuration est en cache : **Rafraîchir le cache de configuration** s'en charge. Les queue workers et les autres processus conservent les valeurs avec lesquelles ils ont démarré jusqu'à leur redémarrage : **Redémarrer les workers** le fait immédiatement, et chaque déploiement aussi.
### J'ai enregistré une erreur. Comment l'annuler ?
Ouvrez **Historique**, trouvez la version d'avant votre modification et cliquez sur **Restaurer**.
### Que devient le .env quand je supprime le site ?
Il est supprimé du serveur avec le répertoire du site, les releases, les workers et les certificats. Copiez-le d'abord si vous en avez encore besoin.