Naar de inhoud
Deploy
Blader door de documentatie

Site-instellingen: PHP-versie, webmap en isolatie

Wijzig PHP-versie, webmap of zero-downtime deploys van een site, voeg Composer- en npm-gegevens toe en stel mails bij mislukte deploys en een deploy-hook in.

Bekijk als Markdown Bijgewerkt op 7 oktober 2026

De pagina Instellingen van een site bepaalt hoe de site op haar server draait: de PHP-versie, de map die Nginx serveert, of deploys zero-downtime releases gebruiken en of de site geïsoleerd draait. Ook staan hier de inloggegevens voor privé Composer- en npm-pakketten en waar de deployresultaten van een site heen gaan, en hier kloon of verwijder je een site.

Je vindt de pagina onderaan de zijbalk van de site onder Instellingen. Sommige dingen stel je elders in: het domein onder Domeinen en SSL, de repository en branch onder Deployments, en de map en de monorepo-root eenmalig, als je de site aanmaakt.

De pagina heeft bovenaan tabbladen:

Tabblad Wat erop staat Te zien bij
Algemeen PHP-versie, webmap of poort, zero-downtime deploys, isolatie, Site klonen en Site verwijderen Elke site
Composer Inloggegevens voor privé Composer-pakketten Laravel-, Symfony-, Statamic- en PHP-sites
npm Tokens voor privé npm-registry's Sites met een repository
Meldingen E-mails bij mislukte deploys en een deploy-hook Sites met een repository

WordPress, phpMyAdmin en sites op een load balancer hebben geen repository en geen build, dus die hebben alleen de algemene instellingen en geen tabbladen.

De pagina Instellingen van een Laravel-site met de PHP-versie, de webmap, de schakelaar voor zero-downtime deploys en website-isolatie
De instellingen van een site

Waar de site op de server staat

Elke site heeft een map in de homemap van de gebruiker waaronder ze draait, ingedeeld voor zero-downtime deploys:

/home/vimonto/example.com/
├── current -> releases/20261007143000   # the live release
├── releases/                            # one directory per deploy
└── shared/
    ├── .env                             # kept across releases
    └── storage/                         # Laravel's storage, kept across releases
Instelling Waar je die instelt Kan het later veranderen?
Map (example.com hierboven) Als je de site aanmaakt Nee. Die blijft hetzelfde als het domein verandert.
Rootmap, voor een monorepo Als je de site aanmaakt Nee.
Webmap Instellingen Ja
PHP-versie Instellingen Ja
Poort van een Node.js-app Instellingen Ja
Zero-downtime deploys Instellingen Ja
Website-isolatie Als je de site aanmaakt Nee
Domein en aliassen Domeinen en SSL Ja
Repository en branch Deployments Ja

Het Overzicht van de site toont in één oogopslag het adres, de map, de webroot, HTTPS, de repository, de branch, quick deploy en de recente deploys. Bij een load-balanced site toont het in plaats daarvan de app-servers erachter. Daaronder laat het paneel Uptime zien of de site bereikbaar is, met 90 dagen geschiedenis (zie uptime monitoring). Rechts toont Activiteit het laatste werk aan de site, nieuwste eerst: deploys, certificaten, workers, functies, commando's en andere taken, elk met wie het startte en hoe het afliep. Klik op een regel om de taak met zijn uitvoer te openen; Meer laden toont oudere.

Tot de site helemaal is ingericht, begint het overzicht met Volgende stappen, zoals een repository koppelen of HTTPS aanzetten. Een stap die je niet nodig hebt, blijft anders altijd openstaan: klik op Verbergen om de lijst voor deze site te verbergen. Dat geldt alleen voor jou.

Een site op een load balancer stuurt verzoeken alleen door naar zijn app-servers, dus zijn pagina Instellingen heeft geen PHP-versie, webmap, zero-downtime deploys of isolatie: er staat dat er niets in te stellen valt, met een link naar zijn pagina Load balancing, waar je hem beheert. Site verwijderen staat er zoals bij elke site.

Het overzicht van een site met het adres, de map, de webroot, de repository, de branch en recente deploys
Het overzicht van een site

De PHP-versie wijzigen

Voor PHP- en Laravel-sites toont PHP-versie de versies die op de server zijn geïnstalleerd. Kies er een en klik op Opslaan.

Vimonto Deploy schrijft de Nginx-configuratie van de site opnieuw, zodat PHP-requests naar de PHP-FPM van de nieuwe versie gaan, en verplaatst bij een geïsoleerde site de PHP-FPM-pool naar die versie. Wil je een versie gebruiken die niet in de lijst staat, installeer die dan eerst op de pagina PHP van de server.

Controleer ook of je deployscript geen vaste PHP-binary aanroept, zoals php8.3.

De webmap wijzigen

De Webmap is de map in je project die Nginx serveert: /public voor Laravel, vaak /dist of /build voor een statische site, of / voor de root van het project. Hij is relatief ten opzichte van de release (of van de rootmap van de monorepo, als de site die heeft). Gebruik letters, cijfers, punten, koppeltekens en underscores, bijvoorbeeld /public of /apps/web/public.

Klik op Opslaan en de Nginx-configuratie wordt opnieuw geschreven met de nieuwe root.

De poort van een Node.js-app wijzigen

Bij een Node.js-site vervangt Poort van je app de webmap. Nginx stuurt elk request door naar je app op 127.0.0.1 en deze poort, tussen 1024 en 65535. Sla je een nieuwe poort op, dan verhuist het proces dat je app draait (onder Processen) mee en start het opnieuw. Heb je zelf een startcommando toegevoegd, pas de poort daarin dan zelf aan.

Zero-downtime deploys

Met Zero-downtime deploys aan (de standaard) bouwt elke deploy een nieuwe release in releases/ en zet die pas live als alles is gelukt, door de symlink current in één stap om te zetten. Bezoekers zien nooit een halve build, een mislukte build verandert niets, oude releases worden opgeruimd en je kunt terug naar een eerdere release.

Staat het uit, dan wordt de code ter plekke bijgewerkt: elke deploy werkt dezelfde release bij en bouwt die, releases/live. Dat is sneller en gebruikt minder schijfruimte, maar bezoekers zien de build gebeuren, een mislukte build kan de live site half bijgewerkt achterlaten en er is niets om naar terug te gaan.

Aan Uit
Waar een deploy bouwt Een nieuwe releasemap releases/live, ter plekke
Een mislukte build Weggegooid; de live site blijft ongewijzigd Blijft in de live site
Rollback Ja Nee
Oude releases Na elke deploy opgeruimd Niet van toepassing

De wijziging geldt vanaf de volgende deploy. Zie deployments.

De schakelaar wordt niet getoond voor geïnstalleerde applicaties zoals WordPress en phpMyAdmin.

Website-isolatie

Website-isolatie laat zien of de site als eigen Linux-gebruiker draait. Je kiest dit als je de site aanmaakt; daarna kan het niet meer worden gewijzigd.

Isolatie aan Isolatie uit
Linux-gebruiker Een eigen gebruiker, bijvoorbeeld shop De systeemgebruiker van de server (vimonto), gedeeld met andere sites
Homemap /home/shop, alleen leesbaar voor die gebruiker en zijn groep /home/vimonto
PHP-FPM Een eigen pool, die draait als de gebruiker van de site, op /run/php/site-{id}.sock De gedeelde pool van de PHP-versie
Deploys, workers, geplande jobs Draaien als de gebruiker van de site Draaien als de systeemgebruiker

Isolatie houdt sites op dezelfde server van elkaar gescheiden: een kwetsbare plugin in de ene site kan de bestanden of .env van een andere niet lezen. Nginx kan de bestanden van de site nog steeds lezen, omdat de systeemgebruiker, waaronder Nginx draait, wordt toegevoegd aan de groep van de sitegebruiker.

Gebruik isolatie als een server sites voor verschillende klanten host, of sites die je minder vertrouwt, zoals WordPress.

Gegevens voor Composer en npm

Om tijdens een deploy privépakketten te installeren, zoals Laravel Nova, Private Packagist of pakketten op GitHub Packages, heeft de build inloggegevens nodig. Die beheer je op de tabbladen Composer en npm. Het zijn dezelfde gegevens die je onder Composer-authenticatie en npm-authenticatie kunt invullen als je de site aanmaakt.

Het tabblad Composer van de instellingen van een site met opgeslagen inloggegevens voor repo.packagist.com
Authenticatie voor Composer-packages

Composer-gegevens toevoegen

  1. Open de Instellingen van de site en klik op het tabblad Composer (Authenticatie voor Composer-packages).
  2. Klik op Inloggegevens toevoegen.
  3. Vul de Host in (bijvoorbeeld repo.packagist.com of nova.laravel.com), de Gebruikersnaam en het Wachtwoord. Een token of licentiesleutel vul je ook in bij Wachtwoord.
  4. Klik op Opslaan.

Dit zijn de http-basic-gegevens uit Composers auth.json. Je kunt één set per host toevoegen, en maximaal 10.

npm-gegevens toevoegen

  1. Klik op het tabblad npm (Authenticatie voor npm-packages).
  2. Klik op Inloggegevens toevoegen.
  3. Vul de Registry in, een https://-adres zoals https://npm.pkg.github.com of https://registry.npmjs.org, en het Token.
  4. Klik op Opslaan.

Eén set per registry, maximaal 10.

Gegevens wijzigen of verwijderen

De lijst toont de host of registry (en de gebruikersnaam), maar nooit meer het wachtwoord of token: daar staat ••••••••. Klik op Bewerken om een set te wijzigen; laat het wachtwoord of token leeg om de opgeslagen waarde te houden. Klik op Verwijderen en bevestig om hem te wissen; de volgende deploy kan daarna geen privépakketten meer van die plek installeren.

Hoe worden de gegevens gebruikt?

De gegevens worden versleuteld opgeslagen in Vimonto Deploy en alleen aan de build gegeven terwijl een deploy draait: Composer krijgt ze via de omgevingsvariabele COMPOSER_AUTH, en de pakketbeheerder via een tijdelijke npm-gebruikersconfiguratie (NPM_CONFIG_USERCONFIG) die daarna wordt verwijderd. Er wordt niets op de server geschreven, dus er staat geen auth.json of .npmrc in je homemap of release. Wijzigingen gelden vanaf de volgende deploy.

Het tabblad Composer is er voor Laravel-, Symfony-, Statamic- en PHP-sites. Het tabblad npm is er voor elke site met een repository.

Deploymeldingen

Elk lid hoort al over deploys via de bel en zijn eigen meldingsinstellingen. Op het tabblad Meldingen stuur je de deployresultaten van een site naar meer plekken: e-mailadressen buiten de organisatie en je eigen endpoint.

Het tabblad Meldingen van de instellingen van een site met de e-mails bij mislukte deploys en de deploy-hook
Deploymeldingen van een site

Vul in wat je wilt en klik op Opslaan. Meldingen worden verstuurd als de deploy klaar is, zodat een traag endpoint een deploy nooit ophoudt. Een geannuleerde deploy telt als mislukt.

E-mails bij mislukte deploys

Vul onder E-mails bij mislukte deploys de adressen in die een e-mail moeten krijgen als een deploy van deze site mislukt, gescheiden door komma's, maximaal 10. Ze hoeven geen lid van de organisatie te zijn. De e-mail noemt de site, toont de fout en linkt naar de deploy. Hij is geschreven in de taal van wie de deploy startte.

Deploy-hook

Zet Deploy-hook aan en vul een URL in. Na elke deploy, gelukt of mislukt, stuurt Vimonto Deploy er een POST-request met JSON naartoe. Zo laat je je eigen systemen, een chatbot of een automatiseringstool weten dat er gedeployd is. De URL moet HTTPS zijn en op het openbare internet staan; redirects worden niet gevolgd, en na 10 seconden geeft het request op.

{
    "event": "deployment.succeeded",
    "site": { "id": 12, "domain": "shop.example.com" },
    "server": { "id": 3, "name": "web-1", "ip_address": "203.0.113.10" },
    "deployment": {
        "id": 481,
        "status": "succeeded",
        "branch": "main",
        "commit_hash": "9f2c1e7a4b...",
        "commit_message": "Fix the checkout total",
        "commit_author": "Sanne de Vries",
        "started_at": "2026-10-07T14:30:00+00:00",
        "finished_at": "2026-10-07T14:31:12+00:00",
        "url": "https://deploy.example.com/acme/servers/3/sites/12/deployments/481"
    }
}

event is deployment.succeeded of deployment.failed (met status failed), of test voor een testrequest. Commitvelden kunnen null zijn als ze niet bekend zijn.

De URL is een geheim: hij wordt versleuteld opgeslagen en nooit meer getoond. Is hij opgeslagen, dan is het veld leeg met de hint "Opgeslagen. Laat leeg om het te houden." Laat het leeg om hem te houden, of typ een nieuwe URL om hem te vervangen. Zet Deploy-hook uit en sla op om hem te verwijderen.

De deploy-hook testen

Is er een deploy-hook opgeslagen, klik dan naast Opslaan op Deploy-hook testen. Vimonto Deploy stuurt de gegevens van de laatste deploy van de site, met event op test. Je ziet Test verstuurd als je endpoint met een successtatus antwoordde, of De test werd niet geaccepteerd als dat niet zo was; controleer dan de URL. Je kunt zes tests per minuut per site sturen.

Een site klonen

Site klonen maakt een nieuwe site die precies zo is als deze, op dezelfde of een andere server: dezelfde repository, branch, buildinstellingen, deployscript, meldingen en regels. Gebruik het voor een stagingkopie, een tweede omgeving voor een klant, of om een site naar een nieuwe server te verhuizen. De kloon wordt meteen ingericht en gedeployd.

  1. Klik op het tabblad Algemeen, onder Site klonen, op Site klonen.
  2. Kies de Server. Je kunt elke actieve server kiezen waar je toegang toe hebt, behalve load balancers.
  3. Kies het adres van de kloon:
    • een Adres op on-deploy.link, ingevuld met een gegenereerde naam die je kunt wijzigen (als gegenereerde adressen beschikbaar zijn); of
    • klik op Eigen domein gebruiken en vul een Domein in, zoals staging.example.com. Laat het daarna naar de server wijzen en zet HTTPS aan op de pagina Domeinen en SSL van de kloon.
  4. Laat De .env kopiëren aan staan om de kloon een kopie van de .env van deze site te geven (te zien als de site er een heeft).
  5. Klik op Site klonen.

Je gaat naar de nieuwe site terwijl die wordt ingericht, net als bij een nieuwe site. De eerste deploy start als het inrichten klaar is.

Wat wordt er gekopieerd?

Gekopieerd Niet gekopieerd
Framework, repository, branch en Git-koppeling Databases en databasegebruikers
Buildinstellingen (Composer, pakketbeheerder, buildcommando) Certificaten
PHP-versie, als die op de doelserver geïnstalleerd is (anders de standaardversie van de server) Queue workers en processen
Webmap en monorepo-rootmap Sitefuncties
Zero-downtime deploys Bestanden die de app opsloeg, zoals shared/storage
Website-isolatie, met dezelfde gebruikersnaam (met een nummer erachter als de server die al heeft)
Composer- en npm-gegevens
Deployscript en quick deploy
Deploymeldingen
Doorverwijzingen en beveiligingsregels
De deploy key, bij een repository zonder Git-koppeling

De gekopieerde .env

Met De .env kopiëren aan krijgt de kloon de .env van deze site met een eigen APP_URL, ingesteld op het adres van de kloon. Al het andere blijft gelijk, dus de kloon gebruikt nog dezelfde database, mail, cache en andere diensten als het origineel. Wijzig die op de pagina Omgeving van de kloon als die eigen nodig heeft, bijvoorbeeld een nieuwe database voor een stagingsite. In het .env-verloop van de kloon heet deze versie Gekopieerd van een andere site.

Met De .env kopiëren uit krijgt de kloon een nieuwe .env, net als een nieuwe site.

Site klonen is er voor sites met een repository; WordPress, phpMyAdmin en sites op een load balancer kun je niet klonen.

Een site verwijderen

  1. Klik onderaan de pagina Instellingen, onder Site verwijderen, op Site verwijderen.
  2. Typ het domein van de site ter bevestiging en klik op Site verwijderen.

Verwijderen draait als achtergrondtaak en haalt van de server:

  • de Nginx-configuratie, de include-map en de certificaten van de site;
  • de workers en geplande jobs van de site;
  • de sitemap, met alle releases, de .env en shared/storage;
  • bij een geïsoleerde site de PHP-FPM-pool, de Linux-gebruiker en de homemap.

Vimonto Deploy verwijdert ook het DNS-record van het gegenereerde adres van de site en de DNS-records die het bij je DNS-integraties heeft gemaakt (de stap DNS-records verwijderen), en haalt de deploy key en webhook bij je Git-host weg. Als dat opruimen mislukt, vertelt de uitvoer van de taak wat je zelf moet verwijderen.

Databases en databasegebruikers blijven bewaard. Verwijder ze op de pagina Databases van de server als je ze niet meer nodig hebt.

Je kunt een site niet verwijderen zolang er nog een taak op draait, zoals een deploy: je ziet dan dat de site nog bezig is. Nadat je hebt bevestigd, ga je terug naar de pagina Sites van de server terwijl de site wordt verwijderd.

Wie kan site-instellingen wijzigen?

Elk lid kan de instellingen zien, ook de tabbladen voor inloggegevens en meldingen (zonder de opgeslagen wachtwoorden, tokens en URL van de deploy-hook). Wijzigingen opslaan, inloggegevens toevoegen of verwijderen, testberichten sturen en een site verwijderen vereisen het recht om sites te beheren (eigenaar, beheerder, manager en developer). Voor wijzigingen op het tabblad Algemeen moeten de site en haar server ook actief zijn. Zie leden en rollen.

Veelgestelde vragen

Hoe wijzig ik het domein van een site?

Op de pagina Domeinen en SSL van de site. De map van de site op de server verandert niet mee.

Hoe koppel ik een andere repository of branch?

Op de pagina Deployments van de site.

Mijn site heeft een eigen Nginx-configuratie. Gelden deze instellingen dan nog?

Ze worden opgeslagen, maar de Nginx-configuratie van de site wordt niet opnieuw geschreven: met een eigen configuratie pas je root, de PHP-FPM-socket of de proxypoort er zelf in aan.

Worden mijn Composer- en npm-gegevens op de server opgeslagen?

Nee. Ze worden versleuteld opgeslagen in Vimonto Deploy en alleen aan de build gegeven terwijl een deploy draait, via COMPOSER_AUTH en een tijdelijke npm-configuratie die daarna wordt verwijderd. Er staat geen auth.json of .npmrc op de server.

Waarom kreeg mijn deploy-hook geen request?

Klik op Deploy-hook testen om te zien of je endpoint met een successtatus antwoordt. Controleer of de URL HTTPS is, vanaf het internet bereikbaar is en niet doorverwijst: redirects worden niet gevolgd.

Kan ik isolatie aanzetten voor een bestaande site?

Nee. Isolatie kies je als de site wordt aangemaakt. Maak een nieuwe, geïsoleerde site aan op dezelfde server en deploy daarnaartoe. Site klonen neemt de isolatie over zoals ze is, dus een kloon van een site zonder isolatie is ook niet geïsoleerd.