Aggiornamento di Plesk Obsidian: nuove funzionalità per i provider di hosting

Separare chiaramente la versione e i componenti

La situazione documentata al 2 ottobre 2026 è la seguente per il Prodotto di punta Plesk Obsidian 18.0.81 Aggiornamento 2. Questo aggiornamento è stato rilasciato il 29 settembre 2026 e risolve un problema di sicurezza critico. Le nuove funzionalità del pannello descritte in questo articolo fanno parte della versione Plesk Obsidian 18.0.81 del 15 settembre 2026; l’aggiornamento 1 e l’aggiornamento 2, invece, contengono correzioni documentate relative a bug e alla sicurezza.

Potrebbero comunque esserci aggiornamenti successivi che non modificano la versione principale 18.0.81 Update 2: Il changelog riporta, ad esempio, aggiornamenti per estensioni come SSL It! e Let’s Encrypt del 29 settembre, nonché aggiornamenti dei pacchetti PHP del 30 settembre 2026. Chi si limita a parlare di un „Plesk aggiornato“ tralascia quindi un’informazione importante ai fini della pianificazione e dell’assistenza.

Plesk distingue diversi livelli di aggiornamento. I pacchetti Plesk costituiscono il pannello stesso e le sue funzionalità direttamente correlate. A questi si aggiungono i pacchetti di servizi e le estensioni forniti da Plesk, che offrono funzionalità aggiuntive o consentono di integrare servizi esterni. Un nuovo numero di versione di un’estensione non è quindi indice del fatto che anche il nucleo di Plesk sia aggiornato a una nuova versione – e viceversa.

Inoltre, ogni Pannello di hosting All’interno di un sistema operativo esistono ulteriori livelli: pacchetti del sistema operativo e componenti di terze parti, quali database, runtime PHP, server web e servizi di posta elettronica. Le loro fonti dei pacchetti, i cicli di supporto e le dipendenze non seguono necessariamente il ritmo di rilascio di Plesk. Per un provider questa distinzione è rilevante dal punto di vista pratico, poiché i tipi di errore, le finestre di manutenzione e le responsabilità possono variare a seconda del componente interessato.

Nella documentazione di inventario dovrebbe quindi essere sempre indicata la combinazione specifica: versione di Plesk con numero di aggiornamento, versione dell’estensione installata, sistema operativo e pacchetti di runtime rilevanti. Per quanto riguarda le funzioni relative ai certificati o alle applicazioni, va indicata anche l’integrazione utilizzata. In questo modo è possibile risalire, ad esempio, se una modifica proviene da SSL It!, da un’integrazione Let’s Encrypt o dal nucleo del pannello di controllo. Ciò evita aspettative poco chiare negli annunci rivolti ai clienti e semplifica l’individuazione del problema durante l’assistenza.

In che modo gli aggiornamenti di Plesk influiscono sui provider

All’interno della linea Obsidian 18.0, gli aggiornamenti vengono rilasciati in modo continuativo e sequenziale installato. Non è possibile saltare singoli aggiornamenti intermedi. Ciò crea un percorso di aggiornamento definito, ma non esonera un provider dal verificare il proprio ambiente: più siti web dei clienti, dipendenze PHP individuali ed estensioni ospita un server, più è importante capire quale modifica influisca su quale classe di servizio.

Plesk descrive gli aggiornamenti automatici per i propri aggiornamenti e opzioni separate per i componenti di terze parti inclusi e i pacchetti di sistema. La pagina della documentazione fornisce tuttavia indicazioni contraddittorie riguardo all’impostazione predefinita dell’opzione relativa ai componenti di terze parti. Gli amministratori non dovrebbero quindi dare per scontata l’esistenza di un’impostazione predefinita valida a livello globale, ma verificare le opzioni effettivamente impostate per ciascun server in Tools & Settings > Update Settings Verificare. È necessario prestare particolare attenzione, poiché i componenti più recenti potrebbero risultare incompatibili con i siti web ospitati.

Per la gestione di molte istanze dei clienti, questa distinzione rappresenta un vantaggio se tradotta in processi concreti. Le correzioni al pannello di controllo e le modifiche di sicurezza possono essere pianificate in base alla loro portata; la sostituzione dei componenti, invece, viene sottoposta a una valutazione di compatibilità a sé stante. Un’offerta di hosting gestito non deve necessariamente adottare immediatamente ogni versione disponibile del pacchetto. Ciò che conta è quali versioni siano compatibili con lo stack concordato, con la base clienti testata e con il modello di assistenza previsto.

I vantaggi delle versioni più recenti di Obsidian si distribuiscono su diverse aree operative: le funzioni di diagnostica consentono di strutturare il supporto di primo livello, i nuovi strumenti di hosting delle applicazioni ampliano le opzioni tariffarie, mentre le funzioni relative ai certificati e all’assistenza riguardano la sicurezza e la gestione dei diritti. Il contributo illustra anche i fondamenti e gli sviluppi precedenti della linea di prodotti Plesk Obsidian 2025: innovazioni rivoluzionarie per il web hosting . Per l'attuale lancio, tuttavia, è determinante la componente specifica, non solo il nome del prodotto.

L'automazione non è quindi una decisione di autorizzazione generica. È opportuno operare una distinzione tra l'installazione regolare di aggiornamenti Plesk documentati e le modifiche gestite in modo mirato allo stack del cliente. Soprattutto nel caso di server condivisi, questa distinzione impedisce che una modifica inosservata di un componente influisca contemporaneamente su molti siti web indipendenti l’uno dall’altro. Non sostituisce i test, ma rende i rischi visibili e identificabili.

Nuove funzionalità in base allo scenario di hosting

Nell'hosting condiviso, un primo caso d'uso consiste nell'individuazione più rapida dei malfunzionamenti dei domini. Quelli presenti in Plesk Obsidian 18.0.81 La diagnostica DNS di uso generale raggruppa i controlli relativi alla risoluzione, agli aspetti relativi agli MX, al DNSSEC, ai server dei nomi e alla scadenza del dominio. Il report di facile lettura visualizzato nel pannello può aiutare il personale dell’assistenza a verificare in modo strutturato le questioni relative al DNS, alla posta elettronica e alla delega prima che si verifichi un’escalation.

Il rapporto è tuttavia un Diagnosi e nessuna correzione automatica. In particolare, gli alias di dominio non sono attualmente supportati. Anche se un risultato indica una delega o una zona errata, la risoluzione del problema potrebbe spettare al registrar o a un gestore DNS esterno. Come strumento di assistenza, questa funzione risulta quindi particolarmente utile se nel ticket vengono chiaramente specificate le responsabilità e la fase successiva di escalation.

Un secondo ambito è Hosting di applicazioni Per agenzie e sviluppatori. Node.js Toolkit 2.5.0 offre una panoramica centralizzata delle applicazioni Node.js attivate e la configurazione con un solo clic dei progetti esistenti. Il rilevamento automatico è in grado di individuare diversi framework server diffusi, nonché front-end statici. Inoltre, l’estensione pnpm è supportata esclusivamente su Plesk per Linux. Ciò riduce le operazioni ripetitive, ma non garantisce che ogni singola implementazione possa essere trasferita senza modifiche.

La nuova estensione Python 1.0.0 è destinata anche ai sistemi Linux e offre supporto Python per dominio, ambienti virtuali, dipendenze, variabili d’ambiente e secret memorizzati in modo crittografato. Le applicazioni vengono eseguite come applicazioni WSGI tramite Phusion Passenger; l’autorizzazione „Python support management“ può essere gestita tramite piani di servizio e abbonamenti. Ciò può diventare una funzionalità tariffaria controllata, ma non sostituisce automaticamente ogni architettura Python.

Un terzo ambito riguarda i certificati e le funzioni di assistenza. Nella versione 18.0.81, SSL It! supporta la convalida DNS come alternativa alla convalida HTTP per le integrazioni citate ext-acme ed ext-letsencrypt. Ciò è rilevante, ad esempio, per i domini senza porta 80 aperta. Rimane comunque necessario disporre di un metodo adeguato per impostare i record DNS nella zona effettivamente competente; la semplice visualizzazione di un record non garantisce l’accesso in scrittura.

MCP è disattivato per impostazione predefinita nella versione 18.0.81 e può essere collegato tramite un account WebPros. Gli amministratori configurano in panel.ini i tipi di utente autorizzati a connettersi ai client MCP. La sua idoneità non dipende quindi solo dalla funzione, ma anche dai ruoli, dalle autorizzazioni e dalla registrazione. Le funzionalità di estensione specifiche della piattaforma, la gestione DNS esterna e l’architettura dell’applicazione del cliente determinano complessivamente quale novità rientri in quale piano tariffario.

Confronto delle funzionalità per la pianificazione dei prodotti

Ai fini della pianificazione dei prodotti, la denominazione “Plesk Obsidian” non è sufficiente: le funzionalità rilevanti in questo contesto provengono in parte dal prodotto principale e in parte da estensioni con versioni separate. Pertanto, un provider non dovrebbe valutare le funzionalità solo in base alla loro utilità, ma dovrebbe includere nel proprio catalogo tariffario anche il sistema operativo, il modello di licenza e le dipendenze tecniche.

La panoramica distingue in modo particolarmente chiaro tra una funzionalità della piattaforma e un servizio tariffario commercializzabile. La diagnostica DNS può essere ampiamente disponibile come strumento di supporto. Python, invece, fa parte solo delle offerte Linux i cui termini di gestione dei diritti e limiti di assistenza lo prevedono. Per quanto riguarda Node.js, il provider deve distinguere le rispettive sottofunzionalità: pnpm è documentato come esclusivo per Linux, mentre il changelog non limita di conseguenza la panoramica centrale e la configurazione automatica.

Anche le funzioni relative ai certificati e all’MCP richiedono una scelta specifica per ogni prodotto anziché un’attivazione globale. Nel caso di DNS-01, è la competenza sulla zona a determinare l’effettiva utilizzabilità. Nel caso dell’MCP, il collegamento tecnico è solo una parte del progetto; sono determinanti la cerchia di persone autorizzate, i processi tracciabili e la gestione delle azioni con effetti collaterali.

Diagnosi del DNA e certificati nell'assistenza

La versione di Plesk Obsidian 18.0.81, ora disponibile al pubblico Diagnosi del DNA È utile come prima valutazione tecnica di un ticket relativo al dominio. Nel pannello, la funzione „Troubleshoot DNS“ apre un rapporto di facile comprensione sulla risoluzione DNS, sui controlli relativi agli MX, sul DNSSEC, sui problemi dei server dei nomi e sulla data di scadenza del dominio. Ciò accorcia la fase di verifica preliminare, ma non sostituisce né l’analisi della zona autoritativa né il coordinamento con il registrar o un gestore DNS esterno.

Per garantire una procedura di primo livello ripetibile, il supporto dovrebbe innanzitutto registrare il dominio principale interessato e la segnalazione, per poi attribuire la competenza e classificare la natura dell’anomalia. Se, ad esempio, la segnalazione evidenzia una delega errata, la correzione spesso esula dalle competenze del panel. È importante anche il limite documentato: gli alias di dominio non sono attualmente coperti da questa verifica.

Per la diagnosi dalla riga di comando, il changelog riporta il seguente comando con un dominio di esempio neutro. Prima dell’utilizzo, un amministratore dovrebbe consultare la guida o la documentazione relativa ai comandi della versione di Plesk effettivamente installata. Dalla sola sintassi indicata nel changelog non è possibile dedurre alcuna garanzia ulteriore riguardo a tutti gli effetti del comando.

plesk repair dns -n -j -check-resolution example.com

Ampliato per i certificati Convalida DNS-01 il possibile ambito di applicazione: SSL It! può essere utilizzato in Plesk Obsidian 18.0.81 in alternativa alla convalida HTTP per l’emissione e il rinnovo. Ciò è rilevante, ad esempio, per i domini API o di posta elettronica in cui la porta 80 non è intenzionalmente aperta. Plesk mostra i record DNS necessari e salva il metodo selezionato per ciascun dominio in vista di futuri rinnovi.

Tuttavia, il processo non va automaticamente a buon fine solo perché viene visualizzato un record. L’amministratore deve disporre dei diritti di scrittura sulla zona DNS effettivamente competente oppure di un percorso di automazione configurato in modo adeguato. Secondo il changelog, la convalida DNS introdotta con la versione 18.0.81 si applica solo alle integrazioni ext-acme ed ext-letsencrypt di SSL It!, non in modo generalizzato a tutti i fornitori di certificati.

Da questo va distinto l'aggiornamento di espansione successivo SSL It! 1.24.0 del 29 settembre 2026. Con questa versione è possibile proteggere un dominio senza hosting tramite il pannello di controllo o la riga di comando con un certificato wildcard; anche il rinnovo automatico avviene con un certificato wildcard. Questa aggiunta non fa parte delle funzionalità originali di Plesk Obsidian 18.0.81, ma segue il proprio ciclo di versioni e rilascio dell’estensione.

L'hosting delle applicazioni come opzione tariffaria controllata

Grazie alle recenti estensioni, l’hosting delle applicazioni risulta ora più facilmente distinguibile come opzione tariffaria. Il Node.js Toolkit 2.5.0 offre una panoramica centralizzata delle applicazioni Node.js attivate e una configurazione con un solo clic dei progetti esistenti. Inoltre, l’estensione supporta il gestore di pacchetti pnpm su Plesk per Linux. Ciò consente a un provider di standardizzare le attività di configurazione ricorrenti senza dover gestire ogni applicazione del cliente come un’istanza server individuale.

Secondo il changelog, il riconoscimento dei progetti include, tra gli altri, Express, Next.js, NestJS e Nuxt.js, nonché frontend statici basati su React, Vue.js, Angular o Vite. Plesk è in grado di creare un file di avvio compatibile con Passenger, tenere conto delle porte hardcoded e impostare la radice dei documenti, mostrando le modifiche prima della conferma. I frontend statici vengono compilati e distribuiti senza un processo Node.js in esecuzione permanente.

Questa automazione è utile, ma non sostituisce una revisione dell’architettura. Processi multipli, code dei worker, proxy inversi specifici, secret esterni o pipeline di build personalizzate possono richiedere regole operative aggiuntive. Secondo il changelog, la limitazione relativa a Linux si applica espressamente a pnpm; per la panoramica centrale dei domini e la configurazione automatica con un clic non è indicata alcuna limitazione di piattaforma corrispondente. Le descrizioni dei piani tariffari dovrebbero quindi indicare separatamente queste sottofunzionalità.

L'estensione Python 1.0.0 offre su Linux una configurazione gestibile separatamente per ogni dominio. I clienti possono creare ambienti virtuali, installare dipendenze tramite l'interfaccia utente, visualizzare i metadati da pyproject.toml e gestire le variabili d'ambiente e i segreti memorizzati in forma crittografata. L'attivazione avviene tramite l'autorizzazione „Python support management“ nei piani di servizio e negli abbonamenti.

Dal punto di vista tecnico, queste applicazioni vengono eseguite come Applicazioni WSGI tramite Phusion Passenger; la configurazione del server web viene generata automaticamente da Plesk. Un piano „Python Web App“ può quindi includere, ad esempio, ambienti virtuali, un limite definito di risorse e il supporto per i classici progetti WSGI. Ciò non significa però che lo stesso piano copra stack ASGI complessi, worker in esecuzione continua o architetture speciali containerizzate.

Per una classificazione delle funzioni precedenti e delle modifiche all'interfaccia, si può consultare l'articolo Plesk Obsidian: panoramica delle novità e dei miglioramenti possono essere utilizzati a titolo integrativo. Per le nuove tariffe, rimane fondamentale documentare congiuntamente la versione estesa, i limiti documentati della piattaforma, le autorizzazioni e il tipo di applicazione concretamente supportato.

Introdurre gli aggiornamenti in modo graduale nell’ambiente di produzione

In un ambiente di provider, l’aggiornamento del pannello di hosting non dovrebbe avviarsi al primo clic sul server principale di produzione. Crea innanzitutto un Inventario dalle versioni di Plesk, dalle versioni del sistema operativo, dalle estensioni attivate e dalle applicazioni dei clienti in esecuzione su di esse. Sono inoltre importanti le dipendenze esterne quali provider DNS, relay di posta, backup, pacchetti PHP personalizzati e processi di distribuzione. In questo modo risulta chiaro quali sistemi abbiano lo stesso stato e quali casi particolari debbano essere trattati separatamente.

Verifica quindi le dipendenze per ciascuna classe di server. Un aggiornamento del prodotto principale può avere conseguenze diverse rispetto all’aggiornamento di un’estensione o di un componente di terze parti. Anche i pacchetti forniti dal sistema operativo costituiscono un’area di manutenzione a sé stante. Plesk distingue espressamente queste categorie; in particolare, gli aggiornamenti dei componenti di terze parti possono influire sui siti web se questi non sono preparati a versioni o ambienti di esecuzione modificati.

Come passo successivo, si consiglia di effettuare un’indagine rappresentativa Istanza pilota anziché un server di test qualsiasi. Dovrebbe riprodurre le configurazioni tariffarie tipiche: ad esempio siti web CMS classici, domini di posta elettronica, utilizzo di database e applicazioni Node.js o Python attivate, qualora fossero offerte. Lo scopo non è quello di simulare una perfetta corrispondenza con l’ambiente di produzione, ma di rendere visibili in anticipo le combinazioni rilevanti di sistema operativo, estensioni e applicazioni dei clienti.

Per l'implementazione in produzione, definisci una finestra di manutenzione con una sequenza chiara. Aggiorna innanzitutto un gruppo limitato di server, valuta i risultati osservati e solo successivamente estendi l'implementazione. Verifica quindi l’accessibilità del pannello di controllo, i backup pianificati, i servizi web e di posta elettronica, i rinnovi dei certificati e i messaggi di errore delle applicazioni interessate. Questi controlli riducono l’incertezza, ma non garantiscono l’assenza di interruzioni o la completa compatibilità delle applicazioni.

Per la pianificazione della capacità, Plesk indica valori minimi di 1 GB di RAM più 1 GB di swap su Linux e 2 GB di RAM su Windows. Per l’hosting condiviso, come raccomandazione approssimativa si indica 1 GB di RAM ogni 40-50 siti web, a condizione che al massimo il dieci per cento di tutti i siti web ospitati registri un numero costante o regolare di visitatori a settimana o al mese. Tali Valori indicativi delle risorse Non costituiscono una garanzia di capacità e non sostituiscono la misurazione del proprio carico: l'attività del database, il volume di posta elettronica, i software di sicurezza e il tipo di applicazione possono modificare in modo significativo il fabbisogno.

Individuare le fonti di errore e le priorità in materia di sicurezza

Gli errori ricorrenti derivano solitamente da definizioni imprecise dei limiti del prodotto. Per questo motivo, in ogni annuncio è necessario documentare la versione specifica del prodotto principale o dell’estensione. Una funzione Node.js o Python non deve essere pubblicizzata in modo generico per i piani Windows se è documentata solo per Plesk per Linux. Allo stesso modo, l’hosting Python con WSGI tramite Passenger non equivale al supporto di qualsiasi architettura ASGI, worker o container.

• Inserire DNS-01 come caratteristica del piano tariffario solo se è disponibile l'accesso in scrittura alla zona DNS autorevole o un percorso di automazione adeguato.
• Non confondere le opzioni relative agli aggiornamenti automatici di Plesk, dei componenti di terze parti e dei pacchetti di sistema; verificare l'impostazione effettiva per ciascun server in „Strumenti e impostazioni > Impostazioni di aggiornamento“.
• Verificare le estensioni, le autorizzazioni e i sistemi operativi prima di attivare nuove funzionalità per ciascuna linea di prodotti.
• Per MCP, definire i gruppi di utenti autorizzati, i percorsi di approvazione e la registrazione delle azioni prima dell'assegnazione di un ruolo.

Il sito Priorità di sicurezza non dipende esclusivamente dalla convenienza della finestra di manutenzione. Alla data di pubblicazione dell’articolo, Plesk Obsidian 18.0.81 Update 2 del 29 settembre 2026 rappresenta lo stato attuale documentato delle patch per questa linea di release principale; Plesk segnala a tal proposito un problema di sicurezza critico e raccomanda l’installazione tempestiva. Anche l’Update 1 del 21 settembre conteneva una correzione di sicurezza critica, espressamente indicata nel changelog per Linux. Per i sistemi Linux, pertanto, non si dovrebbe rimanere fermi all’Update 1.

Il changelog riporta inoltre, per il mese di settembre, correzioni di sicurezza critiche per Node.js Toolkit 2.5.0 del 14 settembre 2026 e Site Import 1.12.2 del 23 settembre 2026. Verifica quindi sempre se il componente interessato è installato e gestisci il nucleo del pannello, le estensioni, i pacchetti PHP e gli altri componenti aggiuntivi come percorsi di patch separati. Un successivo aggiornamento delle estensioni o di PHP non sostituisce un aggiornamento del prodotto principale in sospeso.

MCP merita un numero limitato di Fase pilota anziché un'attivazione immediata su larga scala. La funzione è disattivata per impostazione predefinita; gli amministratori possono, in panel.ini Stabilire quali tipi di utenti possono connettersi ai client MCP. Definire in anticipo quali attività devono essere supportate, chi è autorizzato a verificare le modifiche e come vengono tracciate le azioni sospette o indesiderate. Un’integrazione con l’intelligenza artificiale non sostituisce né i modelli di ruolo, né la gestione del cambiamento, né le revisioni tecniche.

Avviso: i componenti di terze parti non dovrebbero essere installati in modo incontrollato in tutti gli ambienti dei clienti solo perché è disponibile una versione più recente. Plesk segnala possibili incompatibilità con i siti web ospitati; allo stesso tempo, la pagina della documentazione attuale contiene informazioni contraddittorie riguardo al fatto che la relativa funzione automatica sia attiva per impostazione predefinita. Verifica quindi per ogni server alla voce Tools & Settings > Update Settings le opzioni impostate e pianificare, per le durate di esecuzione e i plugin più diffusi, un’implementazione graduale con un gruppo pilota rappresentativo.

Scegliere tra aggiornamento o trasferimento del server

La scelta tra Aggiornamento in loco Il trasferimento del server parte dallo stato attuale, non dalla versione desiderata di Obsidian. Un aggiornamento sullo stesso server presuppone che il sistema operativo e la versione iniziale di Plesk installata siano supportati per il percorso previsto. Verifica inoltre le estensioni utilizzate, le personalizzazioni effettuate e lo spazio disponibile per i backup. Il fatto che un percorso di aggiornamento sia tecnicamente possibile non significa necessariamente che sia adatto a ogni ambiente del cliente.

Per Plesk Onyx, la documentazione relativa all'aggiornamento indica percorsi diretti verso Obsidian per le versioni 17.0, 17.5 e 17.8. Gli ambienti di partenza più vecchi o non adeguatamente supportati potrebbero richiedere un trasferimento su un nuovo server Obsidian, a condizione che la versione di partenza sia migrabile. Il trasferimento offre la possibilità di preparare il sistema operativo, la configurazione delle risorse e le estensioni separatamente dal sistema precedente.

È particolarmente opportuno valutare un nuovo server di destinazione quando il sistema operativo esistente raggiunge la fine del supporto, la piattaforma è stata personalizzata nel corso del tempo o si verificano diversi salti di versione significativi. I requisiti di sistema di Plesk forniscono solo i limiti minimi per la pianificazione. Per la definizione delle dimensioni del server di destinazione occorre tenere conto anche del numero di siti web, delle caselle di posta, dei database, dei servizi di sicurezza, dello spazio di archiviazione dei backup e del carico previsto dopo la migrazione.

All'indirizzo Aggiornamento tramite trasferimento L'ambiente esistente verrà trasferito su un server su cui è installato Plesk Obsidian. Secondo la documentazione relativa all'aggiornamento, è necessario che il sistema operativo del server di destinazione sia supportato e che la versione di partenza installata consenta la migrazione a Obsidian. È quindi opportuno verificare, prima di procedere alla pianificazione, se questa opzione è disponibile in base alla versione di origine specifica.

Per garantire un’installazione aggiornata, supportata e gestibile, l’applicazione tempestiva delle patch in base all’inventario e alla fase pilota rappresenta solitamente la soluzione più ovvia. In caso di nuove estensioni o funzionalità specifiche per Linux, è opportuno prevedere una fase pilota mirata. Se il supporto del sistema operativo, la versione iniziale o i retaggi tecnici limitano il percorso, si dovrebbe innanzitutto effettuare una Preparazione alla migrazione . La scelta della variante più adatta dipende dallo stato dell'assistenza, dalla compatibilità e dal modello operativo, non da un'approvazione generica per l'uso in produzione.