# Het .env-bestand van je site bewerken
> Bewerk de .env van je site in Vimonto Deploy: versleuteld bewaard, naar shared/.env geschreven, aangevuld vanuit .env.example, met een verloop om te herstellen.
De **omgeving** van een site is zijn `.env`-bestand: de instellingen en geheimen die je app tijdens het draaien leest, zoals de app-sleutel, het databasewachtwoord en API-sleutels. In Vimonto Deploy bewerk je hem op de pagina **Omgeving** van de site. Hij wordt versleuteld opgeslagen en naar de server geschreven als één bestand dat alle releases delen.
Omdat de `.env` buiten de releases staat, blijft hij van deploy tot deploy hetzelfde, en zet je nooit geheimen in je repository. Elke opgeslagen versie wordt bewaard, zodat je kunt zien wat er veranderde en een eerdere versie kunt herstellen.
## Waar staat de .env?
Op de server staat de `.env` op `shared/.env` in de map van de site, bijvoorbeeld `/home/vimonto/shop.example.com/shared/.env`. Hij is van de gebruiker van de site, en alleen die gebruiker (en zijn groep) kan hem lezen.
Bij elke deploy krijgt de release er een link naar: `releases/{release}/.env` wijst naar `shared/.env`. Bij een [monorepo](https://ops.vimonto.com/docs/nl/sites/create-a-site#een-monorepo-deployen) komt de link in de hoofdmap van de app binnen de release. Elke release leest dus hetzelfde bestand, en een [rollback](https://ops.vimonto.com/docs/nl/sites/deployments#terugzetten-naar-een-eerdere-release) verandert je instellingen niet.
In Vimonto Deploy wordt de inhoud versleuteld in de database opgeslagen. Wat je op de pagina Omgeving opslaat, wordt naar de server geschreven.
## De .env bekijken en bewerken
1. Open de site en ga naar **Omgeving**.
2. De sleutels zijn zichtbaar, maar de waarden zijn gemaskeerd en vervaagd. Klik op **Tonen** om de echte inhoud in de editor te laden.
3. Maak je wijzigingen en klik op **Opslaan en schrijven**, of druk op ⌘ S (Ctrl S).
Opslaan schrijft het bestand meteen naar de server, als achtergrondtaak die je in de siteheader volgt. Opslaan kan pas na **Tonen**, zodat je nooit een bestand overschrijft dat je niet hebt gezien.
> [!NOTE]
> De `.env` bevat wachtwoorden en sleutels, dus alleen wie sites mag beheren ziet hem. Andere leden van de organisatie zien **Alleen voor wie de site mag wijzigen**. Zie [leden en rollen](https://ops.vimonto.com/docs/nl/organization/members-and-roles). Elke keer **Tonen** wordt vastgelegd in het [auditlog](https://ops.vimonto.com/docs/nl/organization/audit-log).
### De config-cache vernieuwen en workers herstarten bij opslaan
Sommige dingen lezen de `.env` alleen bij het starten, of uit een cache. Bij een Laravel-site, en bij elke site met processen of [sitefuncties](https://ops.vimonto.com/docs/nl/sites/site-features), opent **Opslaan en schrijven** eerst **.env opslaan** met twee keuzes:
| Optie | Wat het doet |
|---|---|
| **Config-cache vernieuwen** | Alleen Laravel-sites. Voert `php artisan config:cache` uit in de live release, zodat een gecachete configuratie niet de oude waarden houdt. |
| **Workers herstarten** | Laravel queue workers maken hun job af en herstarten (`queue:restart`); Horizon, Reverb en de andere processen van de site herstarten ook, zodat ze de nieuwe waarden lezen. |
De eerste keer staan beide aan. Vimonto Deploy onthoudt je keuzes voor deze site, voor jou, en gebruikt ze de volgende keer als standaard. Klik in het venster op **Opslaan en schrijven** om op te slaan. Andere sites slaan meteen op, zonder het venster.
## Eerdere versies bekijken en herstellen
Elke `.env` die wordt opgeslagen, wordt een versie, wie of wat hem ook wijzigde: jij op deze pagina, het aanmaken van de site, de eerste deploy die hem op `.env.example` bouwde, een [sitefunctie](https://ops.vimonto.com/docs/nl/sites/site-features) die sleutels instelde, of een herstel. Klik op **Verloop** om ze te zien, de nieuwste bovenaan. Per site worden de nieuwste 50 versies bewaard.
Elke versie toont waar hij vandaan komt (**Site aangemaakt**, **Gebouwd op .env.example**, **Gekopieerd van een andere site**, **Bewerkt** of **Teruggezet**), wie hem opsloeg (**Systeem** voor wijzigingen door Vimonto Deploy zelf) en wanneer, en welke sleutels veranderden: `+` toegevoegd, `−` verwijderd en `~` gewijzigd. De waarden zie je pas nadat je op **Tonen** hebt geklikt; daarvoor zie je alleen de sleutels.
Wil je terug naar een eerdere versie, klik dan ernaast op **Herstellen** en bevestig. De inhoud ervan vervangt de huidige `.env` en wordt naar de server geschreven. De versie die je vervangt blijft in het verloop staan, dus een herstel maak je op dezelfde manier ongedaan. Een herstel vernieuwt de config-cache niet en herstart geen workers; deploy opnieuw, of sla nog een keer op met die opties, als je app dat nodig heeft.
## Wat staat er in de .env van een nieuwe site?
Voor Laravel- en Statamic-sites schrijft Vimonto Deploy bij het aanmaken van de site een productie-`.env`:
| Sleutel | Waarde |
|---|---|
| `APP_NAME` | Het eerste deel van het domein. |
| `APP_ENV`, `APP_DEBUG` | `production` en `false`. |
| `APP_KEY` | Een nieuw gegenereerde sleutel. |
| `APP_URL` | `http://` en het domein van de site. |
| `APP_LOCALE`, `APP_FALLBACK_LOCALE` | `en`. |
| `LOG_CHANNEL`, `LOG_LEVEL` | `daily` en `error`. |
| `DB_CONNECTION`, `DB_HOST`, `DB_PORT`, `DB_DATABASE`, `DB_USERNAME`, `DB_PASSWORD` | De database die bij het aanmaken van de site is gekoppeld, als die er is. |
| `SESSION_DRIVER`, `CACHE_STORE`, `QUEUE_CONNECTION` | `redis` op een app-server (die Redis heeft), anders `database`. |
| `REDIS_HOST`, `REDIS_PORT` | `127.0.0.1` en `6379`. |
| `MAIL_MAILER` | `log`, tot je een maildienst instelt. |
Gebruikt de database de eigen databasegebruiker van de server en kent Vimonto Deploy het wachtwoord daarvan niet meer, dan blijft `DB_PASSWORD` leeg, met een opmerking die vraagt het in te vullen.
Andere sites beginnen zonder `.env`. Je kunt er op de pagina Omgeving een schrijven zodra je app hem nodig heeft. Een site op een load balancer heeft geen pagina Omgeving: stel de `.env` van de site in op elke app-server erachter.
### Samenvoegen met .env.example bij de eerste deploy
Heeft je repository een `.env.example`, dan bouwt de eerste deploy de `.env` daarop opnieuw op. Het resultaat volgt de sleutels, volgorde en opmerkingen van het voorbeeld, met de waarden die Vimonto Deploy genereerde ingevuld (ook waar het voorbeeld de sleutel heeft uitgecommentarieerd, zoals Laravel doet voor `DB_HOST`). Gegenereerde sleutels die in het voorbeeld ontbreken, komen aan het eind.
Zo staan de eigen sleutels van je app, zoals `VITE_*` of `AWS_*`, al klaar om in te vullen. Tot de eerste deploy staat op de pagina Omgeving **Aangevuld bij de eerste deploy**. Het samenvoegen gebeurt maar één keer, voordat het deployscript draait, en staat in het verloop als **Gebouwd op .env.example**; daarna is de `.env` precies wat jij ervan maakt.
## Moet ik de config-cache legen na een wijziging in de .env?
Laravel-apps die hun configuratie cachen (`php artisan optimize` of `config:cache`, zoals het standaard deployscript doet) lezen de `.env` niet vanzelf opnieuw. Laat **Config-cache vernieuwen** aan staan als je opslaat, dan voert Vimonto Deploy `php artisan config:cache` voor je uit. Anders deploy je opnieuw, zodat het deployscript de nieuwe waarden cachet.
> [!TIP]
> Waarden die je frontend-build gebruikt, zoals `VITE_APP_NAME`, worden ingebakken als de build draait. Deploy opnieuw nadat je ze hebt gewijzigd.
## Welke functies wijzigen de .env?
Sommige [sitefuncties](https://ops.vimonto.com/docs/nl/sites/site-features) hebben instellingen in de `.env` nodig, bijvoorbeeld Horizon (`QUEUE_CONNECTION=redis`), Reverb (`BROADCAST_CONNECTION` en de `REVERB_*`-sleutels) en Nightwatch (`NIGHTWATCH_TOKEN`). Hun venster toont precies welke sleutels ze instellen voordat je ze aanzet.
Als je een functie aanzet, krijgen sleutels die al bestaan hun nieuwe waarde op dezelfde plek, en ontbrekende sleutels komen aan het eind onder een opmerking met de naam van de functie. Al het andere in het bestand blijft zoals het was, en de wijziging wordt in het verloop bewaard. Bij Laravel-sites met een gecachete configuratie wordt de cache daarna opnieuw opgebouwd. Zet je een functie uit, dan blijven zijn sleutels in de `.env` staan.
## Veelgestelde vragen
### Staat de .env in mijn repository?
Nee, en dat hoort ook niet. De `.env` wordt bewaard door Vimonto Deploy en naar `shared/.env` op de server geschreven. Zet in plaats daarvan een `.env.example` zonder geheimen in je repository.
### Herstart mijn app als ik de .env opsla?
Alleen wat je in het opslaanvenster kiest. PHP leest het bestand bij het volgende verzoek, tenzij de configuratie gecachet is: daar zorgt **Config-cache vernieuwen** voor. Queue workers en andere processen houden de waarden waarmee ze zijn gestart tot ze herstarten: **Workers herstarten** doet dat meteen, en elke deploy doet het ook.
### Ik heb een fout opgeslagen. Hoe maak ik dat ongedaan?
Open **Verloop**, zoek de versie van vóór je wijziging en klik op **Herstellen**.
### Wat gebeurt er met de .env als ik de site verwijder?
Hij wordt van de server verwijderd, samen met de map, releases, workers en certificaten van de site. Kopieer hem eerst als je hem nog nodig hebt.