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 e Elimina sito | Ogni sito |
| Composer | Credenziali per pacchetti Composer privati | Siti Laravel, Symfony, Statamic e PHP |
| npm | Token per registry npm privati | Siti con un repository |
| Notifiche | Email per deploy non riusciti e un hook 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.
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:
/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 | 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 | Sì |
| Repository e branch | Deployment | 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). 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, da cui lo gestisci. Elimina sito c'è, come per ogni 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 del server.
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) 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.
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; 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.
Aggiungere credenziali Composer
- Apri le Impostazioni del sito e clicca sulla scheda Composer (Autenticazione dei pacchetti Composer).
- Clicca su Aggiungi credenziali.
- Compila l'Host (per esempio
repo.packagist.comonova.laravel.com), il Nome utente e la Password. Anche un token o una chiave di licenza va in Password. - 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
- Clicca sulla scheda npm (Autenticazione dei pacchetti npm).
- Clicca su Aggiungi credenziali.
- Compila il Registry, un indirizzo
https://comehttps://npm.pkg.github.comohttps://registry.npmjs.org, e il Token. - 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. Nella scheda Notifiche invii i risultati dei deploy di un sito ad altri destinatari: indirizzi email esterni all'organizzazione e un tuo endpoint.
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.
{
"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.
- Nella scheda Generale, in Clona sito, clicca su Clona sito.
- Scegli il Server. Puoi scegliere ogni server attivo a cui hai accesso, tranne i load balancer.
- 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.
- un Indirizzo su
- Lascia attivo Copia il .env per dare al clone una copia del
.envdi questo sito (visibile quando il sito ne ha uno). - Clicca su Clona sito.
Vieni portato al nuovo sito mentre viene configurato, come per un nuovo 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 |
| 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 e regole di sicurezza | |
| 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 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
- In fondo alla pagina Impostazioni, sotto Elimina sito, fai clic su Elimina sito.
- 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
.enveshared/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 (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 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.
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.
Domande frequenti
Come cambio il dominio di un sito?
Nella pagina Domini e SSL del sito. La directory del sito sul server non cambia di conseguenza.
Come collego un altro repository o branch?
Nella pagina Deployment 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, 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.