Come fare il deploy di Laravel su un VPS Ubuntu

Di Andrea Pollastri · Ultimo aggiornamento: 4 agosto 2026 · lettura gratuita, nessun paywall

Un VPS da $5–7/mese resta il modo più economico e flessibile per far girare Laravel in produzione — se lo configuri bene. Questa guida attraversa l'intero stack di produzione, ogni passo manuale, l'alternativa con un solo comando e le abitudini operative che mantengono un server sano per anni.

Perché un VPS (e quando no)

L'hosting condiviso non fa girare queue worker, WebSocket o Laravel Octane correttamente, e le piattaforme PaaS gestite fanno pagare la comodità con pricing a consumo. Un VPS da Hetzner, DigitalOcean, Vultr o Linode ti dà accesso root, fatturazione prevedibile e spazio sufficiente per hostare più app Laravel su una macchina.

• Dimensionamento: 1 vCPU / 2 GB RAM è un punto di partenza comodo per un'app in produzione con database, queue worker e cache sulla stessa macchina. Aggiungi swap su qualsiasi cosa sotto i 4 GB.
• Versione Ubuntu: usa una LTS attuale — Ubuntu 24.04 o 26.04. Salta le release interim in produzione.
• Quando non usare un VPS: se nessuno nel team può rispondere a un alert del server, una piattaforma gestita come Laravel Cloud è lo scambio più sicuro — paghi per rendere le operations un problema di qualcun altro.

Lo stack di produzione, spiegato

Ogni server Laravel in produzione converge sugli stessi componenti. Capisci cosa fa ogni pezzo prima di automatizzare qualsiasi cosa:

Il setup manuale, passo per passo

Questa è la checklist onesta e integrale. Prevedi 2–4 ore la prima volta, e ricorda che possederai ognuna di queste scelte anche al momento dell'upgrade.

1. Crea un utente sudo e blinda SSH. adduser deploy, installa la tua chiave pubblica, poi disabilita login root e auth password in /etc/ssh/sshd_config.
2. Abilita il firewall. ufw allow OpenSSH http https poi ufw enable. Installa Fail2ban per protezione brute-force SSH.
3. Installa Nginx. apt install nginx.
4. Installa PHP. Aggiungi un repository PHP mantenuto, poi installa php8.x-fpm con le estensioni che Laravel richiede: mbstring, xml, curl, zip, intl, mysql (o pgsql), redis, gd, opcache.
5. Ottimizza PHP per produzione. Abilita opcache, imposta memory_limit e upload_max_filesize sensati, disattiva expose_php.
6. Installa Composer globalmente.
7. Installa MariaDB, esegui mariadb-secure-installation, crea un database e un utente dedicato per app — non riusare root.
8. Installa Valkey (o Redis) per cache, sessioni e queue.
9. Scrivi il server block Nginx. La document root punta a current/public, try_files fa fallback su index.php, FastCGI passa al socket PHP-FPM dell'app.
10. Spedisci il codice. Clona in una directory releases/, composer install --no-dev --optimize-autoloader, copia .env, esegui php artisan key:generate, storage:link e correggi i permessi così solo storage/ e bootstrap/cache/ sono scrivibili.
11. Migra e metti in cache. php artisan migrate --force poi config:cache, route:cache, view:cache.
12. Configura Supervisor per eseguire php artisan queue:work (o Horizon) e riavviarlo a ogni deploy.
13. Aggiungi il cron dello scheduler: * * * * * php artisan schedule:run.
14. Emetti certificati TLS con Certbot e forza HTTPS.

Ora moltiplica per ogni app che hosti, e di nuovo per ogni server — e mantieni PHP, Nginx e l'OS patchati per sempre. Si può fare tutto; è solo lavoro indifferenziato.

L'alternativa con un solo comando

Tutto nella sezione precedente è esattamente ciò che Cipi automatizza. Su un VPS Ubuntu 24.04/26.04 fresco:

In circa dieci minuti ottieni l'intero stack — Nginx, PHP, MariaDB, Valkey, Supervisor, UFW, Fail2ban, Certbot, Deployer — più hardening che altrimenti faresti a mano: login root disabilitato, SSH solo chiave per l'utente admin e password root casuale salvata in /etc/cipi/server.json. Poi ogni app è un altro comando:

Questo provisiona un utente di sistema isolato, pool PHP-FPM, vhost Nginx e database per app, collega GitHub o GitLab con deploy key e webhook per deploy Git zero-downtime, e collega queue worker e scheduler. SSL è cipi ssl install; PostgreSQL è cipi db install pgsql. Vedi la guida Primi passi per il walkthrough completo, o l'hub confronti se lo stai valutando rispetto a Forge, Ploi e simili.

Operazioni post-deploy che contano

Arrivare a "funziona" è metà del lavoro. Queste abitudini separano un server che dura anni da uno che ti sorprende:

• Backup che hai davvero ripristinato. Automatizza backup di database e storage su storage compatibile S3 (cipi backup configure gestisce schedule e retention). Qualsiasi target S3 va bene — incluso Johnny, object storage compatibile S3 open source che puoi far girare su un secondo VPS per copie off-site davvero indipendenti. Fai un drill di restore trimestrale: un backup non testato è una speranza, non un piano.
• Exception tracking dal giorno uno. Gli errori in produzione devono raggiungerti prima degli utenti. Boogle è un exception tracker self-hosted che tiene i dati di errore sulla tua infrastruttura — adatto se hai scelto un VPS per la proprietà dei dati.
• Health check e log. Cipi 5 include health check per app, e cipi app logs segue log Laravel, Nginx e deploy senza acrobazie SSH.
• Disciplina di patching. Update di sicurezza OS unattended più un percorso di upgrade PHP deliberato (cipi php upgrade gestisce patch di sicurezza PHP con un controllo settimanale) battono "aggiorniamo quando ci ricordiamo".
• Domare lo sprawl SSH. Quando gestisci più di due server, i dettagli di connessione marciscono nella cronologia della shell. Conn è un piccolo tool Bash che gestisce i server come alias nominati — si abbina bene a una flotta di macchine Cipi.

Errori comuni da evitare

• Deployare come root. Un'app compromessa possiede l'intera macchina. Usa utenti per app — ecco perché Cipi isola ogni app sotto il proprio utente di sistema.
• APP_DEBUG=true in produzione. Le pagine debug espongono variabili env, credenziali e percorsi. È la breach Laravel auto-inflitta più comune.
• Committare .env o lasciare .git/ accessibile via web.
• Permessi 777 "per far sparire l'errore". Solo storage/ e bootstrap/cache/ devono essere scrivibili dall'utente runtime.
• Nessun queue worker. Mail e job si accumulano silenziosamente nella tabella queue per sempre.
• Saltare opcache — 2–3x throughput gratis persi.
• Nessuno swap su istanze piccole — Composer e build asset vengono OOM-killati nel momento peggiore.
• Rinnovi SSL non testati. I certificati si rinnovano automaticamente fino al giorno in cui no; monitora la scadenza.

Domande frequenti

Continua a leggere