1 03/05/2026 10 min

Stack di riferimento: Ubuntu 22.04, Nginx, PHP-FPM e database

Per installare Laravel su Ubuntu 22.04 LTS in modo sensato, conviene partire da una scelta architetturale semplice: Nginx come web server, PHP-FPM per l’esecuzione del codice PHP e un database MySQL o MariaDB. È la combinazione più lineare da mantenere, soprattutto quando l’obiettivo è avere un ambiente pulito, aggiornabile e con pochi punti di attrito.

La sequenza corretta non è “installo Laravel e poi vedo cosa manca”. Prima si prepara il sistema, poi si verifica che PHP abbia le estensioni richieste, quindi si crea il progetto, si imposta il virtual host e solo alla fine si rifiniscono permessi, cache e hardening minimo. Saltare un passaggio qui significa quasi sempre perdere tempo dopo, spesso su problemi banali come permessi errati, extension mancanti o document root sbagliata.

Prerequisiti pratici prima di toccare Composer

Su Ubuntu 22.04 il punto di partenza è aggiornare il sistema e installare i pacchetti base. Se il server è appena creato, controlla anche che l’orario sia corretto: TLS, repository e alcuni job schedulati dipendono da una clock decente.

Comandi iniziali:

sudo apt update
sudo apt -y upgrade
sudo apt -y install ca-certificates curl unzip git software-properties-common

Per verificare rapidamente lo stato del sistema:

lsb_release -a
timedatectl status

Se il server è esposto in produzione, considera da subito il blast radius: ogni modifica a PHP, Nginx o al database può impattare il sito. Per questo conviene lavorare con un backup della configurazione e, se possibile, con una finestra di manutenzione o almeno con un piano di rollback chiaro.

Installare Nginx, PHP-FPM e le estensioni Laravel

Laravel richiede una versione PHP compatibile con la release del framework che vuoi usare. Su Ubuntu 22.04 il repository ufficiale offre PHP 8.1, che è una base comune e stabile. Se ti serve una versione più recente, puoi usare un PPA o un repository esterno, ma lì il rischio operativo sale: cambia il canale di aggiornamento e devi sapere esattamente cosa stai mantenendo.

Installazione base:

sudo apt -y install nginx php-fpm php-cli php-mbstring php-xml php-curl php-zip php-bcmath php-intl php-mysql php-gd

Dopo l’installazione, verifica che PHP-FPM sia attivo:

systemctl status php8.1-fpm --no-pager
systemctl status nginx --no-pager

Se il servizio non parte, l’ordine giusto è leggere i log prima di cambiare qualcosa:

journalctl -u php8.1-fpm -n 50 --no-pager
journalctl -u nginx -n 50 --no-pager

Questo evita il classico errore di correggere il sintomo invece della causa. Se manca una estensione, il log la segnala con precisione; se il problema è una direttiva Nginx, lo vedi nel test di configurazione.

Composer: il punto in cui molti ambienti si sporcano

Composer è il gestore dipendenze di Laravel e va installato in modo verificabile, non “scaricato a mano e basta”. Il punto importante è controllare integrità e percorso. In produzione o su server condivisi, evita di lasciare binari opachi in directory casuali.

Installazione consigliata:

cd /tmp
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php')) { echo 'installer downloaded'; }"
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
php -r "unlink('composer-setup.php');"
composer --version

Qui c’è un dettaglio operativo spesso ignorato: se Composer finisce sotto l’utente sbagliato, poi gli update falliscono o richiedono escalation inutile. In un ambiente ordinato, Composer globale resta per l’amministratore, mentre le dipendenze del progetto si gestiscono dentro la directory applicativa con l’utente dedicato al deploy.

Creare il progetto Laravel e verificare il requisito PHP

Una volta che PHP e Composer sono disponibili, si può creare il progetto. Se stai partendo da zero, usa una directory dedicata sotto `/var/www` e un utente di servizio coerente. Il motivo è semplice: separare il codice dai profili personali evita problemi di permessi e rende più lineare qualsiasi automazione futura.

Creazione progetto:

sudo mkdir -p /var/www/laravel-app
sudo chown -R $USER:$USER /var/www/laravel-app
cd /var/www/laravel-app
composer create-project laravel/laravel .

Se il progetto è già stato clonato da Git, il controllo minimo è questo:

php artisan --version
php -v
composer check-platform-reqs

Il comando composer check-platform-reqs è utile perché ti dice subito se il sistema soddisfa i vincoli del progetto. È il modo più rapido per distinguere un errore di codice da un ambiente incompleto.

Database: MySQL o MariaDB, ma con credenziali pulite

Laravel funziona bene con MySQL e MariaDB. La scelta operativa dipende da standard interni e da compatibilità già presenti. L’importante è non usare l’account root del database nell’applicazione: è una scorciatoia che poi si paga in sicurezza e audit.

Installazione MySQL su Ubuntu 22.04:

sudo apt -y install mysql-server
sudo systemctl enable --now mysql
sudo mysql_secure_installation

Creazione database e utente applicativo:

sudo mysql
CREATE DATABASE laravel_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'laravel_user'@'localhost' IDENTIFIED BY 'password_strong_da_ruotare';
GRANT ALL PRIVILEGES ON laravel_db.* TO 'laravel_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

La password qui è mostrata solo come esempio tecnico: in un ambiente reale va generata, conservata in un secret manager o in un file con permessi stretti, e non lasciata in chiaro in ticket, chat o repository.

Configurare `.env` senza lasciare appoggi fragili

Il file `.env` è il punto in cui Laravel legge la configurazione runtime. È anche il posto in cui si fanno più danni, perché spesso viene trattato come file “temporaneo” invece che come asset sensibile. Va protetto con permessi corretti e gestito come configurazione, non come documento da copiare in giro.

Impostazioni minime rilevanti:

APP_NAME=Laravel
APP_ENV=production
APP_KEY=
APP_DEBUG=false
APP_URL=https://example.com

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel_db
DB_USERNAME=laravel_user
DB_PASSWORD=

Dopo aver creato il progetto, genera la chiave applicativa:

php artisan key:generate

Controlla che il file `.env` non sia leggibile da utenti non autorizzati. Una verifica semplice è questa:

ls -l .env

In un setup ragionevole, il file deve essere accessibile solo all’utente che gestisce il deploy e al processo che ne ha necessità. Se il web server può leggere più del necessario, stai allargando la superficie d’attacco senza motivo.

Nginx virtual host: document root corretto e routing Laravel

Con Laravel la document root deve puntare a `public/`, non alla root del progetto. Questo è il passaggio che separa una configurazione corretta da una configurazione che espone file interni o genera errori di routing. Se la root è sbagliata, il problema non è “Laravel che non va”, ma il web server che serve il posto sbagliato.

Esempio di configurazione Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/laravel-app/public;
    index index.php index.html;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

Salva il file in `/etc/nginx/sites-available/laravel-app`, poi abilitalo con un link simbolico:

sudo ln -s /etc/nginx/sites-available/laravel-app /etc/nginx/sites-enabled/

Prima del reload, testa la sintassi:

sudo nginx -t

Se il test fallisce, non fare reload a tentativi. Correggi il file, retesta e solo dopo riavvia o ricarica il servizio:

sudo systemctl reload nginx

Permessi: il punto più noioso, ma anche il più costoso quando è sbagliato

Laravel deve poter scrivere in directory specifiche come `storage/` e `bootstrap/cache/`. Il resto del codice non dovrebbe essere scrivibile dal web server. Questa distinzione è utile sia per la sicurezza sia per la manutenzione: se tutto è scrivibile da tutti, un errore applicativo o un upload mal gestito diventa un problema più grosso del necessario.

Impostazione base suggerita:

sudo chown -R www-data:www-data /var/www/laravel-app
sudo find /var/www/laravel-app -type f -exec chmod 644 {} \;
sudo find /var/www/laravel-app -type d -exec chmod 755 {} \;
sudo chmod -R ug+rwx /var/www/laravel-app/storage /var/www/laravel-app/bootstrap/cache

Qui serve una nota pratica: in ambienti con deploy automatizzati conviene separare il proprietario del codice da quello del runtime. La regola “tutto a www-data” funziona per un laboratorio, ma in produzione può diventare poco elegante. Se il deploy viene eseguito da un utente dedicato, valuta ACL o gruppi condivisi invece di permission broad-brush.

Cache, migrazioni e ottimizzazioni sensate dopo il primo avvio

Dopo aver reso raggiungibile l’app, esegui le operazioni Laravel di base. L’ordine corretto è importante: prima verifica la connessione al database, poi lancia le migrazioni, infine lavora su cache e ottimizzazioni. Se fai il contrario, rischi di confondere un errore di schema con un problema di configurazione.

Comandi utili:

php artisan migrate
php artisan config:cache
php artisan route:cache
php artisan view:cache

Se qualcosa fallisce, il primo controllo è leggere il log applicativo:

tail -n 50 storage/logs/laravel.log

Un errore frequente è trovare un problema di permessi mascherato da eccezione generica. In quel caso il log chiarisce subito se Laravel non riesce a scrivere nella cache, nei log o nei file temporanei.

Verifica finale: cosa deve funzionare davvero

La verifica finale non è “il browser mostra una pagina”, ma una serie di controlli coerenti. Devi confermare che il web server risponda, che PHP-FPM esegua i file PHP, che il database sia raggiungibile e che Laravel non produca errori di runtime.

Controlli essenziali:

curl -I http://localhost
php artisan about
php artisan route:list | head
systemctl status nginx --no-pager
systemctl status php8.1-fpm --no-pager

Se usi HTTPS, aggiungi anche la verifica del certificato e del virtual host. Un sito che risponde in HTTP ma non in TLS non è “quasi pronto”: è incompleto. In produzione l’ordine naturale è terminare il setup con certificato valido, redirect verso HTTPS e controllo della catena di trust.

Problemi tipici e lettura rapida della causa

Se compare una pagina bianca o un errore 500, i sospetti iniziali sono sempre pochi: permessi errati, estensione PHP mancante, `.env` incoerente, database non raggiungibile o configurazione Nginx sbagliata. La falsificazione rapida si fa così: controlli il log Laravel, il log di PHP-FPM, il test di Nginx e la reachability del database.

Esempi di controlli rapidi:

php -m | grep -E 'mbstring|xml|curl|zip|bcmath|intl|mysql'
sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 storage/logs/laravel.log
mysql -u laravel_user -p -h 127.0.0.1 laravel_db

Se il database risponde ma Laravel no, il problema è quasi sempre nella stringa di connessione o nei permessi del progetto. Se Nginx risponde con 502, di solito il collo di bottiglia è PHP-FPM. Se vedi 403, controlla root, index e permessi sulla directory `public/`.

Hardening minimo che vale la pena fare subito

Una installazione Laravel non dovrebbe restare “aperta” oltre il necessario. Il minimo da fare è limitare l’esposizione, tenere `APP_DEBUG=false` in produzione, proteggere il file `.env`, aggiornare regolarmente il sistema e non lasciare servizi inutili in ascolto. Il resto dipende dal contesto: CDN, WAF, backup, separazione dei ruoli e auditing dei log.

In pratica, tieni sotto controllo almeno questi punti:

  • solo i servizi necessari devono essere attivi;
  • il web root deve essere `public/`;
  • i secret non devono finire nel repository;
  • i log devono essere ruotati e leggibili solo da chi serve;
  • gli update di sistema vanno pianificati, non improvvisati.

Questo approccio tiene basso il rischio operativo senza introdurre complessità inutile. Laravel funziona bene su Ubuntu 22.04 proprio quando l’ambiente è semplice, ripetibile e documentato. Se devi ricordarti una sola cosa: il framework è la parte facile; il vero lavoro è mettere in ordine sistema, permessi e configurazione web.