Paramètres du site : version PHP, répertoire web, isolation

La page Paramètres d'un site définit la façon dont le site tourne sur son serveur : sa version de PHP, le répertoire servi par Nginx, l'utilisation ou non de releases sans interruption pour les déploiements, et l'isolation du site. Elle contient aussi les identifiants des paquets Composer et npm privés et les destinations des résultats de déploiement du site, et c'est là que vous clonez ou supprimez un site.

Vous la trouvez en bas de la barre latérale du site sous Paramètres. Certains éléments se règlent ailleurs : le domaine dans Domaines et SSL, le dépôt et la branche dans Déploiements, et le répertoire et la racine de monorepo une fois pour toutes, à la création du site.

La page a des onglets en haut :

WordPress, phpMyAdmin et les sites d'un load balancer n'ont ni dépôt ni build : ils n'ont que les paramètres généraux, sans onglets.

Où se trouve le site sur le serveur#

Chaque site a un répertoire dans le dossier personnel de l'utilisateur sous lequel il tourne, organisé pour les déploiements sans interruption :

/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

La Vue d'ensemble du site affiche d'un coup d'œil l'adresse, le répertoire, la racine web, HTTPS, le dépôt, la branche, le déploiement rapide et les déploiements récents. Pour un site à charge répartie, elle liste à la place les serveurs d'application placés derrière. En dessous, le panneau Disponibilité indique si le site est joignable, avec 90 jours d'historique (voir surveillance de la disponibilité). À droite, Activité liste les dernières tâches du site, les plus récentes en premier : déploiements, certificats, workers, fonctionnalités, commandes et autres tâches, chacune avec la personne qui l'a lancée et son résultat. Cliquez sur une ligne pour ouvrir la tâche et sa sortie ; Charger plus affiche les plus anciennes.

Tant que le site n'est pas entièrement configuré, la vue d'ensemble commence par Prochaines étapes, comme connecter un dépôt ou activer HTTPS. Une étape dont vous n'avez pas besoin resterait toujours affichée : cliquez sur Cacher pour masquer la liste pour ce site. Cela ne vaut que pour vous.

Un site sur un load balancer ne fait que transmettre les requêtes à ses serveurs d'application : sa page Paramètres n'a donc ni version de PHP, ni répertoire web, ni déploiements sans interruption, ni isolation. Elle indique qu'il n'y a rien à régler et renvoie à sa page Répartition de charge, où vous le gérez. Supprimer le site s'y trouve, comme pour tout site.

Changer la version de PHP#

Pour les sites PHP et Laravel, Version de PHP liste les versions installées sur le serveur. Choisissez-en une et cliquez sur Enregistrer.

Vimonto Deploy réécrit la configuration Nginx du site pour que les requêtes PHP aillent vers le PHP-FPM de la nouvelle version et, pour un site isolé, déplace son pool PHP-FPM vers cette version. Pour utiliser une version non listée, installez-la d'abord sur la page PHP du serveur.

Vérifiez aussi que votre script de déploiement n'appelle pas un binaire PHP fixe comme php8.3.

Changer le répertoire web#

Le Répertoire web est le répertoire que Nginx sert dans votre projet : /public pour Laravel, souvent /dist ou /build pour un site statique, ou / pour la racine du projet. Il est relatif à la release (ou au répertoire racine du monorepo, si le site en a un). Utilisez des lettres, des chiffres, des points, des tirets et des tirets bas, par exemple /public ou /apps/web/public.

Cliquez sur Enregistrer et la configuration Nginx est réécrite avec le nouveau root.

Changer le port d'une application Node.js#

Pour un site Node.js, Port de votre application remplace le répertoire web. Nginx transmet chaque requête à votre application sur 127.0.0.1 et ce port, entre 1024 et 65535. Quand vous enregistrez un nouveau port, le processus qui fait tourner votre application (sous Processus) passe lui aussi sur ce port et redémarre. Si vous avez ajouté votre propre commande de démarrage, modifiez-y le port vous-même.

Déploiements sans interruption#

Avec les Déploiements sans interruption activés (par défaut), chaque déploiement construit une nouvelle release dans releases/ et ne la met en ligne qu'une fois tout réussi, en basculant le lien symbolique current en une seule étape. Les visiteurs ne voient jamais un build à moitié terminé, un build raté ne change rien, les anciennes releases sont nettoyées et vous pouvez revenir à une release précédente.

Désactivés, le code est mis à jour sur place : chaque déploiement met à jour et construit la même release, releases/live. C'est plus rapide et cela prend moins d'espace disque, mais les visiteurs voient le build se dérouler, un build raté peut laisser le site en ligne à moitié mis à jour, et il n'y a rien vers quoi revenir en arrière.

Le changement s'applique à partir du prochain déploiement. Consultez déploiements.

L'interrupteur n'est pas affiché pour les applications installées comme WordPress et phpMyAdmin.

Isolation des sites#

Isolation des sites indique si le site tourne sous son propre utilisateur Linux. Vous le choisissez quand vous créez le site ; cela ne peut plus être modifié ensuite.

L'isolation sépare les sites d'un même serveur : un plugin vulnérable dans un site ne peut pas lire les fichiers ou le .env d'un autre. Nginx peut toujours lire les fichiers du site, car l'utilisateur système, sous lequel tourne Nginx, est ajouté au groupe de l'utilisateur du site.

Utilisez l'isolation quand un serveur héberge des sites de clients différents, ou des sites auxquels vous faites moins confiance, comme WordPress.

Identifiants Composer et npm#

Pour installer des paquets privés pendant un déploiement, comme Laravel Nova, Private Packagist ou des paquets sur GitHub Packages, le build a besoin d'identifiants. Vous les gérez dans les onglets Composer et npm. Ce sont les mêmes identifiants que ceux que vous pouvez saisir sous Authentification Composer et Authentification npm quand vous créez le site.

Ajouter des identifiants Composer#

1. Ouvrez les Paramètres du site et cliquez sur l'onglet Composer (Authentification des paquets Composer).
2. Cliquez sur Ajouter des identifiants.
3. Renseignez l'Hôte (par exemple repo.packagist.com ou nova.laravel.com), le Nom d'utilisateur et le Mot de passe. Un token ou une clé de licence se met aussi dans Mot de passe.
4. Cliquez sur Enregistrer.

Ce sont les identifiants http-basic du fichier auth.json de Composer. Vous pouvez ajouter une entrée par hôte, 10 au maximum.

Ajouter des identifiants npm#

1. Cliquez sur l'onglet npm (Authentification des paquets npm).
2. Cliquez sur Ajouter des identifiants.
3. Renseignez le Registry, une adresse https:// comme https://npm.pkg.github.com ou https://registry.npmjs.org, et le Token.
4. Cliquez sur Enregistrer.

Une entrée par registre, 10 au maximum.

Modifier ou supprimer des identifiants#

La liste affiche l'hôte ou le registre (et le nom d'utilisateur), mais plus jamais le mot de passe ni le token : elle affiche ••••••••. Cliquez sur Modifier pour changer une entrée ; laissez le mot de passe ou le token vide pour garder celui enregistré. Cliquez sur Supprimer et confirmez pour l'effacer ; le déploiement suivant ne pourra plus installer de paquets privés depuis cet endroit.

Comment les identifiants sont-ils utilisés ?#

Les identifiants sont stockés chiffrés dans Vimonto Deploy et transmis au build uniquement pendant un déploiement : Composer les reçoit par la variable d'environnement COMPOSER_AUTH, et le gestionnaire de paquets par une configuration utilisateur npm temporaire (NPM_CONFIG_USERCONFIG) supprimée ensuite. Rien n'est écrit sur le serveur : il n'y a ni auth.json ni .npmrc dans votre répertoire personnel ou votre release. Les modifications s'appliquent à partir du déploiement suivant.

L'onglet Composer existe pour les sites Laravel, Symfony, Statamic et PHP. L'onglet npm existe pour chaque site avec un dépôt.

Notifications de déploiement#

Chaque membre est déjà informé des déploiements par la cloche et ses propres paramètres de notification. Dans l'onglet Notifications, vous envoyez les résultats des déploiements d'un site à d'autres destinataires : des adresses e-mail extérieures à l'organisation et votre propre endpoint.

Remplissez ce que vous voulez et cliquez sur Enregistrer. Les notifications partent une fois le déploiement terminé, si bien qu'un endpoint lent ne retarde jamais un déploiement. Un déploiement annulé compte comme échoué.

E-mails en cas d'échec de déploiement#

Sous E-mails en cas d'échec de déploiement, saisissez les adresses qui doivent recevoir un e-mail chaque fois qu'un déploiement de ce site échoue, séparées par des virgules, 10 au maximum. Elles n'ont pas besoin d'appartenir à l'organisation. L'e-mail nomme le site, affiche l'erreur et renvoie vers le déploiement. Il est rédigé dans la langue de la personne qui a lancé le déploiement.

Hook de déploiement#

Activez Hook de déploiement et saisissez une URL. Après chaque déploiement, réussi ou échoué, Vimonto Deploy y envoie une requête POST avec du JSON. Servez-vous-en pour prévenir vos propres systèmes, un bot de chat ou un outil d'automatisation. L'URL doit être en HTTPS et sur l'internet public ; les redirections ne sont pas suivies et la requête abandonne au bout de 10 secondes.

{
    "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 vaut deployment.succeeded ou deployment.failed (avec status à failed), ou test pour une requête de test. Les champs du commit peuvent valoir null quand ils ne sont pas connus.

L'URL est un secret : elle est stockée chiffrée et n'est plus jamais affichée. Une fois enregistrée, le champ est vide avec l'indication « Enregistré. Laissez vide pour le garder. » Laissez-le vide pour la garder, ou saisissez une nouvelle URL pour la remplacer. Désactivez Hook de déploiement et enregistrez pour le supprimer.

Tester le hook de déploiement#

Une fois un hook de déploiement enregistré, cliquez sur Tester le hook de déploiement à côté de Enregistrer. Vimonto Deploy envoie les données du dernier déploiement du site, avec event à test. Vous voyez Test envoyé si votre endpoint a répondu avec un statut de succès, ou Le test n'a pas été accepté sinon ; vérifiez alors l'URL. Vous pouvez envoyer six tests par minute et par site.

Cloner un site#

Cloner le site crée un nouveau site identique à celui-ci, sur le même serveur ou sur un autre : même dépôt, même branche, mêmes réglages de build, même script de déploiement, mêmes notifications et mêmes règles. Servez-vous-en pour une copie de staging, un second environnement pour un client, ou pour déplacer un site vers un nouveau serveur. Le clone est installé et déployé tout de suite.

1. Dans l'onglet Général, sous Cloner le site, cliquez sur Cloner le site.
2. Choisissez le Serveur. Vous pouvez choisir tout serveur actif auquel vous avez accès, sauf les load balancers.
3. Choisissez l'adresse du clone :
   • une Adresse sur on-deploy.link, préremplie avec un nom généré que vous pouvez changer (quand les adresses générées sont disponibles) ; ou
   • cliquez sur Utiliser un domaine personnalisé et saisissez un Domaine, comme staging.example.com. Faites-le ensuite pointer vers le serveur et activez HTTPS sur la page Domaines et SSL du clone.
4. Laissez Copier le .env activé pour donner au clone une copie du .env de ce site (affiché quand le site en a un).
5. Cliquez sur Cloner le site.

Vous arrivez sur le nouveau site pendant son installation, comme pour un nouveau site. Son premier déploiement démarre une fois l'installation terminée.

Qu'est-ce qui est copié ?#

Le .env copié#

Avec Copier le .env activé, le clone reçoit le .env de ce site avec son propre APP_URL, réglé sur l'adresse du clone. Tout le reste est identique : le clone utilise donc toujours la même base de données, le même mail, le même cache et les mêmes autres services que l'original. Modifiez-les sur la page Environnement du clone s'il lui faut les siens, par exemple une nouvelle base de données pour un site de staging. Dans l'historique du .env du clone, cette version s'affiche comme Copié d'un autre site.

Avec Copier le .env désactivé, le clone reçoit un nouveau .env, comme un nouveau site.

Cloner le site existe pour les sites avec un dépôt ; WordPress, phpMyAdmin et les sites d'un load balancer ne peuvent pas être clonés.

Supprimer un site#

1. En bas de la page Paramètres, sous Supprimer le site, cliquez sur Supprimer le site.
2. Saisissez le domaine du site pour confirmer et cliquez sur Supprimer le site.

La suppression s'exécute sous forme de tâche en arrière-plan et retire du serveur :

• la configuration Nginx, son dossier d'include et les certificats du site ;
• les workers et les tâches planifiées du site ;
• le répertoire du site, avec toutes les releases, le .env et shared/storage ;
• pour un site isolé, son pool PHP-FPM ainsi que son utilisateur Linux et son répertoire personnel.

Vimonto Deploy supprime aussi l'enregistrement DNS de l'adresse générée du site et les enregistrements DNS qu'il a créés chez vos intégrations DNS (l'étape Supprimer les enregistrements DNS), et retire la deploy key et le webhook chez votre hébergeur Git. Si ce nettoyage échoue, la sortie de la tâche vous indique ce qu'il faut supprimer vous-même.

Les bases de données et leurs utilisateurs sont conservés. Supprimez-les sur la page Bases de données du serveur si vous n'en avez plus besoin.

Vous ne pouvez pas supprimer un site tant qu'une tâche, comme un déploiement, tourne encore dessus : un message vous indique que le site est encore occupé. Après votre confirmation, vous revenez sur la page Sites du serveur pendant que le site est supprimé.

Qui peut modifier les paramètres du site ?#

Chaque membre peut voir les paramètres, y compris les onglets des identifiants et des notifications (sans les mots de passe, tokens et l'URL du hook de déploiement enregistrés). Enregistrer des modifications, ajouter ou supprimer des identifiants, envoyer des messages de test et supprimer un site nécessitent la permission de gérer les sites (propriétaire, administrateur, manager et développeur). Les modifications de l'onglet Général exigent en plus que le site et son serveur soient actifs. Consultez membres et rôles.

Questions fréquentes#

Comment changer le domaine d'un site ?#

Sur la page Domaines et SSL du site. Le répertoire du site sur le serveur ne change pas pour autant.

Comment connecter un autre dépôt ou une autre branche ?#

Sur la page Déploiements du site.

Mon site a une configuration Nginx personnalisée. Ces réglages s'appliquent-ils encore ?#

Ils sont enregistrés, mais la configuration Nginx du site n'est pas réécrite : avec une configuration personnalisée, vous mettez vous-même à jour root, le socket PHP-FPM ou le port du proxy.

Mes identifiants Composer et npm sont-ils stockés sur le serveur ?#

Non. Ils sont stockés chiffrés dans Vimonto Deploy et transmis au build uniquement pendant un déploiement, via COMPOSER_AUTH et une configuration npm temporaire supprimée ensuite. Il n'y a ni auth.json ni .npmrc sur le serveur.

Pourquoi mon hook de déploiement n'a-t-il reçu aucune requête ?#

Cliquez sur Tester le hook de déploiement pour voir si votre endpoint répond avec un statut de succès. Vérifiez que l'URL est en HTTPS, joignable depuis internet et sans redirection : les redirections ne sont pas suivies.

Puis-je activer l'isolation pour un site existant ?#

Non. L'isolation se choisit à la création du site. Créez un nouveau site isolé sur le même serveur et déployez-y votre code. Cloner le site reprend l'isolation telle quelle : le clone d'un site sans isolation n'est pas isolé non plus.