Un sito in Vimonto Deploy è un sito web o un'app su uno dei tuoi server, con il suo dominio, la sua configurazione Nginx, il suo codice, il suo .env e i suoi deploy. Lo crei da un preset di framework (Laravel, WordPress, Next.js e altri), che sceglie il runtime, la directory web, il comando di build e uno script di deploy adatto.
Quando crei un sito, Vimonto Deploy lo configura sul server, collega il suo repository e fa subito il deploy. Pochi minuti dopo il sito è online su un indirizzo on-deploy.link generato, ancora prima che tu abbia toccato il DNS.
Trova tutti i tuoi siti
La scheda Siti nella barra in alto elenca tutti i siti dell'organizzazione, su tutti i suoi server. Ogni riga mostra il dominio con l'icona del framework e, sotto, il server, il framework, la versione PHP e il branch. Deploy eseguito dice quanto tempo fa è stato fatto l'ultimo deploy del sito (oppure non ancora deployato), e Stato mostra se il sito è pronto o ancora occupato. Cerca per dominio, ordina per colonna e clicca su una riga per aprire il sito.
Se la tua organizzazione usa i team, vedi solo i siti sui server a cui hai accesso. La pagina Siti di un server elenca solo i siti su quel server.
Crea un nuovo sito
- Apri un server e vai alla sua pagina Siti.
- Clicca su Nuovo sito e scegli con cosa è costruito il sito, per esempio Laravel o WordPress.
- Compila il modulo (ogni campo è descritto più avanti) e clicca su Crea sito.
Nuovo sito nell'elenco Siti dell'organizzazione ha lo stesso menu di framework. Il modulo ti fa poi scegliere il server, e il suo link ← Siti riporta all'elenco dell'organizzazione invece che a quello del server.
I siti vanno su server che servono siti web: un app server o un web server. Un load balancer ospita solo siti con bilanciamento del carico (consulta bilanciamento del carico). Se non c'è ancora un server adatto, il modulo mostra Ancora nessun server per i siti e propone Nuovo server. Consulta i tipi di server per sapere cosa installa ciascun tipo.
Ti serve il permesso di gestire i siti nell'organizzazione; consulta membri e ruoli. Il piano gratuito include 3 siti su tutti i server dell'organizzazione insieme; quando sono usati, il modulo mostra Il tuo piano è pieno con Vedi i piani. Vedi fatturazione.
Quali framework puoi scegliere?
Il menu Nuovo sito raggruppa i preset per linguaggio. Ogni preset imposta il runtime (come Nginx serve il sito) e valori predefiniti sensati, che puoi cambiare in Impostazioni avanzate.
| Preset | Runtime | Directory web | Composer | Comando di build predefinito | Repository |
|---|---|---|---|---|---|
| Laravel | Laravel (PHP) | /public |
Sì | npm run build |
Sì |
| Symfony | PHP | /public |
Sì | nessuno | Sì |
| Statamic | Laravel (PHP) | /public |
Sì | npm run build |
Sì |
| WordPress | PHP | / |
No | nessuno | No, viene installato per te |
| phpMyAdmin | PHP | / |
No | nessuno | No, viene installato per te |
| PHP | PHP | /public |
Sì | nessuno | Sì |
| Next.js | Node.js | non usata | No | npm run build |
Sì |
| Nuxt | Node.js | non usata | No | npm run build |
Sì |
| HTML | Statico | / |
No | nessuno | Sì |
| Altro | PHP | / |
No | nessuno | Sì |
| Load balancer | Proxy verso i tuoi app server | non usata | No | nessuno | No |
Cosa significano i runtime:
- Laravel: PHP-FPM dietro Nginx, con lo
storage/di Laravel condiviso tra le release, queue worker e lo scheduler. - PHP: qualsiasi app PHP con un
index.php, come Symfony o WordPress. - Statico: HTML, oppure un frontend compilato in file (Vite, Astro, un export statico di Next.js).
- Node.js: un'app in ascolto su una porta; Nginx le inoltra le richieste.
Il preset Load balancer, sotto Bilanciamento del carico nel menu, è solo per i server load balancer ed è l'unico tipo di sito che ospitano. Non ha codice né deploy: inoltra le richieste ai tuoi app server. Il suo modulo non ha repository, database né Impostazioni avanzate, perché non c'è nulla da compilare o isolare. Consulta bilanciamento del carico.
WordPress e phpMyAdmin
WordPress e phpMyAdmin non hanno bisogno di un repository. Vimonto Deploy scarica l'ultima release sul server e ne scrive la configurazione:
- WordPress riceve un
wp-config.phpcon nome, utente e password del database, e chiavi e salt di sicurezza nuovi. WordPress ha sempre bisogno di un database, quindi Collega un database non si può disattivare. - phpMyAdmin riceve un
config.inc.phpche accede con autenticazione tramite cookie al server di database sulla stessa macchina.
Apri poi il sito per completare l'installazione di WordPress nel browser.
Compila il modulo
Server
Scegli il server su cui va il sito. Sono elencati, con il loro indirizzo IP, solo i server attivi che possono ospitare questo tipo di sito: app server e web server per ogni preset, load balancer solo per il preset Load balancer.
Codice sorgente, repository e branch
In Codice sorgente, scegli una delle tue connessioni Git (GitHub, GitLab o Bitbucket), oppure URL Git personalizzato.
- Con una connessione, scegli il Repository (eventualmente filtrato per Organizzazione) e il Branch.
- Con URL Git personalizzato, inserisci l'URL Git, come
git@github.com:you/project.gitohttps://github.com/you/project.git, e il Branch.
Il repository è facoltativo. Senza, il sito viene configurato con una pagina segnaposto e puoi collegare un repository in seguito dalla pagina Deployment.
Collega un database
Su un server con un database, Collega un database è attivo per impostazione predefinita, con un nuovo database che prende il nome dal sito (per esempio shop_example_com). Puoi:
- Cliccare su Modifica o Crea database per scegliere il nome, un Utente dedicato e una Password. Lascia vuoto l'utente per usare l'utente di database del server. Lascia vuota la password e ne viene generata una.
- Scegliere un database esistente dall'elenco. Il sito riceve allora un utente di database dedicato, così non condivide mai una password con un altro sito.
Per i siti Laravel e Statamic, nome, utente e password del database vengono scritti nel .env del sito. Consulta database per gestirli in seguito.
Dominio o indirizzo generato
Ogni sito può avere un indirizzo gratuito su on-deploy.link, come kalme-rivier-4821.on-deploy.link. Puoi cambiare la prima parte del nome nel campo Indirizzo on-deploy.link. Funziona subito, senza alcun DNS tuo, quindi è comodo per fare test e condividere. Un sito che gira su questo indirizzo riceve anche HTTPS da solo (vedi più avanti).
Per usare un tuo dominio, clicca su Usa un dominio personalizzato e inseriscilo, per esempio shop.example.com. Lascia selezionato Anche …on-deploy.link se il sito deve rispondere anche sull'indirizzo generato.
Poi il dominio ha bisogno di record DNS che puntino al server. Con le integrazioni DNS, il suggerimento sotto il dominio dice "Cerchiamo il dominio presso i tuoi provider DNS e impostiamo i suoi record automaticamente." Mentre digiti, un riquadro DNS mostra se una delle tue integrazioni (Hetzner Cloud, DigitalOcean, Vultr, Akamai, AWS, Google Cloud o Cloudflare) lo gestisce; i loro elenchi di domini vengono recuperati in tempo reale:
- In tal caso è scelto Puntalo automaticamente con …. Il riquadro elenca i record (un record A per il dominio e un CNAME per
www.) come Nuovo, Già corretto o Modifiche, con un avviso per tutto ciò che cambia o viene rimosso. Se cambiano record esistenti, spunta Modifica questi record. Dopo la configurazione, Vimonto Deploy aggiorna i record, aspetta che il dominio si risolva e richiede HTTPS da solo. Scegli Gestisco il DNS da solo per non toccare il DNS. - Se nessuna lo gestisce ma hai integrazioni DNS, attiva Aggiungi il dominio a un provider DNS e scegli il Provider e la Zona (per impostazione predefinita il dominio senza il sottodominio, come
example.com). Vimonto Deploy crea lì la zona, imposta i record e nell'output del task elenca i nameserver da impostare presso il tuo registrar; HTTPS arriva quando il DNS si risolve. - Altrimenti fai puntare tu il dominio all'indirizzo IP del server con un record A presso il tuo provider DNS.
Consulta domini e SSL per il significato di ogni avviso.
Puoi aggiungere altri domini, disattivare l'indirizzo generato e attivare HTTPS in seguito; consulta domini e SSL.
Installa i pacchetti Composer
Per i siti Laravel, Symfony, Statamic e PHP con un repository, Installa i pacchetti Composer aggiunge composer install allo script di deploy. Disattivalo se il tuo progetto non ha un composer.json o installa i pacchetti in un altro modo.
Deploy key dedicata
Con Deploy key dedicata per GitHub (oppure GitLab, Bitbucket; Deploy key dedicata per il tuo host Git con un URL Git personalizzato) attiva, l'impostazione predefinita, il sito riceve una chiave SSH tutta sua per il repository. Con un Git host collegato, Vimonto Deploy la registra sul repository come deploy key di sola lettura. Con un URL Git personalizzato, copi la chiave dalla pagina Deployment e la aggiungi tu al tuo Git host.
Un repository di un Git host collegato riceve anche Deploy a ogni push attivato: Vimonto Deploy aggiunge un webhook e ogni push sul branch fa partire un deploy. Puoi disattivarlo nella pagina Deployment.
Impostazioni avanzate
Clicca su Impostazioni avanzate per cambiare i valori predefiniti del preset. Clicca su Salva impostazioni per mantenerli.
| Impostazione | Cosa fa |
|---|---|
| Directory root | Dove si trova l'app nel repository. / è l'intero repository; usa /backend o simili per un monorepo. |
| Directory web | Cosa serve Nginx, all'interno della directory root, come /public o /dist. Non viene mostrata per i siti Node.js. |
| Versione PHP | Una delle versioni PHP installate sul server. Consulta PHP. |
| Package manager frontend | npm (predefinito), yarn, pnpm o bun. Yarn e pnpm girano tramite Corepack. |
| Comando di build | Viene eseguito dopo l'installazione dei pacchetti, come npm run build. Vuoto: non compila nulla. |
| Isolamento del sito | Dà al sito un utente Linux dedicato, con un Nome utente a tua scelta. |
| Deploy zero-downtime | Compila ogni deploy in una nuova release e passa a quella solo se è riuscito. Attivo per impostazione predefinita. |
| Autenticazione Composer | Host, nome utente e password o token per pacchetti Composer privati, come repo.packagist.com. |
| Autenticazione npm | Registry e token per un registry npm privato, come https://npm.pkg.github.com. |
Deploy di un monorepo
Imposta la Directory root sulla cartella dell'app, per esempio /backend. Viene clonato l'intero repository, ma lo script di deploy gira in quella cartella, il .env viene collegato lì e la directory web viene cercata al suo interno. Un deploy fallisce con un messaggio chiaro se la cartella non è nel repository.
Isolamento del sito
Un sito isolato gira con un proprio utente Linux, con una home directory che gli altri siti non possono leggere. Un sito PHP riceve anche un proprio pool PHP-FPM che gira con quell'utente. Nginx può comunque servire i file perché l'utente di sistema del server entra nel gruppo del sito. Usalo quando più clienti o progetti condividono un server.
L'utente si sceglie quando crei il sito. Il nome deve contenere solo lettere minuscole, numeri, _ e -, iniziare con una lettera e non essere un nome di sistema come root o www-data.
Deploy zero-downtime
Con i deploy zero-downtime, ogni deploy viene compilato in una nuova directory di release e va live con un unico passaggio atomico, così i visitatori non vedono mai un sito costruito a metà e puoi fare rollback. Se li disattivi, un'unica release viene aggiornata sul posto: è più veloce, ma i visitatori possono vedere la build in corso e non c'è rollback. Puoi cambiarlo in seguito nelle impostazioni del sito. Consulta deployment per i dettagli.
Pacchetti Composer e npm privati
Le credenziali in Autenticazione Composer e Autenticazione npm sono salvate cifrate e usate solo durante la build: Composer le legge da COMPOSER_AUTH, npm da un file di configurazione temporaneo che viene rimosso subito dopo. Puoi aggiungerle, modificarle o rimuoverle in seguito nelle Impostazioni del sito, nelle schede Composer e npm: vedi credenziali per Composer e npm.
Cosa succede dopo aver cliccato su Crea sito?
Arrivi sulla pagina del sito, che finché il sito non è live mostra solo la configurazione: le fasi, il passaggio in esecuzione e il log di ogni task. Puoi lasciare la pagina in qualsiasi momento; il lavoro prosegue in background.
- Configura: Vimonto Deploy crea il record DNS per l'indirizzo generato, crea il database e il suo utente, crea le directory del sito e scrive il
.env, il pool PHP-FPM (se isolato) e la configurazione Nginx. Fino al primo deploy, il sito mostra una pagina che dice che è pronto. WordPress e phpMyAdmin vengono installati in questa fase. - Collega: con un repository, la deploy key viene messa sul server e, con un Git host collegato, registrata sul repository insieme al webhook per i push.
- Recupera, Build, Live: il primo deploy clona il branch, esegue lo script di deploy e mette live la release.
- HTTPS: per un sito il cui indirizzo è l'indirizzo
on-deploy.linkgenerato, e per un sito su un tuo dominio che un'integrazione DNS fa puntare. Per un tuo dominio, Vimonto Deploy aggiorna prima i record DNS come mostrava il piano. Poi aspetta che il nome punti al server (al massimo 10 minuti), richiede un certificato Let's Encrypt gratuito e passa il sito a HTTPS. Questa fase gira insieme al primo deploy ed è l'ultima mostrata. Se fallisce, il sito continua a funzionare su HTTP; richiedi un certificato in seguito in domini e SSL.
Un sito creato con un tuo dominio di cui gestisci tu il DNS salta la fase HTTPS, perché il suo DNS potrebbe non puntare ancora al server. Richiedi il suo certificato quando lo fa.
Mentre la configurazione è in corso (configurazione, collegamento del repository, primo deploy e primo certificato HTTPS), questa panoramica con i suoi passaggi è l'unica pagina del sito, insieme al log del primo deploy: non c'è la barra laterale, e le altre pagine del sito riportano qui.
Quando tutto è finito, la pagina diventa la normale panoramica del sito con la sua barra laterale. La prima volta che tu (o chiunque altro nell'organizzazione) la apri dopo, inizia con Il tuo sito è live, quanto è durata la configurazione e un pulsante Apri; Chiudi la nasconde, e le visite successive mostrano solo la panoramica.
Su disco, ogni sito si trova in /home/{user}/{domain}, con releases/, shared/ e un symlink current. La directory mantiene il suo nome quando in seguito cambi il dominio del sito.
Se una fase fallisce, la pagina mostra Configurazione non riuscita, Collegamento del repository non riuscito o Primo deploy non riuscito, con l'errore e il log del passaggio non riuscito (in Dettagli e log). Risolvi la causa (il nome di un branch, una deploy key mancante) e usa il pulsante nella pagina: Riprova, Collega di nuovo o Rifai il deploy. Quando una fase non è riuscita, la barra laterale e tutte le pagine del sito tornano, così puoi risolvere la causa nelle pagine Deployment e Ambiente.
Cosa fare dopo
- Per un sito su un tuo dominio di cui gestisci tu il DNS, attiva HTTPS con un certificato Let's Encrypt gratuito in domini e SSL.
- Controlla il
.envin ambiente. - Per Laravel, aggiungi queue worker e lo scheduler in queue e scheduler, oppure attiva Horizon dal menu delle funzionalità del sito.
- Con un URL Git personalizzato, chiama l'URL di deploy dal tuo Git host o dalla CI per fare il deploy a ogni push.
Domande frequenti
Mi serve un dominio per creare un sito?
No. Ogni sito può avere un indirizzo on-deploy.link generato che funziona subito. Aggiungi il tuo dominio quando sei pronto.
Posso ospitare più siti su un solo server?
Sì. Un server può ospitare tutti i siti per cui ha spazio. Ogni sito ha la sua configurazione Nginx e la sua directory; attiva l'isolamento del sito per dare a ciascuno anche un proprio utente Linux.
Quale repository usa WordPress?
Nessuno. WordPress e phpMyAdmin vengono scaricati e installati sul server quando crei il sito. Se tieni un progetto WordPress in Git, scegli invece il preset PHP e collega il tuo repository.
Come faccio il deploy di un'app Next.js o Nuxt?
Scegli Next.js o Nuxt. Il sito riceve una porta locale libera (da 3000 in su) verso cui Nginx inoltra le richieste, e lo script di deploy installa i pacchetti ed esegue npm run build. Vimonto Deploy aggiunge anche il processo che esegue la tua app su quella porta, e il primo deploy lo avvia. Lo trovi in Processi.
Posso distribuire un sito su più server?
Sì, con un server load balancer davanti a due o più app server che eseguono ciascuno lo stesso sito. Consulta bilanciamento del carico.
Posso cambiare il framework in seguito?
No, il preset si sceglie quando crei il sito. La versione PHP, la directory web, la porta Node.js e i deploy zero-downtime si possono cambiare nelle impostazioni del sito, e lo script di deploy nella pagina Deployment.
Posso copiare un sito esistente?
Sì. Nelle Impostazioni del sito, clicca su Clona sito per creare un nuovo sito con lo stesso repository, le stesse impostazioni di build, lo stesso script di deploy e le stesse regole, sullo stesso server o su un altro. Vedi clonare un sito.