# Zero-downtime deployments, push to deploy en rollbacks
> Zo deployt Vimonto Deploy je site zonder downtime: releases, het deployscript en zijn variabelen, push to deploy, deploy-URL's en terugzetten.
Een **deployment** zet een nieuwe versie van je code live op je server. Vimonto Deploy kloont je branch in een nieuwe releasemap, voert daar je deployscript uit en schakelt de site pas daarna in één atomische stap om. Tot dat moment krijgen bezoekers de vorige versie, dus een mislukte build haalt je site nooit offline.
Je kunt deployen met een knop, bij elke push naar je branch, of vanuit CI met een deploy-URL. De laatste paar releases blijven op de server staan, dus teruggaan naar een eerdere versie kost seconden.
## Hoe werkt een zero-downtime deployment?
Elke site staat op schijf ingericht voor zero-downtime deploys:
```text
/home/{user}/{directory}/
├── releases/
│ ├── 20261007141502/ één map per deploy
│ └── 20261007153044/
├── shared/
│ ├── .env blijft tussen releases bewaard
│ └── storage/ alleen Laravel
└── current -> releases/20261007153044
```
Nginx serveert de site vanuit `current`. Een deploy doorloopt deze stappen, die je live kunt volgen:
| Stap | Wat er gebeurt |
|---|---|
| **Code ophalen** | De branch wordt gekloond in een nieuwe release die naar datum en tijd is genoemd (een shallow clone van de nieuwste commit). De commithash, auteur en het bericht worden vastgelegd. |
| **Deployscript uitvoeren** | De gedeelde `.env` wordt in de release gekoppeld (en bij Laravel ook `storage/`). Daarna draait je deployscript in de release, als de gebruiker van de site. |
| **Live zetten** | `current` wordt in één atomische rename naar de nieuwe release gezet. PHP-FPM wordt herladen, zodat OPcache de nieuwe bestanden oppakt. |
| **Oude releases opruimen** | Oude releases worden verwijderd; de nieuwste vijf blijven bewaard. |
Na het live zetten herstart Vimonto Deploy ook wat je code draait: Laravel queue workers krijgen `artisan queue:restart`, Node.js-processen worden herstart, en elke ingeschakelde [sitefunctie](https://ops.vimonto.com/docs/nl/sites/site-features) voert een eigen commando uit (bijvoorbeeld `horizon:terminate` voor Horizon).
Heeft je repository een `.env.example`, dan wordt bij de eerste deploy van een site de `.env` daarop opnieuw opgebouwd voordat het deployscript draait: met de sleutels, volgorde en opmerkingen van het voorbeeld, en de waarden die Vimonto Deploy genereerde ingevuld. Het deploylogboek meldt dit, en de [geschiedenis van de .env](https://ops.vimonto.com/docs/nl/sites/environment#eerdere-versies-bekijken-en-herstellen) bewaart het als **Gebouwd op .env.example**. Dit gebeurt maar één keer. Zie [omgeving](https://ops.vimonto.com/docs/nl/sites/environment).
Bij elke keer ophalen worden ook de pakketten in je `composer.json` en `package.json` gelezen, zodat het menu [sitefuncties](https://ops.vimonto.com/docs/nl/sites/site-features) de tools kan markeren die je app gebruikt.
### Wat gebeurt er als een deploy mislukt?
Mislukt het ophalen of het deployscript, dan wordt de nieuwe release weggegooid en blijft `current` ongemoeid. De deploypagina meldt **Deploy mislukt** met de fout en **De live versie is niet veranderd.** Open **Details en logboek** om de uitvoer van elke stap te zien, los het probleem op en klik op **Opnieuw deployen**.
## Nu deployen
Klik op **Deployen** in de siteheader, bovenaan elke sitepagina. Je gaat naar de eigen pagina van de deploy, met de fasen, de stap die bezig is en de voortgang. Je hoeft het venster niet open te houden: de deploy draait op de server, je krijgt een bericht in de app als hij klaar is, en een afgeronde of mislukte deploy stuurt ook een [melding](https://ops.vimonto.com/docs/nl/more/notifications). Wil je de deployresultaten van een site ook naar je eigen endpoint of extra e-mailadressen sturen, stel dan haar [deploymeldingen](https://ops.vimonto.com/docs/nl/sites/site-settings#deploymeldingen) in.
Per site draait er maar één deploy tegelijk. Start je er een terwijl er een bezig is, dan zie je **Er loopt al een deploy voor** met het domein van de site.
## De repository koppelen of wijzigen
Het paneel **Repository** toont de repository, de branch en de status van de **Deploy-sleutel**. Klik op **Repository koppelen** of **Wijzigen** om een repository te kiezen van een [gekoppelde Git-host](https://ops.vimonto.com/docs/nl/connections/source-control) of een **Eigen Git-URL** te gebruiken.
- **Gekoppelde Git-host**: de deploy-sleutel van de site wordt op de repository geregistreerd als alleen-lezen deploy-sleutel, en van de oude repository verwijderd als je wisselt. Bij een nieuw gekoppelde repository staat **Deployen bij elke push** meteen aan.
- **Eigen Git-URL**: gebruik een SSH-URL (`git@…`) voor een privé repository en voeg de sleutel onder **Deploy-sleutel van deze site** toe als deploy-sleutel bij je Git-host. Gebruik een HTTPS-URL voor een openbare repository. **Deployen bij elke push** staat uit, omdat alleen een gekoppelde Git-host een webhook van Vimonto Deploy kan krijgen.
## Het deployscript bewerken
Het paneel **Deployscript** bevat het Bash-script dat een release bouwt, in een code-editor met shell-markering. Het begint met een script dat bij je framework past. Je kunt het vrij bewerken en opslaan met **Opslaan** (of ⌘ S, Ctrl S). De volgende deployment gebruikt het. **Standaard** zet het gegenereerde script terug in de editor; het wordt pas bewaard als je op **Opslaan** klikt.
Het standaardscript voor een Laravel-site ziet er zo uit:
```bash
$VIMONTO_COMPOSER install --no-dev --no-interaction --prefer-dist --optimize-autoloader
if [ -f package.json ]; then
if [ -f package-lock.json ]; then npm ci; else npm install; fi
npm run build
fi
$VIMONTO_PHP artisan storage:link --force
$VIMONTO_PHP artisan migrate --force
$VIMONTO_PHP artisan optimize
```
Symfony-sites legen de cache en voeren Doctrine-migraties uit als er een map `migrations` is. Statamic-sites warmen ook de Stache op. Statische en Node.js-sites installeren pakketten en voeren het buildcommando uit.
Het script draait als de gebruiker van de site, in de map van de app binnen de nieuwe release (de hoofdmap, bij een monorepo), met `set -e`: het eerste commando dat mislukt stopt de deploy.
### Welke variabelen kan het deployscript gebruiken?
| Variabele | Waarde |
|---|---|
| `$VIMONTO_PHP` | De PHP-binary van de PHP-versie van de site, zoals `php8.4`. |
| `$VIMONTO_COMPOSER` | Composer, uitgevoerd met de PHP-versie van de site. |
| `$VIMONTO_RELEASE_PATH` | De map van de app in de nieuwe release. |
| `$VIMONTO_SITE_PATH` | De map van de site, zoals `/home/vimonto/shop.example.com`. |
| `$VIMONTO_BRANCH` | De branch die gedeployd wordt. |
| `$VIMONTO_COMMIT` | De volledige hash van de commit die gedeployd wordt. |
Gebruik `$VIMONTO_PHP` en `$VIMONTO_COMPOSER` in plaats van `php` en `composer`, zodat het script de PHP-versie van de site volgt als je die wijzigt.
> [!TIP]
> Gegevens uit **Composer-authenticatie** en **npm-authenticatie** (ingesteld bij het aanmaken van de site) zijn alleen tijdens de build beschikbaar, via `COMPOSER_AUTH` en een tijdelijke npm-configuratie. Later beheer je ze in de **Instellingen** van de site, op de tabbladen **Composer** en **npm**: zie [gegevens voor Composer en npm](https://ops.vimonto.com/docs/nl/sites/site-settings#gegevens-voor-composer-en-npm).
## Push to deploy
Bij een repository van een gekoppelde Git-host heeft het paneel **Quick deploy** de optie **Deployen bij elke push**. Die staat vanzelf aan als je de repository koppelt, bij het aanmaken of later: Vimonto Deploy voegt een webhook toe aan de repository bij GitHub, GitLab of Bitbucket. Elke push naar de branch van de site start dan een deploy; pushes naar andere branches worden genegeerd. Zet je het uit, dan wordt de webhook weer verwijderd.
Bij een repository met een eigen Git-URL zegt het paneel dat je in plaats daarvan de deploy-URL aanroept vanuit je Git-host of CI.
## Deployen vanuit CI met de deploy-URL
Het paneel **Deploy-URL** toont een geheime URL voor de site, aan wie sites mag beheren. Een `POST`-verzoek daarnaartoe deployt de branch van de site:
```bash
curl -X POST https://…/deploy/your-secret-token
```
Gebruik hem als laatste stap van een pipeline in GitHub Actions, GitLab CI of een andere tool, zodat een deploy pas start als je tests slagen. De antwoorden zijn gewone JSON:
| Status | Bericht | Betekenis |
|---|---|---|
| `202` | `Deploy started.` | De deploy staat in de wachtrij; het antwoord bevat het id ervan. |
| `409` | `A deploy is already running.` | Probeer het opnieuw als de lopende deploy klaar is. |
| `422` | De reden | De site is niet klaar of heeft geen repository. |
| `404` | | Het token klopt niet. |
De URL accepteert 60 verzoeken per minuut. Iedereen met de URL kan een deploy starten, dus houd hem geheim. Klik op **Vernieuwen** om een nieuwe te maken; de oude URL werkt dan meteen niet meer, en de webhook bij je Git-host wordt voor je bijgewerkt.
## Een deploy volgen en de uitvoer lezen
De lijst **Deploys** toont elke deploy, de nieuwste bovenaan, 15 per pagina: de status, de commit, hoe hij gestart is (**Handmatig**, **Push**, **Deploy-URL**, **Terugzetten** of **API**, voor deploys die zijn gestart via de [REST API](https://ops.vimonto.com/docs/nl/more/api) of de [CLI](https://ops.vimonto.com/docs/nl/more/cli)), wie hem startte, de auteur van de commit, de branch en hoe lang hij duurde. De live release heeft een label **Live**. Het overzicht van de site toont ook de meest recente deploys.
Klik op **Bekijken** om een deploy te openen. De pagina toont de fasen **Ophalen**, **Bouwen** en **Live**, de voortgang tijdens het draaien, en onder **Details en logboek** de uitvoer van elke stap. Het paneel **Commit** toont het bericht, de commit, de auteur, de branch, de release en wanneer hij gestart is. Met **Vorige** en **Volgende** ga je naar andere deploys.
## Terugzetten naar een eerdere release
Omdat de nieuwste vijf releases op de server blijven, kun je een eerdere weer live zetten zonder iets te bouwen:
1. Zoek de deploy in de lijst **Deploys** en klik op **Terugzetten**, of open hem en klik op **Terugzetten naar deze release**.
2. Bevestig. `current` wijst meteen weer naar die release, PHP-FPM wordt herladen en workers worden herstart.
Een rollback verschijnt in de lijst als **Teruggezet naar …**. Terugzetten werkt alleen met zero-downtime deploys, en alleen voor releases die nog op de server staan.
> [!WARNING]
> Databasemigraties worden niet teruggedraaid. Heeft een release een migratie uitgevoerd die de oudere code niet aankan, draai die migratie dan eerst zelf terug.
## Ter plekke deployen zonder zero downtime
Staat **Zero-downtime deploys** uit (gekozen bij het [aanmaken van de site](https://ops.vimonto.com/docs/nl/sites/create-a-site#zero-downtime-deploys) of onder [site-instellingen](https://ops.vimonto.com/docs/nl/sites/site-settings)), dan werkt elke deploy één release bij, `releases/live`, ter plekke. De code wordt opgehaald en teruggezet naar de branch, terwijl genegeerde bestanden zoals `vendor/` en `node_modules/` blijven staan, dus builds gaan sneller.
De nadelen:
- Bezoekers kunnen de site zien terwijl hij gebouwd wordt.
- Een mislukte build wordt niet weggegooid: de live code is de code die niet gebouwd kon worden.
- Er zijn geen oude releases, dus geen rollback en geen opruimstap.
## Veelgestelde vragen
### Moet ik de deploypagina open houden?
Nee. Deploys draaien op de server als achtergrondtaken. Je kunt de pagina sluiten, en wie de deploy startte krijgt een melding als hij klaar is. Volg alle taken op de pagina [activiteit](https://ops.vimonto.com/docs/nl/organization/activity). Elke deploy en rollback wordt ook vastgelegd in het [auditlog](https://ops.vimonto.com/docs/nl/organization/audit-log).
### Heeft een load-balanced site deploys?
Nee. Een site op een load balancer heeft geen code, en dus geen pagina Deployments. Deploy de site op elke app-server erachter. Zie [load balancing](https://ops.vimonto.com/docs/nl/sites/load-balancing).
### Hoeveel releases worden bewaard?
Vijf: de nieuwste releases, altijd inclusief de live release. Oudere worden na elke geslaagde deploy verwijderd.
### Waarom startte mijn push geen deploy?
Controleer of **Deployen bij elke push** aan staat en of je naar de branch van de site hebt gepusht. Pushes naar andere branches worden genegeerd. Een deploy die al loopt weigert ook een tweede.
### Kan ik migraties alleen bij sommige deploys uitvoeren?
Het deployscript is gewoon Bash, dus je kunt voorwaarden gebruiken. Controleer bijvoorbeeld `$VIMONTO_BRANCH` of een bestand in de release voordat je `$VIMONTO_PHP artisan migrate --force` uitvoert.