Hosting WordPress su VPS - guida completa Ubuntu 24.04

26 settembre 2026 · lettura 7 min · Koapanel

Ospitare WordPress su una VPS conviene quando vuoi prestazioni prevedibili e controllo totale: per un sito medio bastano 2 vCPU e 2-4 GB di RAM con lo stack nginx + PHP-FPM + MariaDB + Redis, HTTPS, backup esterni e aggiornamenti controllati. Puoi configurare tutto a mano (in questa guida trovi i comandi per Ubuntu 24.04) oppure usare un pannello di controllo che lo fa per te. Il lavoro vero non è l'installazione, ma la manutenzione dei mesi successivi.

VPS, hosting condiviso o WordPress gestito?

Se hai un solo sito piccolo e non vuoi pensare al server, un buon WordPress gestito resta la scelta più comoda. La VPS diventa interessante quando hai più siti, un e-commerce che rallenta sull'hosting condiviso, o clienti da ospitare: il costo è per server, non per sito.

Quanto deve essere grande la VPS

Indicazioni di partenza, da verificare con il traffico reale:

Con la cache delle pagine la CPU lavora poco per i visitatori anonimi; a consumare sono utenti collegati, carrello, checkout e area admin, che non si possono mettere in cache. Se ospiti anche la posta con antispam e antivirus, aggiungi 1-2 GB di RAM.

Lo stack consigliato

• nginx: serve file statici e pagine in cache in modo molto efficiente. Non legge i file .htaccess: le regole vanno scritte nella configurazione del sito.
• PHP-FPM 8.3: la versione inclusa in Ubuntu 24.04 e quella raccomandata dai requisiti ufficiali di WordPress. Un pool separato per ogni sito, con il suo utente di sistema, isola i siti tra loro.
• MariaDB 10.11: anche questa è la versione minima raccomandata da WordPress.
• Redis: cache degli oggetti, riduce le query al database.
• OPcache: tiene in memoria il codice PHP già compilato.

Installazione manuale su Ubuntu 24.04

Negli esempi il dominio è esempio.it e l'utente di sistema del sito è esempio. Parti da una VPS aggiornata (sudo apt update && sudo apt -y full-upgrade).

1. Pacchetti

sudo apt install -y nginx mariadb-server redis-server unzip \
php8.3-fpm php8.3-cli php8.3-mysql php8.3-curl php8.3-gd php8.3-mbstring \
php8.3-xml php8.3-zip php8.3-intl php8.3-bcmath php8.3-opcache \
php-imagick php-redis certbot python3-certbot-nginx

2. Utente del sito e pool PHP-FPM dedicato

sudo useradd -m -d /var/www/esempio.it -s /usr/sbin/nologin esempio
sudo chmod 750 /var/www/esempio.it
sudo usermod -aG esempio www-data
sudo -u esempio mkdir /var/www/esempio.it/public_html

Crea /etc/php/8.3/fpm/pool.d/esempio.conf:

[esempio]
user = esempio
group = esempio
listen = /run/php/esempio.sock
listen.owner = www-data
listen.group = www-data
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 30s
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M

sudo systemctl restart php8.3-fpm

3. Database

Su Ubuntu l'utente root di MariaDB entra tramite socket, senza password. Crea database e utente dedicati:

sudo mariadb <<'SQL'
CREATE DATABASE wp_esempio CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_esempio'@'localhost' IDENTIFIED BY 'una-password-lunga-e-casuale';
GRANT ALL PRIVILEGES ON wp_esempio.* TO 'wp_esempio'@'localhost';
FLUSH PRIVILEGES;
SQL

4. Configurazione nginx

Crea /etc/nginx/conf.d/wp-login-limit.conf con una riga che limita i tentativi di login:

limit_req_zone $binary_remote_addr zone=wplogin:10m rate=10r/m;

Poi /etc/nginx/sites-available/esempio.it:

server {
listen 80;
listen [::]:80;
server_name esempio.it www.esempio.it;
root /var/www/esempio.it/public_html;
index index.php;
client_max_body_size 64m;
location = /xmlrpc.php { deny all; }
location ~* /wp-content/uploads/.*\.php$ { deny all; }
location ~ /\.(?!well-known) { deny all; }
location = /wp-login.php {
limit_req zone=wplogin burst=5 nodelay;
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/esempio.sock;
}
location / { try_files $uri $uri/ /index.php?$args; }
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/esempio.sock;
}
}

Le regole di blocco stanno prima di \.php$ perché nginx usa la prima espressione regolare che corrisponde. Attiva il sito e richiedi il certificato (il dominio deve già puntare alla VPS):

sudo ln -s /etc/nginx/sites-available/esempio.it /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d esempio.it -d www.esempio.it

Certbot aggiunge il blocco HTTPS, il reindirizzamento da HTTP e il rinnovo automatico.

5. WordPress con WP-CLI

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
W="sudo -u esempio wp --path=/var/www/esempio.it/public_html"
$W core download --locale=it_IT
$W config create --dbname=wp_esempio --dbuser=wp_esempio --prompt=dbpass
$W core install --url=https://esempio.it --title="Il mio sito" \
--admin_user=mario --admin_email=mario@esempio.it

Con --prompt=dbpass la password del database non finisce nella cronologia della shell; senza --admin_password, WP-CLI genera una password e la stampa una volta. Evita admin come nome utente: è il primo che provano i bot.

6. Redis, WP-Cron e protezioni

Limita la memoria di Redis in /etc/redis/redis.conf (maxmemory 128mb e maxmemory-policy allkeys-lru), riavvialo con sudo systemctl restart redis-server, poi:

$W config set WP_REDIS_PREFIX esempio:
$W plugin install redis-cache --activate
$W redis enable
$W config set DISALLOW_FILE_EDIT true --raw
$W config set DISABLE_WP_CRON true --raw
echo '*/5 * * * * /usr/local/bin/wp --path=/var/www/esempio.it/public_html cron event run --due-now --quiet' | sudo crontab -u esempio -

Il prefisso evita che più siti sullo stesso Redis si mescolino le chiavi. WP-Cron sul cron di sistema fa girare gli eventi programmati anche senza visite.

Sicurezza

• Firewall: apri solo SSH, 80 e 443 (sudo ufw allow OpenSSH, sudo ufw allow 'Nginx Full', sudo ufw enable).
• SSH con chiave e login con password disattivato.
• fail2ban contro chi insiste su SSH e wp-login.php (sudo apt install -y fail2ban: su Ubuntu la protezione di SSH è attiva di serie, quella per WordPress va aggiunta).
• Aggiornamenti di sicurezza automatici di Ubuntu: unattended-upgrades è già attivo di serie, controlla con systemctl status unattended-upgrades.
• Isolamento: un utente di sistema e un pool PHP per sito, come sopra.
• Integrità: $W core verify-checksums confronta i file con quelli ufficiali.

Approfondimento completo in Sicurezza di una VPS per l'hosting.

Backup

Regola pratica: una copia fuori dal server, cifrata, automatica e provata con un ripristino ogni tanto. Con restic (nei repository di Ubuntu) e uno spazio S3:

sudo apt install -y restic
sudo -u esempio mkdir -p /var/www/esempio.it/backup
$W db export /var/www/esempio.it/backup/db.sql
sudo RESTIC_REPOSITORY=s3:https://s3.eu-central-1.amazonaws.com/mio-bucket/wp \
RESTIC_PASSWORD_FILE=/root/.restic-pass \
AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... \
restic backup /var/www/esempio.it

La prima volta serve restic init con le stesse variabili; poi restic forget --keep-daily 7 --keep-weekly 4 --prune elimina le copie vecchie. Tutti i dettagli in Backup dei siti su S3.

Aggiornamenti senza sorprese

Gli aggiornamenti di WordPress, plugin e temi sono la prima difesa, ma sono anche la prima causa di siti rotti. Una procedura sicura:

1. backup di file e database subito prima;
2. $W core update, $W core update-db, $W plugin update --all, $W theme update --all;
3. $W core verify-checksums;
4. controllo che la home risponda con codice 200 (curl -sI https://esempio.it);
5. se qualcosa non va, ripristino dal backup.

Per cambi importanti (tema nuovo, WooCommerce) prova prima su una copia di staging.

A mano o con un pannello?

Configurare a mano è il modo migliore per capire lo stack. Con molti siti, però, ripetere ogni passaggio e ricordarsi i backup diventa il vero costo.

WordPress su VPS con Koapanel

Koapanel automatizza lo stack descritto sopra su Ubuntu 24.04. La sezione WordPress comprende:

• installazione in un clic: database dedicato, wp-config.php con chiavi nuove, permalink, WP-Cron sul cron di sistema e verifica finale. Tutti i comandi girano con l'utente di sistema del sito, mai come root;
• tre livelli di cache già configurati: cache delle pagine di nginx (che esclude utenti collegati, carrello, checkout e admin, anche WooCommerce), un Redis privato per ogni sito su socket locale senza porte di rete, e OPcache. Il pannello misura il tempo di risposta della home con e senza cache;
• aggiornamenti sicuri con ritorno automatico: copia di sicurezza, aggiornamento, verifica dei checksum ufficiali e controllo della home; se un passo fallisce file e database tornano com'erano da soli e ricevi un'email. Gli aggiornamenti automatici notturni seguono la stessa procedura;
• protezioni a interruttore: login limitati, fail2ban su login e XML-RPC, XML-RPC chiuso, PHP bloccato in uploads, editor disattivato, file sensibili nascosti, controllo notturno dell'integrità;
• copia di prova protetta da password e non indicizzata, pubblicabile in produzione (file, database o entrambi);
• strumenti: accesso a wp-admin senza password con link valido 60 secondi, cerca e sostituisci anche nei dati serializzati, WP-CLI dal browser, debug e manutenzione;
• importazione di un WordPress esistente da archivio dei file e dump SQL.

I backup vanno su S3 o su disco con restic (Backup e ripristino). Limiti da conoscere: niente Apache né .htaccess (le regole dei plugin di cache o sicurezza scritte per Apache non servono, perché la cache è già gestita da nginx), niente WordPress multisite, niente FTP classico ma SFTP.

Domande frequenti

Quanta RAM serve per WordPress su VPS?

Per uno o pochi siti bastano 2 GB con Redis e cache delle pagine. Per WooCommerce o più di dieci siti parti da 4 GB.

Meglio nginx o Apache per WordPress?

Entrambi funzionano bene. nginx con PHP-FPM consuma meno memoria e serve le pagine in cache più velocemente; Apache ha dalla sua i file .htaccess, comodi se un plugin li richiede.

Redis serve davvero?

Su siti con utenti collegati, WooCommerce o molti plugin riduce parecchio le query al database. Su un blog con cache delle pagine l'effetto è minore, ma costa poca memoria.

Posso migrare un WordPress esistente sulla VPS?

Sì: copia i file, esporta e importa il database, aggiorna wp-config.php e sostituisci l'indirizzo con wp search-replace. Koapanel lo fa dalla funzione Importa, oppure migra interi account da cPanel e Plesk (Migrazione).

Koapanel supporta WordPress multisite?

No, oggi gestisce installazioni singole.

Prova WordPress su Koapanel

Vuoi lo stack di questa guida già configurato? Installa Koapanel gratis su una VPS Ubuntu 24.04 (fino a 3 siti per uso personale) seguendo la guida di installazione, o prova la sezione WordPress nella demo pubblica (utente admin, password demo-admin-2026).