# Paramètres du site : version PHP, répertoire web, isolation > Changez la version PHP, le répertoire web ou le zero downtime d'un site, ajoutez des identifiants Composer et npm, des e-mails d'échec et un hook de déploiement. 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 : | Onglet | Contenu | Affiché pour | | --- | --- | --- | | **Général** | Version de PHP, répertoire web ou port, déploiements sans interruption, isolation, [**Cloner le site**](#cloner-un-site) et **Supprimer le site** | Tous les sites | | **Composer** | [Identifiants des paquets Composer privés](#identifiants-composer-et-npm) | Sites Laravel, Symfony, Statamic et PHP | | **npm** | [Tokens des registres npm privés](#identifiants-composer-et-npm) | Sites avec un dépôt | | **Notifications** | [E-mails en cas d'échec et un hook de déploiement](#notifications-de-déploiement) | Sites avec un dépôt | 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. ![La page Paramètres d'un site Laravel avec la version de PHP, le répertoire web, l'interrupteur des déploiements sans interruption et l'isolation des sites](https://ops.vimonto.com/docs-media/fr/site-settings.webp?v=161e760d "Les paramètres d'un site") ## 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 : ```text /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 ``` | Réglage | Où le définir | Modifiable plus tard ? | | --- | --- | --- | | Répertoire (`example.com` ci-dessus) | Quand vous [créez le site](https://ops.vimonto.com/docs/fr/sites/create-a-site) | Non. Il reste le même quand le domaine change. | | Répertoire racine, pour un monorepo | À la création du site | Non. | | Répertoire web | Paramètres | Oui | | Version de PHP | Paramètres | Oui | | Port d'une application Node.js | Paramètres | Oui | | Déploiements sans interruption | Paramètres | Oui | | Isolation des sites | À la création du site | Non | | Domaine et alias | [Domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl) | Oui | | Dépôt et branche | [Déploiements](https://ops.vimonto.com/docs/fr/sites/deployments) | Oui | 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é](https://ops.vimonto.com/docs/fr/sites/uptime-monitoring)). À 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](https://ops.vimonto.com/docs/fr/sites/load-balancing), où vous le gérez. **Supprimer le site** s'y trouve, comme pour tout site. ![La vue d'ensemble d'un site avec son adresse, son répertoire, sa racine web, son dépôt, sa branche et les déploiements récents](https://ops.vimonto.com/docs-media/fr/site-overview.webp?v=161e760d "La vue d'ensemble d'un 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](https://ops.vimonto.com/docs/fr/servers/php) du serveur. > [!WARNING] > Les queue workers et les tâches planifiées du site continuent d'utiliser l'ancienne version de PHP. Après le changement, ajoutez-les à nouveau sur la page [files d'attente et planificateur](https://ops.vimonto.com/docs/fr/sites/queues-and-scheduler). Une notification vous le rappelle si le site en a. 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](https://ops.vimonto.com/docs/fr/sites/queues-and-scheduler#faire-tourner-une-application-nodejs)) 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. | | Activé | Désactivé | | --- | --- | --- | | Où un déploiement construit | Un nouveau répertoire de release | `releases/live`, sur place | | Un build raté | Abandonné ; le site en ligne ne change pas | Reste dans le site en ligne | | Rollback | Oui | Non | | Anciennes releases | Nettoyées après chaque déploiement | Sans objet | Le changement s'applique à partir du prochain déploiement. Consultez [déploiements](https://ops.vimonto.com/docs/fr/sites/deployments). 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](https://ops.vimonto.com/docs/fr/sites/create-a-site) ; cela ne peut plus être modifié ensuite. | | Isolation activée | Isolation désactivée | | --- | --- | --- | | Utilisateur Linux | Son propre utilisateur, par exemple `shop` | L'utilisateur système du serveur (`vimonto`), partagé avec les autres sites | | Répertoire personnel | `/home/shop`, lisible uniquement par cet utilisateur et son groupe | `/home/vimonto` | | PHP-FPM | Son propre pool, tournant sous l'utilisateur du site, sur `/run/php/site-{id}.sock` | Le pool partagé de la version de PHP | | Déploiements, workers, tâches planifiées | Tournent sous l'utilisateur du site | Tournent sous l'utilisateur système | 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](https://ops.vimonto.com/docs/fr/sites/create-a-site#paquets-composer-et-npm-privés). ![L'onglet Composer des paramètres d'un site avec des identifiants enregistrés pour repo.packagist.com](https://ops.vimonto.com/docs-media/fr/site-composer.webp?v=161e760d "Authentification des paquets Composer") ### 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](https://ops.vimonto.com/docs/fr/more/notifications). 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. ![L'onglet Notifications des paramètres d'un site avec les e-mails en cas d'échec et le hook de déploiement](https://ops.vimonto.com/docs-media/fr/site-notifications.webp?v=161e760d "Les notifications de déploiement d'un site") 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. ```json { "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](https://ops.vimonto.com/docs/fr/sites/create-a-site#que-se-passe-t-il-après-avoir-cliqué-sur-créer-le-site-). Son premier déploiement démarre une fois l'installation terminée. ### Qu'est-ce qui est copié ? | Copié | Non copié | | --- | --- | | Framework, dépôt, branche et connexion Git | Bases de données et utilisateurs de base de données | | Réglages de build (Composer, gestionnaire de paquets, commande de build) | Certificats | | Version de PHP, si elle est installée sur le serveur cible (sinon celle par défaut du serveur) | Workers de file d'attente et processus | | Répertoire web et racine de monorepo | [Fonctionnalités de site](https://ops.vimonto.com/docs/fr/sites/site-features) | | Déploiements sans interruption | Fichiers enregistrés par l'application, comme `shared/storage` | | Isolation des sites, avec le même nom d'utilisateur (suivi d'un numéro si le serveur l'a déjà) | | | Identifiants Composer et npm | | | Script de déploiement et quick deploy | | | Notifications de déploiement | | | [Redirections](https://ops.vimonto.com/docs/fr/sites/redirects) et [règles de sécurité](https://ops.vimonto.com/docs/fr/sites/security-rules) | | | La clé de déploiement, pour un dépôt sans connexion Git | | ### 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](https://ops.vimonto.com/docs/fr/sites/environment) 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](https://ops.vimonto.com/docs/fr/connections/integrations) (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](https://ops.vimonto.com/docs/fr/servers/databases) 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é. > [!WARNING] > La suppression d'un site est irréversible. Téléchargez d'abord ce dont vous avez besoin dans `shared/storage`, et gardez une copie du `.env`. ## 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](https://ops.vimonto.com/docs/fr/organization/members-and-roles). ## Questions fréquentes ### Comment changer le domaine d'un site ? Sur la page [Domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-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](https://ops.vimonto.com/docs/fr/sites/deployments) 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](https://ops.vimonto.com/docs/fr/sites/nginx#quest-ce-qui-change-quand-vous-utilisez-votre-propre-configuration-), 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.