1 14/10/2026 13 min

Installare Plesk su Ubuntu 20.04 non è complicato, ma va fatto con metodo: il punto non è lanciare uno script e sperare che tutto resti pulito, bensì arrivare a un host coerente, aggiornato e con una baseline chiara prima di esporre pannelli, servizi web e mail. Su una macchina destinata a produzione, la sequenza corretta è semplice: controlli preliminari, installazione, verifica dell’integrazione con il sistema, hardening minimo e test dei servizi che Plesk andrà a gestire.

Ubuntu 20.04 è ancora una base comune per molti ambienti legacy o consolidati. Plesk funziona bene su questa release, ma i problemi tipici nascono quasi sempre prima dell’installer: hostname errato, DNS non coerente, pacchetti di sistema obsoleti, conflitti con stack già presenti, oppure una VM sottodimensionata. Se il nodo è già in uso per altro, va deciso subito cosa deve restare e cosa deve essere sostituito da Plesk, perché il pannello tende a prendere il controllo di Apache, Nginx, PHP, mail e DNS.

Scelta architetturale: cosa deve gestire Plesk

Prima di installare, chiarisci il perimetro. Plesk può diventare il centro operativo per hosting web, mail, DNS, database e certificati, ma non è una “pezza” sopra un server già configurato in modo creativo. Se il nodo ospita già un reverse proxy custom, un’istanza Docker con porte esposte, un mail server manuale o una configurazione Apache/Nginx molto ritoccata, l’installer può sovrascrivere componenti o introdurre dipendenze inattese.

La domanda pratica è questa: vuoi un server gestito da Plesk o un server su cui Plesk sia ospitato? Nel primo caso il pannello deve essere il riferimento principale. Nel secondo, il rischio di conflitti aumenta e conviene valutare una VM dedicata. In produzione, separare i ruoli riduce quasi sempre il tempo speso in diagnosi successive.

Prerequisiti minimi prima di toccare il sistema

Su Ubuntu 20.04, il nodo deve partire da un sistema aggiornato e con accesso root o sudo. Il controllo preliminare essenziale è questo:

hostnamectl

Il nome host deve essere un FQDN valido, ad esempio server01.example.com, non un nome corto o temporaneo. Plesk usa il nome host in più punti, dai certificati ai servizi interni. Se il valore è sbagliato, correggilo prima di installare:

sudo hostnamectl set-hostname server01.example.com

Verifica anche la risoluzione locale:

getent hosts server01.example.com

Se il comando non restituisce l’IP atteso, controlla /etc/hosts e la zona DNS. Un mismatch qui non blocca sempre l’installer, ma genera problemi dopo: mail, certificati, accesso al pannello e servizi che si aspettano un nome coerente.

Controlla anche lo stato degli aggiornamenti e la connettività verso i repository. L’installer di Plesk scarica componenti durante il setup, quindi il nodo deve raggiungere Internet o almeno i mirror necessari:

sudo apt update

Se apt update fallisce, non ha senso andare avanti: prima risolvi DNS, routing, proxy o policy firewall in uscita.

Controlli di base su porte, risorse e conflitti

Plesk occupa porte ben precise, soprattutto per il pannello e i servizi web. Prima dell’installazione verifica che non siano già in uso da processi non controllati:

sudo ss -lntp | egrep ':(80|443|8443|25|53|110|143|465|587|993|995)'

Se trovi servizi sconosciuti in ascolto su 80, 443 o 8443, valuta se disattivarli o spostarli. Il pannello Plesk, per accesso iniziale, usa normalmente la porta 8443. Se quella porta è già bloccata, l’accesso iniziale diventa più complicato e il troubleshooting si allunga inutilmente.

Controlla anche le risorse minime. Per un’installazione base, 2 GB di RAM sono il limite operativo, ma 4 GB o più sono una scelta più sensata appena si aggiungono mail, antivirus, più domini o PHP multipli. Il disco deve avere margine reale, non solo nominale: tra pacchetti, log e cache, un nodo stretto va in sofferenza in fretta.

Una verifica rapida del filesystem aiuta a evitare installazioni interrotte a metà:

df -hT

Se lo spazio libero è scarso, libera prima il necessario oppure espandi il volume. Far partire l’installer con meno di qualche gigabyte disponibili è un invito a problemi durante il download dei componenti.

Installazione di Plesk su Ubuntu 20.04

Il metodo standard e più pulito è usare l’installer ufficiale. Scarica lo script e avvialo con privilegi elevati. In un contesto operativo normale, questo è il percorso più lineare:

wget https://autoinstall.plesk.com/plesk-installer
chmod +x plesk-installer
sudo ./plesk-installer

Se preferisci una modalità non interattiva, utile per automazione o provisioning ripetibile, puoi usare l’installazione in unattended. In quel caso devi però sapere già quali componenti vuoi includere. Non è il momento di improvvisare: il rischio è installare più del necessario o, peggio, un profilo che non corrisponde al tuo servizio.

Durante il wizard scegli il tipo di installazione in base all’uso previsto. Per un server hosting classico, il preset completo con stack web, PHP e database è il più comune. Se invece il nodo ospita solo alcuni siti e il resto è esternalizzato, conviene ridurre il set iniziale e aggiungere solo ciò che serve davvero.

In fase di setup, osserva con attenzione eventuali avvisi su pacchetti già installati. Plesk può sostituire o integrare componenti come Apache, Nginx, PHP, MariaDB e Postfix. Se il sistema aveva già versioni custom o repository terzi, fermati e valuta l’impatto. Il punto non è “si può fare”, ma “quanto costa rimettere in ordine se qualcosa si rompe”.

Verifica dell’accesso al pannello dopo il setup

Al termine dell’installazione, il pannello è normalmente raggiungibile su HTTPS alla porta 8443. La verifica più semplice è da shell:

curl -kI https://IP_DEL_SERVER:8443

Ti aspetti un HTTP/1.1 200, un 302 verso la pagina di login o comunque una risposta TLS valida. Se ricevi timeout, controlla firewall locale, security group del provider e stato del servizio Plesk. Se invece il certificato risulta non attendibile, è normale nelle prime fasi: poi sostituirai il certificato di default con uno valido per il dominio corretto.

Dal lato sistema, verifica che i servizi principali siano attivi:

sudo systemctl status psa

In base al layout installato, possono esserci anche servizi separati per Apache, Nginx, MariaDB, Postfix e Dovecot. Non basta che il pannello risponda: bisogna controllare che la macchina sia operativa come host applicativo, non solo come interfaccia web.

Accesso iniziale e hardening minimo del pannello

Al primo accesso, completa la configurazione iniziale con credenziali amministrative robuste e con un indirizzo email gestito davvero. Evita caselle temporanee o indirizzi non presidiati: Plesk invia notifiche, allarmi e messaggi operativi che servono per la manutenzione. Se li perdi, perdi anche la capacità di reagire in tempo.

La prima correzione utile è sostituire il certificato auto-firmato del pannello con uno valido. Questo riduce gli avvisi lato browser e impedisce che gli utenti amministrativi ignorino i warning TLS. Se il pannello è esposto su Internet, il certificato non è un dettaglio estetico: è parte dell’igiene operativa.

Controlla anche la policy degli accessi. Se il server è amministrato da un team, limita gli account con privilegi elevati e usa ruoli separati per attività diverse. Un solo account condiviso è comodo fino al primo incidente, poi diventa un buco nero nei log e nella responsabilità operativa.

Configurazione dei servizi web: Apache, Nginx e PHP

Una delle ragioni per cui Plesk è usato spesso in hosting è la gestione integrata di Apache e Nginx. In molti scenari Nginx lavora come reverse proxy davanti ad Apache, ma la scelta dipende dal profilo del sito. Per applicazioni leggere e statiche, Nginx può fare gran parte del lavoro; per stack legacy o CMS storici, la compatibilità con Apache resta utile.

Il punto operativo è che Plesk rende la gestione dei virtual host più coerente, ma non elimina la necessità di capire cosa sta succedendo sotto. Se una pagina risponde lentamente, devi sapere se il collo di bottiglia è PHP-FPM, il database, il disco o la cache. Il pannello semplifica il cambio di configurazione, non la diagnosi.

Per controllare i pool PHP attivi e le versioni disponibili, il percorso in GUI è spesso più comodo, ma da shell puoi vedere quali processi stanno girando e con quali parametri. La verifica base è questa:

ps aux | grep php-fpm

Se usi più versioni PHP, fai attenzione alla compatibilità dei siti importati. Un sito che girava su PHP 7.4 può rompersi su PHP 8.x per funzioni deprecate o estensioni mancanti. Il passaggio va testato dominio per dominio, non imposto in blocco.

DNS, mail e certificati: tre punti che generano problemi reali

Con Plesk, DNS e mail spesso finiscono nello stesso perimetro operativo, ma vanno trattati con attenzione diversa. Se il server gestisce anche i record DNS autorevoli, la zona deve essere coerente con l’IP pubblico e con l’hostname del nodo. Un record A sbagliato o un MX incoerente può sembrare un problema minore, ma si traduce subito in mail non recapitate o in certificati che non si allineano ai nomi reali.

Per la mail, la parte critica non è “installare il servizio”, ma farlo parlare bene con il resto del mondo. SPF, DKIM e DMARC non sono optional se il server invia posta per domini reali. Plesk semplifica la configurazione, ma non sostituisce la verifica delle policy esterne e del reverse DNS del provider.

Un controllo rapido sul reverse DNS e sulla risoluzione pubblica evita molte ore perse dopo:

dig +short server01.example.com A
dig +short -x IP_PUBBLICO

Se i due valori non sono coerenti con il ruolo del server, apri il ticket presso il provider o correggi la delega DNS. Per i certificati, usa Let’s Encrypt quando il dominio è già pubblicamente risolvibile e raggiungibile sulla porta 80/443. Se il DNS non è stabile, il rinnovo automatico fallirà prima o poi.

Installazione pulita vs migrazione da server esistente

Una migrazione su un nodo nuovo è sempre preferibile a una sovrascrittura su un server già pieno di servizi. Se devi importare siti da un ambiente precedente, prima fai un inventario: domini, versioni PHP, database, cron, certificati, mailboxes, record DNS e eventuali rewrite custom. Senza questa lista, il passaggio diventa un tentativo cieco.

Quando il vecchio server ha configurazioni manuali, non copiare a mano i file “a sentimento”. Verifica quali elementi sono realmente necessari e quali erano solo workaround del passato. In molti casi conviene ricreare il sito in Plesk e migrare solo contenuti, database e parametri indispensabili, lasciando fuori il debito tecnico accumulato nel tempo.

Se l’ambiente è critico, pianifica un rollback semplice: snapshot della VM prima del setup o backup completo del server. Questo è il tuo punto di ritorno se l’installazione interferisce con stack esistenti o se una parte del servizio non si riallinea come previsto.

Verifiche post-installazione da non saltare

Dopo il setup, valida almeno questi punti:

  • Il pannello risponde in https://IP:8443 e il login funziona.
  • Il nome host è corretto e risolve sia localmente che pubblicamente.
  • I servizi web rispondono e i virtual host creati in Plesk servono contenuto.
  • La mail, se attivata, passa i controlli SPF/DKIM/DMARC.
  • Lo spazio disco resta abbondante dopo l’installazione e i log crescono in modo normale.
  • In pratica, non fermarti al “si apre il pannello”. Un’installazione completa ma fragile è peggio di un’installazione incompleta, perché ti dà una falsa sensazione di stabilità. I problemi si presentano di solito al primo rinnovo certificato, al primo aggiornamento PHP o al primo dominio importato.

    Manutenzione dopo l’installazione

    Plesk non va trattato come un sistema che “una volta installato e finito”. Il pannello, i componenti web e le estensioni richiedono aggiornamenti regolari. La manutenzione minima include patch di sistema, aggiornamenti del pannello, controllo dei log e pulizia dei componenti non usati. Se non governi questa routine, il nodo si appesantisce e la diagnostica diventa più lenta nel tempo.

    Per tenere sotto controllo lo stato del sistema, usa log e metriche prima di modificare qualcosa. Alcuni check utili sono i log di sistema, i log del pannello e i log dei servizi web. A livello pratico, se un sito risponde male, guarda prima gli errori dell’applicazione e i tempi di risposta reali, non soltanto la pagina di stato del pannello.

    Un approccio sano è questo: aggiornamenti pianificati, backup verificati, monitoraggio attivo del disco e alert sui servizi essenziali. Se il server ospita più domini, la saturazione di un singolo sito non deve trascinare giù il resto. Qui entrano in gioco limiti PHP, pool separati e una configurazione sensata delle risorse.

    Errore tipico: il pannello non si apre dopo l’installazione

    Se dopo il setup non riesci ad aprire Plesk, la diagnosi più rapida segue tre strade: porta bloccata, servizio fermo, oppure DNS/hostname incoerente. Il controllo base è:

    sudo systemctl status psa

    Se il servizio è attivo ma il browser non raggiunge la pagina, verifica il firewall locale e quello del provider. Se il servizio non parte, controlla i log di installazione e lo stato dei componenti. In caso di hostname errato, correggilo e riavvia i servizi interessati. Evita di fare “restart a caso” su tutto il sistema: prima identifica il layer che sta fallendo.

    Se il problema è un certificato o un redirect anomalo, prova l’accesso diretto via IP sulla porta 8443 e poi sostituisci il certificato del pannello con uno valido. Se il problema è più profondo, un backup della VM o uno snapshot ti consente di tornare indietro senza perdere ore in tentativi casuali.

    Quando conviene non installare Plesk su quel nodo

    Ci sono casi in cui la risposta corretta è “no, non qui”. Se il server è già un nodo di produzione con stack personalizzati, se gestisce applicazioni containerizzate complesse, se funge da reverse proxy centralizzato o se ospita servizi critici non web, aggiungere Plesk può aumentare la superficie di manutenzione invece di ridurla. In quei casi la scelta migliore è una macchina dedicata o una VM separata, con ruoli più chiari.

    Lo stesso vale per ambienti in cui il team vuole controllo granulare su ogni componente e preferisce gestire tutto da IaC o da configurazioni versionate. Plesk è utile quando vuoi accelerare la gestione operativa e ridurre gli errori manuali su hosting standard. Non è il sostituto universale di una piattaforma progettata su misura.

    Sequenza pratica riassunta

  • Imposta hostname FQDN e verifica la risoluzione con hostnamectl e getent hosts.
  • Aggiorna il sistema con apt update e correggi eventuali problemi di rete o repository.
  • Controlla porte, servizi in ascolto e spazio disco con ss e df -hT.
  • Avvia l’installer ufficiale di Plesk e scegli il profilo coerente con il ruolo del server.
  • Verifica l’accesso su https://IP:8443 e lo stato dei servizi con systemctl.
  • Completa hardening minimo, certificati, DNS e test funzionali dei siti ospitati.
  • Se tieni questo ordine, l’installazione resta prevedibile. Saltare i controlli iniziali, al contrario, porta quasi sempre agli stessi problemi: pannello non raggiungibile, mail mal configurata, certificati incoerenti o servizi web che sembrano funzionare solo finché non arriva il primo cambio reale.

    In un’installazione Plesk fatta bene, il valore non sta nello script lanciato, ma nella qualità del nodo che lo ospita. Ubuntu 20.04 è una buona base, ma va preparata con disciplina. Se il server è coerente prima dell’installer, il resto è quasi sempre una questione di configurazione, non di fortuna.