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:
/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 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 bewaart het als Gebouwd op .env.example. Dit gebeurt maar één keer. Zie omgeving.
Bij elke keer ophalen worden ook de pakketten in je composer.json en package.json gelezen, zodat het menu sitefuncties 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. Wil je de deployresultaten van een site ook naar je eigen endpoint of extra e-mailadressen sturen, stel dan haar 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 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:
$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.
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:
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 of de 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:
- Zoek de deploy in de lijst Deploys en klik op Terugzetten, of open hem en klik op Terugzetten naar deze release.
- Bevestig.
currentwijst 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.
Ter plekke deployen zonder zero downtime
Staat Zero-downtime deploys uit (gekozen bij het aanmaken van de site of onder site-instellingen), 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. Elke deploy en rollback wordt ook vastgelegd in het auditlog.
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.
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.