Per eseguire WordPress in un homelab devi scegliere due cose: l’ambiente che ospita il sistema e il modo in cui installi l’applicazione. VM e LXC riguardano soprattutto il primo livello; Docker Compose organizza i servizi applicativi e può girare, per esempio, dentro una VM.
Questa distinzione evita un confronto confuso. Un pannello come HestiaCP, uno stack Compose e un database separato rispondono a problemi operativi diversi. La scelta migliore è quella che riesci ad aggiornare, osservare e ripristinare con le competenze e le risorse disponibili.
VM o LXC: il confine del sistema operativo
Una VM ha il proprio kernel e presenta un ambiente più separato dall’host. Un container LXC Linux condivide il kernel del nodo e usa meccanismi di isolamento del sistema operativo. Questo rende LXC leggero, ma introduce vincoli su funzioni del kernel, dispositivi e privilegi.
Per un laboratorio che studia sistemi diversi, una VM è spesso facile da ragionare come macchina autonoma. Per molti ambienti Linux simili, LXC può ridurre l’ingombro operativo. La documentazione dei container Proxmox è il riferimento per privilegi, mount e limiti: non renderei un container privilegiato soltanto per superare un errore d’installazione senza capirlo.
Stack di sistema con HestiaCP
Nel lavoro sulle infrastrutture Romiltec, HestiaCP è uno strumento concreto per gestire domini, utenti, database e configurazioni web. Questo modello ha senso se il team conosce Linux e vuole amministrare più siti con convenzioni uniformi.
La manutenzione richiede di rispettare i template e gli strumenti del pannello: una modifica manuale a un file generato può sparire al rebuild successivo. Prima dell’installazione va verificata la matrice dei sistemi supportati da HestiaCP, senza presumere che l’ultima Debian sia già adatta.
Utenti, permessi e pool PHP separati forniscono confini utili, ma CPU, memoria e storage rimangono risorse da dimensionare. Un pannello non rende automaticamente sicuro ogni plugin; una versione PHP diversa per progetto non risolve da sola le incompatibilità dell’applicazione.
Docker Compose: descrivere lo stack e i dati persistenti
Compose permette di versionare la definizione dei servizi, delle reti e dei volumi. È utile quando vuoi ricostruire uno staging o mantenere runtime differenti. Nel repository vanno configurazione e istruzioni; credenziali e contenuti del database richiedono una gestione separata.
L’immagine ufficiale WordPress offre varianti con server web o PHP-FPM. Con FPM devi aggiungere un web server e configurare correttamente i percorsi dei file: montare soltanto wp-content in nginx non gli rende disponibile il resto del core che deve servire o verificare.
Non includo qui un Compose ridotto che sembri pronto per la produzione. Prima del primo avvio definirei persistenza del database, file e uploads, versione delle immagini, segreti, health check e backup. Il fatto che il container riparta non dimostra che l’applicazione abbia conservato tutti i dati.
Per ospitare più stack puoi usare un reverse proxy e reti applicative dedicate. Verifica quali porte vengono pubblicate sull’host: due servizi non possono occupare lo stesso indirizzo e la stessa porta. Verifica anche i limiti di risorse Docker: per impostazione predefinita i container non hanno limiti dedicati che impediscano loro di consumare le risorse disponibili.
Separare web e database solo con un motivo preciso
Un database su una VM distinta può avere senso per dimensionamento, manutenzione o condivisione tra nodi web. Aggiunge però connessioni di rete, credenziali, monitoraggio e una procedura di recupero coordinata.
Se il web server viene compromesso, l’attaccante può ancora trovare credenziali con cui l’applicazione accede al database. La rete privata riduce l’esposizione, ma non cancella questo percorso. Servono privilegi minimi e una chiara separazione delle responsabilità.
| Situazione | Punto di partenza ragionevole | Cosa provare prima |
|---|---|---|
| Imparare Linux e WordPress | VM con stack semplice | Installazione, aggiornamento e restore completo |
| Amministrare siti con procedure già basate su Hestia | VM o LXC con sistema supportato | Ripristino di un singolo dominio e dei suoi dati |
| Staging frequenti e runtime diversi | Compose su un host adatto | Ricostruzione su un host vuoto con backup |
| Esigenza dimostrata di scalare componenti | Web e database separati | Guasto di un componente e recupero coerente |
La prova decisiva è ricostruire il sito
Prendi un WordPress di test con un articolo, un utente e un allegato. Salva ciò che serve, ricostruisci l’ambiente altrove e controlla login, permalink, media e una scrittura. Un archivio della directory non sostituisce il database; uno snapshot non coordinato non garantisce la consistenza tra servizi.
Non userei un numero di visite mensili come soglia automatica per scegliere l’architettura. Due siti con lo stesso traffico possono avere costi molto diversi per plugin, cache e operazioni dinamiche. Misura il carico che resta dopo la cache e il comportamento durante i picchi.
Il laboratorio è un buon posto per confrontare queste soluzioni. Se il sito deve servire clienti, aggiungi al confronto connettività, alimentazione, monitoraggio e tempi di recupero. La guida alla migrazione tramite Proxmox Backup Server approfondisce proprio il passaggio dall’ambiente di prova a quello operativo.