# Impostazioni del sito: PHP, directory web e isolamento > Cambia versione PHP, directory web o deploy zero downtime di un sito, aggiungi credenziali Composer e npm, email per deploy falliti e un hook di deploy. La pagina **Impostazioni** di un sito definisce come il sito gira sul suo server: la versione di PHP, la directory servita da Nginx, se i deploy usano release zero-downtime e se il sito gira isolato. Contiene anche le credenziali per i pacchetti Composer e npm privati e dove vanno i risultati dei deploy del sito, ed è il punto in cui cloni o elimini un sito. La trovi in fondo alla barra laterale del sito, sotto **Impostazioni**. Alcune cose si impostano altrove: il dominio in **Domini e SSL**, il repository e il branch in **Deployment**, e la directory e la root del monorepo una sola volta, quando crei il sito. In cima alla pagina ci sono delle schede: | Scheda | Cosa contiene | Presente per | | --- | --- | --- | | **Generale** | Versione PHP, directory web o porta, deploy zero-downtime, isolamento, [**Clona sito**](#clonare-un-sito) e **Elimina sito** | Ogni sito | | **Composer** | [Credenziali per pacchetti Composer privati](#credenziali-per-composer-e-npm) | Siti Laravel, Symfony, Statamic e PHP | | **npm** | [Token per registry npm privati](#credenziali-per-composer-e-npm) | Siti con un repository | | **Notifiche** | [Email per deploy non riusciti e un hook di deploy](#notifiche-di-deploy) | Siti con un repository | WordPress, phpMyAdmin e i siti su un load balancer non hanno repository né build, quindi hanno solo le impostazioni generali, senza schede. ![La pagina Impostazioni di un sito Laravel con versione PHP, directory web, interruttore dei deploy zero-downtime e isolamento del sito](https://ops.vimonto.com/docs-media/it/site-settings.webp?v=161e760d "Le impostazioni di un sito") ## Dove si trova il sito sul server Ogni sito ha una directory nella cartella home dell'utente con cui gira, organizzata per i deploy zero-downtime: ```text /home/vimonto/example.com/ ├── current -> releases/20261007143000 # la release attiva ├── releases/ # una directory per ogni deploy └── shared/ ├── .env # mantenuto tra le release └── storage/ # lo storage di Laravel, mantenuto tra le release ``` | Impostazione | Dove la imposti | Si può cambiare in seguito? | | --- | --- | --- | | Directory (`example.com` qui sopra) | Quando [crei il sito](https://ops.vimonto.com/docs/it/sites/create-a-site) | No. Resta uguale quando cambia il dominio. | | Directory root, per un monorepo | Quando crei il sito | No. | | Directory web | Impostazioni | Sì | | Versione PHP | Impostazioni | Sì | | Porta di un'app Node.js | Impostazioni | Sì | | Deploy zero-downtime | Impostazioni | Sì | | Isolamento del sito | Quando crei il sito | No | | Dominio e alias | [Domini e SSL](https://ops.vimonto.com/docs/it/sites/domains-and-ssl) | Sì | | Repository e branch | [Deployment](https://ops.vimonto.com/docs/it/sites/deployments) | Sì | La **Panoramica** del sito mostra a colpo d'occhio indirizzo, directory, web root, HTTPS, repository, branch, quick deploy e i deploy recenti. Per un sito con bilanciamento del carico elenca invece gli app server dietro di esso. Più in basso, il pannello **Uptime** mostra se il sito è raggiungibile, con 90 giorni di storico (vedi [monitoraggio dell'uptime](https://ops.vimonto.com/docs/it/sites/uptime-monitoring)). A destra, **Attività** elenca il lavoro più recente sul sito, dal più nuovo: deploy, certificati, worker, funzionalità, comandi e altre attività, ognuna con chi l'ha avviata e com'è andata. Fai clic su una riga per aprire l'attività con il suo output; **Carica altro** mostra quelle più vecchie. Finché il sito non è del tutto configurato, la panoramica inizia con **Prossimi passi**, come collegare un repository o attivare HTTPS. Un passo che non ti serve resterebbe sempre aperto: fai clic su **Nascondi** per nascondere l'elenco per questo sito. Vale solo per te. Un sito su un load balancer si limita a inoltrare le richieste ai suoi app server, quindi la sua pagina **Impostazioni** non ha versione PHP, directory web, deploy zero-downtime né isolamento: dice che non c'è nulla da impostare e rimanda alla sua pagina [Bilanciamento del carico](https://ops.vimonto.com/docs/it/sites/load-balancing), da cui lo gestisci. **Elimina sito** c'è, come per ogni sito. ![La panoramica di un sito con indirizzo, directory, web root, repository, branch e deploy recenti](https://ops.vimonto.com/docs-media/it/site-overview.webp?v=161e760d "La panoramica di un sito") ## Cambiare la versione di PHP Per i siti PHP e Laravel, **Versione PHP** elenca le versioni installate sul server. Scegline una e fai clic su **Salva**. Vimonto Deploy riscrive la configurazione Nginx del sito in modo che le richieste PHP vadano al PHP-FPM della nuova versione e, per un sito isolato, sposta il suo pool PHP-FPM su quella versione. Per usare una versione non elencata, installala prima nella pagina [PHP](https://ops.vimonto.com/docs/it/servers/php) del server. > [!WARNING] > I queue worker e i job pianificati del sito continuano a usare la versione di PHP precedente. Dopo il cambio, aggiungili di nuovo nella pagina [queue e scheduler](https://ops.vimonto.com/docs/it/sites/queues-and-scheduler). Una notifica te lo ricorda quando il sito ne ha. Controlla anche che il tuo script di deploy non richiami un binario PHP fisso come `php8.3`. ## Cambiare la directory web La **Directory web** è la directory servita da Nginx, all'interno del tuo progetto: `/public` per Laravel, spesso `/dist` o `/build` per un sito statico, oppure `/` per la root del progetto. È relativa alla release (o alla directory root del monorepo, se il sito ne ha una). Usa lettere, numeri, punti, trattini e underscore, per esempio `/public` o `/apps/web/public`. Fai clic su **Salva** e la configurazione Nginx viene riscritta con il nuovo `root`. ## Cambiare la porta di un'app Node.js Per un sito Node.js, **Porta della tua app** sostituisce la directory web. Nginx inoltra ogni richiesta alla tua app su `127.0.0.1` e su questa porta, tra 1024 e 65535. Quando salvi una nuova porta, anche il processo che esegue la tua app (in [Processi](https://ops.vimonto.com/docs/it/sites/queues-and-scheduler#eseguire-unapp-nodejs)) passa alla nuova porta e si riavvia. Se hai aggiunto un tuo comando di avvio, cambia tu la porta al suo interno. ## Deploy zero-downtime Con **Deploy zero-downtime** attivo (il default), ogni deploy costruisce una nuova release in `releases/` e la porta online solo quando tutto è andato a buon fine, cambiando il symlink `current` in un solo passaggio. I visitatori non vedono mai una build a metà, una build fallita non cambia nulla, le vecchie release vengono ripulite e puoi fare il rollback a una release precedente. Se è disattivato, il codice viene aggiornato sul posto: ogni deploy aggiorna e ricostruisce la stessa release, `releases/live`. È più veloce e occupa meno spazio su disco, ma i visitatori vedono la build in corso, una build fallita può lasciare il sito live aggiornato a metà e non c'è nulla a cui tornare con un rollback. | | On | Off | | --- | --- | --- | | Dove costruisce un deploy | In una nuova directory di release | In `releases/live`, sul posto | | Una build fallita | Scartata; il sito live non cambia | Resta nel sito live | | Rollback | Sì | No | | Vecchie release | Eliminate dopo ogni deploy | Non applicabile | La modifica vale dal deploy successivo. Vedi [deployment](https://ops.vimonto.com/docs/it/sites/deployments). L'interruttore non viene mostrato per le applicazioni installate come WordPress e phpMyAdmin. ## Isolamento del sito **Isolamento del sito** mostra se il sito gira con un proprio utente Linux. Lo scegli quando [crei il sito](https://ops.vimonto.com/docs/it/sites/create-a-site); non si può cambiare in seguito. | | Isolamento attivo | Isolamento disattivato | | --- | --- | --- | | Utente Linux | Un utente proprio, per esempio `shop` | L'utente di sistema del server (`vimonto`), condiviso con altri siti | | Directory home | `/home/shop`, leggibile solo da quell'utente e dal suo gruppo | `/home/vimonto` | | PHP-FPM | Un pool proprio, eseguito con l'utente del sito, su `/run/php/site-{id}.sock` | Il pool condiviso della versione di PHP | | Deploy, worker, job pianificati | Girano con l'utente del sito | Girano con l'utente di sistema | L'isolamento tiene separati i siti sullo stesso server: un plugin vulnerabile in un sito non può leggere i file o il `.env` di un altro. Nginx può comunque leggere i file del sito perché l'utente di sistema, con cui gira Nginx, viene aggiunto al gruppo dell'utente del sito. Usa l'isolamento quando un server ospita siti di clienti diversi, o siti di cui ti fidi meno, come WordPress. ## Credenziali per Composer e npm Per installare pacchetti privati durante un deploy, come Laravel Nova, Private Packagist o pacchetti su GitHub Packages, la build ha bisogno di credenziali. Le gestisci nelle schede **Composer** e **npm**. Sono le stesse credenziali che puoi inserire in **Autenticazione Composer** e **Autenticazione npm** quando [crei il sito](https://ops.vimonto.com/docs/it/sites/create-a-site#pacchetti-composer-e-npm-privati). ![La scheda Composer delle impostazioni di un sito con credenziali salvate per repo.packagist.com](https://ops.vimonto.com/docs-media/it/site-composer.webp?v=161e760d "Autenticazione dei pacchetti Composer") ### Aggiungere credenziali Composer 1. Apri le **Impostazioni** del sito e clicca sulla scheda **Composer** (**Autenticazione dei pacchetti Composer**). 2. Clicca su **Aggiungi credenziali**. 3. Compila l'**Host** (per esempio `repo.packagist.com` o `nova.laravel.com`), il **Nome utente** e la **Password**. Anche un token o una chiave di licenza va in **Password**. 4. Clicca su **Salva**. Sono le credenziali `http-basic` del file `auth.json` di Composer. Puoi aggiungere una voce per host, al massimo 10. ### Aggiungere credenziali npm 1. Clicca sulla scheda **npm** (**Autenticazione dei pacchetti npm**). 2. Clicca su **Aggiungi credenziali**. 3. Compila il **Registry**, un indirizzo `https://` come `https://npm.pkg.github.com` o `https://registry.npmjs.org`, e il **Token**. 4. Clicca su **Salva**. Una voce per registry, al massimo 10. ### Modificare o rimuovere credenziali L'elenco mostra l'host o il registry (e il nome utente), ma mai più la password o il token: al loro posto vedi `••••••••`. Clicca su **Modifica** per cambiare una voce; lascia vuoti la password o il token per mantenere quelli salvati. Clicca su **Rimuovi** e conferma per eliminarla; il deploy successivo non potrà più installare pacchetti privati da lì. ### Come vengono usate le credenziali? Le credenziali sono salvate cifrate in Vimonto Deploy e passate alla build solo mentre un deploy è in corso: Composer le riceve tramite la variabile d'ambiente `COMPOSER_AUTH`, il package manager tramite una configurazione utente npm temporanea (`NPM_CONFIG_USERCONFIG`) che viene rimossa subito dopo. Sul server non viene scritto nulla, quindi non c'è nessun `auth.json` o `.npmrc` nella tua home o nella release. Le modifiche valgono dal deploy successivo. La scheda **Composer** c'è per i siti Laravel, Symfony, Statamic e PHP. La scheda **npm** c'è per ogni sito con un repository. ## Notifiche di deploy Ogni membro è già informato dei deploy tramite la campanella e le proprie [impostazioni delle notifiche](https://ops.vimonto.com/docs/it/more/notifications). Nella scheda **Notifiche** invii i risultati dei deploy di un sito ad altri destinatari: indirizzi email esterni all'organizzazione e un tuo endpoint. ![La scheda Notifiche delle impostazioni di un sito con le email per deploy non riusciti e l'hook di deploy](https://ops.vimonto.com/docs-media/it/site-notifications.webp?v=161e760d "Le notifiche di deploy di un sito") Compila ciò che ti serve e clicca su **Salva**. Le notifiche partono a deploy finito, così un endpoint lento non rallenta mai un deploy. Un deploy annullato conta come non riuscito. ### Email per deploy non riusciti In **Email per deploy non riusciti** inserisci gli indirizzi che devono ricevere un'email ogni volta che un deploy di questo sito non riesce, separati da virgole, al massimo 10. Non devono per forza essere membri dell'organizzazione. L'email indica il sito, mostra l'errore e rimanda al deploy. È scritta nella lingua di chi ha avviato il deploy. ### Hook di deploy Attiva **Hook di deploy** e inserisci un **URL**. Dopo ogni deploy, riuscito o no, Vimonto Deploy gli invia una richiesta `POST` con JSON. Usalo per avvisare i tuoi sistemi, un bot di chat o uno strumento di automazione. L'URL deve essere HTTPS e raggiungibile su internet; i redirect non vengono seguiti e la richiesta si interrompe dopo 10 secondi. ```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` è `deployment.succeeded` o `deployment.failed` (con `status` `failed`), oppure `test` per una richiesta di prova. I campi del commit possono essere `null` quando non sono noti. L'URL è un segreto: viene salvato cifrato e non viene mai più mostrato. Una volta salvato, il campo è vuoto con il suggerimento "Salvato. Lascia vuoto per mantenerlo." Lascialo vuoto per mantenerlo, o scrivi un nuovo URL per sostituirlo. Disattiva **Hook di deploy** e salva per rimuoverlo. ### Provare l'hook di deploy Quando un hook di deploy è salvato, clicca su **Prova l'hook di deploy** accanto a **Salva**. Vimonto Deploy invia i dati dell'ultimo deploy del sito, con `event` impostato a `test`. Vedi **Test inviato** se il tuo endpoint ha risposto con uno stato di successo, oppure **Il test non è stato accettato** se no; in quel caso controlla l'URL. Puoi inviare sei prove al minuto per sito. ## Clonare un sito **Clona sito** crea un nuovo sito uguale a questo, sullo stesso server o su un altro: stesso repository, branch, impostazioni di build, script di deploy, notifiche e regole. Usalo per una copia di staging, un secondo ambiente per un cliente o per spostare un sito su un nuovo server. Il clone viene configurato e deployato subito. 1. Nella scheda **Generale**, in **Clona sito**, clicca su **Clona sito**. 2. Scegli il **Server**. Puoi scegliere ogni server attivo a cui hai accesso, tranne i load balancer. 3. Scegli l'indirizzo del clone: - un **Indirizzo** su `on-deploy.link`, precompilato con un nome generato che puoi cambiare (quando gli indirizzi generati sono disponibili); oppure - clicca su **Usa un dominio personalizzato** e inserisci un **Dominio**, come `staging.example.com`. Poi puntalo al server e attiva HTTPS nella pagina **Domini e SSL** del clone. 4. Lascia attivo **Copia il .env** per dare al clone una copia del `.env` di questo sito (visibile quando il sito ne ha uno). 5. Clicca su **Clona sito**. Vieni portato al nuovo sito mentre viene configurato, come per un [nuovo sito](https://ops.vimonto.com/docs/it/sites/create-a-site#cosa-succede-dopo-aver-cliccato-su-crea-sito). Il suo primo deploy parte quando la configurazione è finita. ### Cosa viene copiato? | Copiato | Non copiato | | --- | --- | | Framework, repository, branch e connessione Git | Database e utenti del database | | Impostazioni di build (Composer, package manager, comando di build) | Certificati | | Versione PHP, se è installata sul server di destinazione (altrimenti quella predefinita del server) | Queue worker e processi | | Directory web e root del monorepo | [Funzionalità del sito](https://ops.vimonto.com/docs/it/sites/site-features) | | Deploy zero-downtime | File salvati dall'app, come `shared/storage` | | Isolamento del sito, con lo stesso nome utente (con un numero aggiunto se il server lo ha già) | | | Credenziali Composer e npm | | | Script di deploy e quick deploy | | | Notifiche di deploy | | | [Redirect](https://ops.vimonto.com/docs/it/sites/redirects) e [regole di sicurezza](https://ops.vimonto.com/docs/it/sites/security-rules) | | | La deploy key, per un repository senza connessione Git | | ### Il .env copiato Con **Copia il .env** attivo, il clone riceve il `.env` di questo sito con il proprio `APP_URL`, impostato sull'indirizzo del clone. Tutto il resto resta uguale, quindi il clone usa ancora **lo stesso database, la stessa posta, la stessa cache e gli stessi altri servizi** dell'originale. Cambiali nella pagina [Ambiente](https://ops.vimonto.com/docs/it/sites/environment) del clone se gliene servono di propri, per esempio un nuovo database per un sito di staging. Nella cronologia del `.env` del clone, questa versione appare come **Copiato da un altro sito**. Con **Copia il .env** disattivato, il clone riceve un `.env` nuovo, come un nuovo sito. **Clona sito** c'è per i siti con un repository; WordPress, phpMyAdmin e i siti su un load balancer non si possono clonare. ## Eliminare un sito 1. In fondo alla pagina Impostazioni, sotto **Elimina sito**, fai clic su **Elimina sito**. 2. Digita il dominio del sito per confermare e fai clic su **Elimina sito**. L'eliminazione avviene come task in background e rimuove dal server: - la configurazione Nginx, la sua cartella include e i certificati del sito; - i worker e i job pianificati del sito; - la directory del sito, con tutte le release, il `.env` e `shared/storage`; - per un sito isolato, il suo pool PHP-FPM, il suo utente Linux e la sua directory home. Vimonto Deploy elimina anche il record DNS dell'indirizzo generato del sito e i record DNS che ha creato presso le tue [integrazioni DNS](https://ops.vimonto.com/docs/it/connections/integrations) (il passaggio **Rimuovi i record DNS**), e rimuove la deploy key e il webhook dal tuo Git host. Se questa pulizia non riesce, l'output del task ti dice cosa rimuovere tu stesso. I database e gli utenti del database vengono mantenuti. Eliminali nella pagina [Database](https://ops.vimonto.com/docs/it/servers/databases) del server se non ti servono più. Non puoi eliminare un sito mentre è ancora in corso un task su di esso, come un deploy: vedi che il sito è ancora occupato. Dopo la conferma torni alla pagina **Siti** del server mentre il sito viene rimosso. > [!WARNING] > L'eliminazione di un sito non si può annullare. Scarica prima tutto ciò che ti serve da `shared/storage` e conserva una copia del `.env`. ## Chi può modificare le impostazioni del sito? Ogni membro può vedere le impostazioni, anche le schede delle credenziali e delle notifiche (senza le password, i token e l'URL dell'hook di deploy salvati). Per salvare le modifiche, aggiungere o rimuovere credenziali, inviare messaggi di prova ed eliminare un sito serve il permesso di gestire i siti (proprietario, amministratore, manager e sviluppatore). Per le modifiche nella scheda **Generale** il sito e il suo server devono anche essere attivi. Vedi [membri e ruoli](https://ops.vimonto.com/docs/it/organization/members-and-roles). ## Domande frequenti ### Come cambio il dominio di un sito? Nella pagina [Domini e SSL](https://ops.vimonto.com/docs/it/sites/domains-and-ssl) del sito. La directory del sito sul server non cambia di conseguenza. ### Come collego un altro repository o branch? Nella pagina [Deployment](https://ops.vimonto.com/docs/it/sites/deployments) del sito. ### Il mio sito ha una configurazione Nginx personalizzata. Queste impostazioni valgono ancora? Vengono salvate, ma la configurazione Nginx del sito non viene riscritta: con una [configurazione personalizzata](https://ops.vimonto.com/docs/it/sites/nginx#cosa-cambia-quando-usi-una-configurazione-tua), aggiorni tu stesso `root`, il socket PHP-FPM o la porta del proxy al suo interno. ### Le mie credenziali Composer e npm vengono salvate sul server? No. Sono salvate cifrate in Vimonto Deploy e passate alla build solo mentre un deploy è in corso, tramite `COMPOSER_AUTH` e una configurazione npm temporanea che viene rimossa subito dopo. Sul server non c'è nessun `auth.json` o `.npmrc`. ### Perché il mio hook di deploy non ha ricevuto nessuna richiesta? Clicca su **Prova l'hook di deploy** per vedere se il tuo endpoint risponde con uno stato di successo. Controlla che l'URL sia HTTPS, raggiungibile da internet e senza redirect: i redirect non vengono seguiti. ### Posso attivare l'isolamento per un sito esistente? No. L'isolamento si sceglie quando il sito viene creato. Crea un nuovo sito isolato sullo stesso server e fai il deploy lì. **Clona sito** riprende l'isolamento così com'è: il clone di un sito senza isolamento non è isolato neanche lui.