Ospitare un'app Laravel: VPS, requisiti e deployment

Laravel è un framework applicativo PHP completo, non un insieme di pagine da caricare via FTP. Si aspetta un vero ambiente di esecuzione: un PHP recente, diverse estensioni, una directory di storage scrivibile, attività pianificate e — per qualsiasi cosa non banale — worker di coda in background. Ecco perché un hosting condiviso di base spesso ti ostacola, e perché un VPS è di solito la casa giusta per un'app Laravel. Questa guida copre ciò di cui il server ha davvero bisogno e percorre un deployment reale.

Perché un VPS si adatta a Laravel

L'hosting condiviso è costruito per «lasciare i file in una web root». Laravel vuole di più: accesso SSH per eseguire composer e artisan, la possibilità di puntare il web server alla directory public/, un processo di lunga durata per svuotare la coda e una voce cron per lo scheduler. Un VPS ti dà accesso root, RAM e CPU garantite e il controllo completo dello stack — esattamente ciò che richiedono queste esigenze. Anche una piattaforma gestita può funzionare, ma un VPS è la via di mezzo più flessibile una volta che un'app ha code, un database e una cache.

Requisiti del server

PHP ed estensioni

Esegui una versione di PHP attualmente supportata che corrisponda alla tua release di Laravel — consulta la documentazione del framework per il minimo esatto. Laravel ha bisogno di un set standard di estensioni PHP attivate; su un VPS Debian/Ubuntu si installano tipicamente insieme:

# Ubuntu/Debian: PHP-FPM + the extensions Laravel expects
sudo apt install -y php-fpm php-cli php-mbstring php-xml \
  php-bcmath php-curl php-mysql php-zip php-gd php-intl

# Composer (dependency manager)
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

I nomi esatti dei pacchetti variano a seconda della distribuzione, ma le estensioni da confermare sono mbstring, xml, bcmath, curl, il driver del database (pdo_mysql o pdo_pgsql), zip e openssl. Se ne manca una, di solito compare come un errore chiaro durante composer install o all'avvio.

Database, cache e backend della coda

La maggior parte delle app Laravel si abbina a MySQL/MariaDB o PostgreSQL. Per qualsiasi cosa che usi code, sessioni o caching su larga scala, aggiungi Redis — funge da cache veloce, archivio di sessioni e driver di coda in uno. Assicurati che il VPS abbia abbastanza RAM per il database e Redis accanto ai worker PHP-FPM; la memoria è la risorsa che più probabilmente esaurirai.

Permessi di storage

Laravel scrive in due directory, storage/ e bootstrap/cache/. L'utente del web server (spesso www-data) deve poterci scrivere, altrimenti otterrai errori di permessi che sembrano bug dell'applicazione:

sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R ug+rwX storage bootstrap/cache

Primo piano di uno schermo che mostra codice con evidenziazione della sintassi con funzioni e condizioni — Un deployment di Laravel è una sequenza di comandi ripetibile — installare le dipendenze, mettere in cache configurazione e route, eseguire le migrazioni — invece di caricare file a mano.

Percorso di deployment

1. Ottenere il codice e installare le dipendenze

Clona il repository sul server, poi installa le dipendenze di produzione. I flag qui sotto saltano i pacchetti di sviluppo e costruiscono un autoloader ottimizzato:

git clone https://github.com/you/your-app.git /var/www/app
cd /var/www/app
composer install --no-dev --optimize-autoloader

2. Configurare l'ambiente

Laravel legge la configurazione da un file .env che non viene mai versionato in git. Copia l'esempio, genera la chiave dell'applicazione e inserisci i valori reali:

cp .env.example .env
php artisan key:generate

Un .env di produzione minimo si presenta così — imposta APP_DEBUG a false in modo che gli errori non vengano divulgati ai visitatori:

APP_NAME="Your App"
APP_ENV=production
APP_KEY=base64:...generated...
APP_DEBUG=false
APP_URL=https://yourapp.com

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=yourapp
DB_USERNAME=yourapp
DB_PASSWORD=change-me

CACHE_STORE=redis
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis
REDIS_HOST=127.0.0.1

3. Migrare e mettere in cache per la produzione

Esegui le migrazioni del database, poi costruisci la configurazione, le route e le view memorizzate in cache di Laravel. Mettere in cache questi elementi è ciò che rende veloce il framework in produzione — ma ricorda di ricostruirli a ogni deployment, poiché congelano lo stato corrente:

php artisan migrate --force

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

4. Puntare Nginx a public/

La document root del web server deve essere la directory public/ — mai la radice del progetto, altrimenti esporresti .env e i file sorgente. Un blocco server Nginx + PHP-FPM standard:

server {
    listen 80;
    server_name yourapp.com;
    root /var/www/app/public;

    index index.php;
    charset utf-8;

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

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Aggiungi l'HTTPS con un certificato automatizzato gratuito (la maggior parte degli hosting e strumenti come Certbot lo riducono a una sola riga) — un'app di produzione dovrebbe sempre essere servita su TLS.

5. Eseguire il worker di coda con Supervisor

I lavori in background (email, notifiche, esportazioni) vengono eseguiti tramite un worker di coda, un processo di lunga durata che deve sopravvivere a crash e riavvii. Non eseguire php artisan queue:work a mano in una sessione SSH — usa un gestore di processi come Supervisor per tenerlo in vita:

# /etc/supervisor/conf.d/app-worker.conf
[program:app-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/worker.log
stopwaitsecs=3600

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start app-worker:*

6. Pianificare lo scheduler

Lo scheduler delle attività di Laravel è guidato da un'unica voce cron che viene eseguita ogni minuto; è Laravel stesso a decidere quali attività sono dovute. Aggiungila al crontab dell'utente di deployment:

* * * * * cd /var/www/app && php artisan schedule:run >> /dev/null 2>&1

Dimensionare il VPS

Profilo dell'app	Di cosa ha bisogno
App piccola, traffico leggero	VPS di base: un paio di GB di RAM, storage NVMe, 1–2 vCPU — PHP-FPM più un piccolo database.
Code + Redis + database	Più margine di RAM affinché Redis, il database e diversi processi PHP-FPM e worker coesistano comodamente.
Traffico più elevato / lavori pesanti	vCPU dedicate per un carico costante, più processi worker, spazio per scalare; valuta di separare il database in seguito.

A chi si rivolge

Preferisce non gestire un server: una piattaforma gestita o un VPS gestito si occupa del patching e della supervisione dei processi al posto tuo, a un prezzo più alto.
A proprio agio con la riga di comando: un VPS non gestito è più economico e del tutto flessibile — sei tu il proprietario della configurazione di PHP, Nginx, Supervisor e cron mostrata sopra.
App in crescita con code e cache: un VPS con RAM/CPU garantite e Redis è la scelta naturale; dimensiona prima la memoria, poi la CPU, poi lo storage.

Come decidere

Parti da ciò di cui Laravel ha bisogno per funzionare bene: accesso SSH, un PHP supportato con le estensioni giuste, un database e (per code/cache) Redis, storage scrivibile, un worker di coda sotto Supervisor e un cron di una riga per lo scheduler. Un VPS ti dà tutto questo con risorse garantite e un percorso chiaro per scalare — fai corrispondere il piano al tuo traffico e al carico dei lavori in background, e scegli il più piccolo che lo copra con margine.