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 komt de link in de hoofdmap van de app binnen de release. Elke release leest dus hetzelfde bestand, en een rollback 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
- Open de site en ga naar Omgeving.
- De sleutels zijn zichtbaar, maar de waarden zijn gemaskeerd en vervaagd. Klik op Tonen om de echte inhoud in de editor te laden.
- 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.
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, 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 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.
Welke functies wijzigen de .env?
Sommige sitefuncties 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.