Su mrtux.it abbiamo già coperto Pressable e MCP come caso di hosting managed che usa container per orchestrare AI workload, Sevalla come alternativa PaaS e il workflow Salesforce+Kinsta API per il deploy automatizzato. Questo articolo fa un passo indietro e spiega l'architettura: cosa sono i container nel contesto WordPress, perché Kinsta, Pressable e Sevalla li usano, quando ha senso il self-hosted con containerd/Kubernetes, e come si confronta in TCO con un setup tradizionale. È un articolo architetturale, non un tutorial di installazione.

Cosa significa "container-based" nel contesto WordPress

Un container è un'unità di esecuzione isolata che condivide il kernel del sistema operativo host ma ha il proprio filesystem, process space e network namespace. Nel contesto WordPress, ogni sito gira in un container separato con il suo PHP-FPM, MariaDB/MySQL, Nginx e storage. Quando un sito riceve traffico, solo il suo container scala; gli altri siti sullo stesso server fisico non subiscono il carico.

I tre vantaggi strutturali

Il container-based hosting non è una moda da devops, è una risposta a tre problemi operativi concreti.

• Isolamento delle risorse. Un sito con un picco di traffico non sottrae RAM o CPU agli altri siti sullo stesso server fisico. Su un hosting tradizionale shared o VPS, un picco di un cliente può degradare le performance di tutti gli altri.
• Sicurezza cross-site. Se un sito viene compromesso (XSS, plugin vulnerabile, supply chain attack), l'attaccante non può uscire dal container. Su un hosting tradizionale, l'accesso a un sito può diventare accesso all'intero server.
• Scalabilità granulare per sito. Ogni container scala indipendentemente in base al carico del singolo sito. Su un hosting tradizionale, si scala l'intero server, anche se il 90% dei siti è fermo.

Cosa NON è un container

Un container non è una VM. La differenza è sottile ma critica: una VM ha il proprio kernel, un container condivide il kernel dell'host. Questo rende i container più leggeri (un container WP occupa 200-500 MB di RAM, una VM ne occupa 1-2 GB) e più veloci da avviare (un container WP è pronto in 1-2 secondi, una VM in 30-60 secondi). Ma significa anche che un kernel panic sull'host abbatte tutti i container.

Perché i managed host WordPress sono passati ai container

La domanda non è "i container sono meglio", è "perché i principali managed host WordPress sono passati ai container". La risposta è duplice: economics e operations.

Caso 1: Kinsta

Kinsta usa container basati su LXC (Linux Containers) dal 2017, e la decisione architetturale spiegata nel blog post "Why Kinsta uses container-based hosting (and why it matters)" del maggio 2026 è che il container permette di dare a ogni cliente un environment con risorse garantite (CPU e RAM fisse) senza dover allocare un intero server fisico per sito. Il modello di business è "resources on demand", con pricing per visitor e storage, e il container è l'unità di billing.

• Architettura: LXC containers, isolamento kernel-level, Nginx + PHP-FPM 8.2/8.3, MariaDB per container, edge cache Cloudflare integrata.
• Deployment: 60+ data center Google Cloud Platform, ogni sito sceglie regione, deploy in 30 secondi.
• Pricing: piano Starter da 35 $/mese per 1 sito, 25.000 visite, 10 GB storage. Piano Pro da 70 $/mese per 2 siti, 50.000 visite. Piano Business da 100 $/mese per 3 siti, 100.000 visite. Multi-site e multi-region da 200 $/mese in su.

Caso 2: Pressable

Pressable usa container basati su Docker Swarm, con orchestrazione custom per il bilanciamento del carico. L'architettura è ottimizzata per il workflow agenzia: ogni cliente è un container, ogni staging environment è un container separato, e la clonazione tra staging e production è uno snap del container.

• Architettura: Docker Swarm, container WP completi (PHP-FPM + Nginx + MariaDB), object storage per media, edge cache Automattic.
• Deployment: 6 data center globali, SFTP + WP-CLI + Git, staging in 1 click.
• Pricing: piano Starter da 25 $/mese per 1 sito, 50.000 visite. Piano Pro da 50 $/mese per 1 sito, 200.000 visite. Piano Agency da 175 $/mese per 5 siti, 1M visite totali.

Caso 3: Sevalla

Sevalla è il nuovo PaaS di Kinsta (lanciato nel 2026) che usa container per orchestrare applicazioni production, non solo WordPress. È progettato per team che vogliono container senza la complessità di Kubernetes.

• Architettura: container basati su containerd + orchestrazione custom, supporto multi-region, build automatica da Git, preview environments per branch.
• Deployment: Git push to deploy, preview environment automatico per ogni PR, scaling automatico per carico.
• Pricing: usage-based, ~25 $/mese per 1 app + 5 GB egress + 1 GB RAM. Più economico di Kubernetes managed (che parte da 70-150 $/mese per cluster) ma più caro di WP managed puro (che parte da 25-35 $/mese per sito).

Perché NON usano Kubernetes direttamente

Kubernetes è la piattaforma di orchestrazione container più diffusa, ma i managed host WordPress non la usano direttamente per WordPress. Le ragioni sono tre.

1. Costo overhead. Un cluster Kubernetes minimo (3 nodi, control plane, etcd, monitoring) costa 70-150 $/mese solo di infrastruttura di base, prima ancora di ospitare qualsiasi sito. Su 10 siti WP il break-even con un hosting managed è sfavorevole.
2. Complessità operativa. Kubernetes richiede un team operativo che gestisca aggiornamenti, monitoring, security patching del control plane. Le agenzie WP di solito non hanno questa seniority.
3. Overkill per il workload. WordPress è un'applicazione stateful con storage persistente, caching object, code job. La maggior parte delle feature Kubernetes (service mesh, operator pattern, sidecar containers) non sono necessarie per WP.

Sevalla, come spiegato nell'articolo dedicato, è la risposta a questo trade-off: container senza la complessità operativa di Kubernetes.

Architettura di un container WordPress self-hosted

Per chi vuole il container senza pagare un managed host, l'opzione self-hosted è Docker + Docker Compose su VPS, oppure Kubernetes per setup più articolati. Vediamo entrambi.

Setup minimo: Docker Compose su VPS

Per un'agenzia 10-30 siti, un singolo VPS Hetzner o OVH (8-16 GB RAM, 4-8 vCPU) con Docker Compose è sufficiente. Ogni sito ha il suo stack in container separato, e il reverse proxy (Nginx o Traefik) instrada le richieste per dominio.

Il docker-compose.yml di base ha la struttura seguente. Il volume persistente per WordPress è separato dal container PHP per permettere aggiornamenti senza perdere dati, e MariaDB gira in un container dedicato per isolare il database.

# File: docker-compose.yml
# Stack WP base con PHP 8.3, MariaDB 10.11, Nginx reverse proxy
# Setup: docker compose up -d
version: '3.9'
services:
  wp:
    image: wordpress:6.7-php8.3-apache
    restart: unless-stopped
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_DB_NAME: wp_db
    volumes:
      - wp_data:/var/www/html
    networks:
      - wp_net
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wp_db
      MARIADB_USER: wp_user
      MARIADB_PASSWORD: ${DB_PASSWORD}
      MARIADB_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - wp_net
  nginx:
    image: nginx:1.27-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
    networks:
      - wp_net
volumes:
  wp_data:
  db_data:
networks:
  wp_net:
    driver: bridge

Setup intermedio: Kubernetes per agenzie 30+ siti

Per un'agenzia 30+ siti, Docker Compose su un singolo VPS diventa un single point of failure e complica il backup, il monitoring e la scalabilità. Kubernetes (anche nella versione leggera K3s di Rancher) gestisce questi aspetti nativamente, al costo di una complessità operativa maggiore.

Il deployment Kubernetes minimo per WP prevede: un namespace per sito, un deployment per PHP-FPM (con 2-3 repliche), un StatefulSet per MariaDB, un PersistentVolumeClaim per storage, un Service per il bilanciamento interno, e un Ingress Nginx per il routing HTTPS.

# File: deployment-wp-php.yaml
# Deployment PHP-FPM per un singolo sito WP
# Setup: kubectl apply -f deployment-wp-php.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wp-php
  namespace: cliente-acme
spec:
  replicas: 3
  selector:
    matchLabels:
      app: wp-php
  template:
    metadata:
      labels:
        app: wp-php
    spec:
      containers:
        - name: php
          image: wordpress:6.7-php8.3-fpm
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          volumeMounts:
            - name: wp-content
              mountPath: /var/www/html/wp-content
      volumes:
        - name: wp-content
          persistentVolumeClaim:
            claimName: wp-content-pvc

K3s (Rancher) è la versione leggera di Kubernetes che gira anche su un singolo nodo, ed è la scelta pragmatica per un'agenzia che vuole l'orchestrazione senza pagare un cluster managed. Il setup è 1.000 righe di YAML, ma il risultato è un'infrastruttura che scala orizzontalmente e gestisce i deployment GitOps senza intervento manuale.

Container e AI workload: il caso reale

L'argomento che rende i container WordPress non più "nice to have" ma "must have" nel 2026 è il workload AI on-edge. Quando un sito WordPress integra un modello AI (per personalizzazione, raccomandazioni, generazione immagine), il workload AI può essere 10-50x più pesante del workload WP classico. Se condividi lo stesso processo PHP-FPM, l'AI workload degrada le performance dell'intero sito.

L'architettura a container risolve il problema con il sidecar pattern: il container principale fa solo WordPress, un container separato (sidecar) fa il workload AI, e i due comunicano via HTTP interno. Quando l'AI è sotto carico, solo il container AI scala, e il sito WP rimane veloce.

Esempio: sidecar AI per raccomandazioni prodotto

Un sito WooCommerce che usa un modello AI per raccomandazioni prodotto può isolare il workload AI in un container separato. Il container WP chiama il container AI via REST, il container AI fa l'inferenza, e il container WP riceve le raccomandazioni in 200-500ms senza impatto sul TTFB del sito.

Il docker-compose.yml per il sidecar AI ha il container Ollama separato dal container WordPress, con una rete interna dedicata per la comunicazione.

# File: docker-compose-ai-sidecar.yml
# Stack WP + Ollama self-hosted LLM in container separato
# Setup: docker compose -f docker-compose-ai-sidecar.yml up -d
version: '3.9'
services:
  wp:
    image: wordpress:6.7-php8.3-apache
    # ... configurazione WP standard
  ollama:
    image: ollama/ollama:latest
    restart: unless-stopped
    # Limita risorse: AI workload non deve saturare il sistema
    deploy:
      resources:
        limits:
          memory: 8G
          cpus: '4'
    volumes:
      - ollama_data:/root/.ollama
    networks:
      - ai_net
  nginx:
    image: nginx:1.27-alpine
    # ... configurazione reverse proxy con route /api/ai/* verso ollama:11434

L'isolamento delle risorse è il vantaggio chiave: se il container Ollama satura la CPU per un'inferenza lenta, il container WP continua a rispondere normalmente. Su un setup tradizionale non-container, lo stesso workload degraderebbe TTFB del sito a 2-5 secondi.

Abbiamo trattato il self-hosted LLM per WordPress in un articolo dedicato che copre Ollama, LM Studio e vLLM con numeri di TCO reali per agenzie e software house.

TCO a 12 mesi: container managed vs self-hosted

La domanda operativa concreta è: quanto costa in TCO reale un setup container managed rispetto al self-hosted? Ho simulato i tre scenari tipo per un'agenzia con 20 siti WP di medie dimensioni (50-200 visite/giorno ciascuno).

Scenario A: 20 siti su Kinsta WP hosting

Costo: 20 siti × 35 $/mese (piano Starter) = 700 $/mese = 8.400 $/anno (circa 7.700 €/anno). Include edge cache, backup giornaliero, staging, SSL automatico, supporto 24/7. Tempo di setup: 1-2 ore. Tempo di manutenzione annuo: 4-8 ore.

Scenario B: 20 siti su Pressable Agency plan

Costo: 4 piani Agency (5 siti × 175 $/mese) = 700 $/mese = 8.400 $/anno. Include edge cache Automattic, backup giornaliero, staging, supporto 24/7. Tempo di setup: 1-2 ore. Tempo di manutenzione annuo: 4-8 ore.

Scenario C: 20 siti self-hosted su Hetzner + Docker Compose

Costo: 1 VPS Hetzner CCX63 (24 vCPU, 64 GB RAM) = 60 €/mese + object storage per backup = 20 €/mese = 80 €/mese + 500 € iniziali per setup Docker Compose = ~1.500 €/anno. Include setup custom, backup manuale o scriptato, SSL via Let's Encrypt, monitoring con UptimeRobot (gratuito). Tempo di setup: 1-2 giornate. Tempo di manutenzione annuo: 60-80 ore (aggiornamenti WP, security patching, monitoring, backup restore test).

Analisi

Il break-even tra self-hosted e managed è a 15-20 siti se il valore orario dello sviluppatore è sopra i 50 €/ora. Sotto i 15 siti, self-hosted è economicamente superiore solo se lo sviluppatore ha competenze DevOps reali (Kubernetes, monitoring, security). Sopra i 20 siti, managed è quasi sempre la scelta giusta per agenzie senza team DevOps dedicato.

La variabile nascosta è il costo di incident. Su un setup self-hosted, un singolo errore di aggiornamento (PHP rotto, MariaDB corrotta, container che non riparte) può causare 4-8 ore di downtime non pianificato. Su un setup managed, lo stesso incidente è gestito dal provider con SLA. Per un'agenzia con clienti enterprise, il costo di 8 ore di downtime supera spesso il risparmio annuale del self-hosted.

Quando NON serve il container

Il container non è una soluzione universalmente migliore. Ci sono casi in cui è over-engineering, e adottarlo significa pagare complessità per un vantaggio che non si materializza.

Caso 1: 1-3 siti personali

Se gestisci 1-3 siti personali senza workload AI e senza team multi-sviluppatore, il container è overkill. Un hosting WP tradizionale (SiteGround, DreamHost, anche Kinsta Starter) ti dà tutto ciò che ti serve con meno complessità operativa. Il break-even per il container è a 5+ siti.

Caso 2: Siti statici senza AI workload

Se i tuoi siti sono brochure statiche senza interazioni AI, plugin pesanti o workload custom, il container ti dà isolamento ma non ti fa risparmiare nulla. Un hosting shared di qualità è sufficiente.

Caso 3: Team senza competenze DevOps

Se il tuo team non ha nessuno con competenze Docker/Kubernetes/monitoring, il self-hosted container è una trappola operativa. Anche il managed richiede un minimo di comprensione dell'architettura (per debug, per configurare DNS, per gestire backup restore). Senza queste basi, anche un setup "managed" diventa ingestibile.

Caso 4: Siti con storage > 500 GB

Il container ha limiti pratici sullo storage persistente. Se un singolo sito ha 500 GB+ di media (libreria fotografica, archivio video), il container diventa scomodo perché lo storage va gestito come volume separato, con backup più complessi. In questi casi, un object storage (S3, Wasabi) + CDN è la soluzione naturale, container o non container.

Confronto rapido: managed container vs self-hosted

Una scheda affiancata per orientare la scelta operativa. I criteri sono quelli che contano nella decisione di acquisto, non nella scheda tecnica del vendor.

Managed container (Kinsta, Pressable, Sevalla)

• Funziona quando: agenzia 5+ siti, team senza DevOps dedicato, bisogno di SLA, workload AI variabile.
• AI utile per: sidecar AI, generazione di template, testing A/B.
• Rischio: lock-in vendor, costo a lungo termine più alto, meno controllo sull'infrastruttura.

Self-hosted container (Docker Compose, K3s)

• Funziona quando: agenzia 20+ siti, team con competenze DevOps, budget limitato, bisogno di customizzazione spinta.
• AI utile per: self-hosted LLM, inferenza on-edge, workload AI isolato per cliente.
• Rischio: costo di incident alto, tempo di manutenzione 60-80 ore/anno, single point of failure se non ben architettato.

Le 5 trappole da evitare nella scelta

L'adozione di un container hosting cade su pattern ricorrenti. Ecco le cinque trappole che vedo più spesso, in ordine di costo.

1. Scegliere Kubernetes quando serve solo Docker Compose

Kubernetes è potente, ma il setup minimo è 70-150 $/mese + 1-2 giornate di setup. Per un'agenzia 10-20 siti, è overkill. Il break-even per Kubernetes è a 30-50 siti con team DevOps. Sotto quella soglia, Docker Compose su VPS è la scelta corretta.

2. Ignorare il costo del backup e del monitoring

Un container senza backup è un incidente annunciato. Su un setup self-hosted, il backup deve essere automatico (cron + script bash + object storage), testato periodicamente (restore drill trimestrale), e monitorato (alert se il backup fallisce). Il setup minimo sono 4-8 ore/mese di manutenzione.

3. Sottovalutare il costo di incident

Un singolo aggiornamento WP che rompe il container può causare 4-8 ore di downtime. Su un cliente enterprise, il costo di 8 ore di downtime è 5.000-20.000 € (perdita revenue + danno reputazione + remediation). Il container non previene gli incident, li rende solo più veloci da risolvere se hai il runbook.

4. Container senza CI/CD

Un container aggiornato manualmente è un container che presto sarà obsoleto. Il setup minimo è Git push to deploy (Sevalla, Pressable), o WP-CLI + cron per aggiornamenti automatici (Kinsta). Senza automazione, il drift tra dev e production è garantito.

5. Scegliere managed per nascondere la mancanza di competenze

Se il tuo team non capisce l'architettura, il managed ti dà un'esternalizzazione operativa ma non ti fa crescere professionalmente. Il rischio è che in 3 anni il costo managed sia diventato un vincolo economico, e tu non abbia le competenze per migrare a self-hosted. Investi almeno il 10% del tempo in formazione DevOps del team.

Roadmap 90 giorni: dal sito singolo alla flotta container

Una sequenza operativa per adottare il container senza bruciare sei mesi.

Fase 1 (giorni 1-15): scelta architetturale

• Mappa i tuoi siti su una matrice: numero, visite/mese, workload AI, criticità, budget per sito.
• Decidi managed vs self-hosted basandoti sul TCO a 12 mesi (vedi sopra) e sulle competenze del team.
• Se managed: pilota Kinsta o Pressable su 3 siti rappresentativi. Se self-hosted: pilota Docker Compose su 5 siti rappresentativi.

Fase 2 (giorni 16-45): pilot operativo

• Migra i 3-5 siti pilota sull'architettura scelta.
• Configura backup, monitoring, runbook incident.
• Misura: TTFB, uptime, tempo di manutenzione settimanale, costo mensile effettivo.

Fase 3 (giorni 46-90): rollout e ottimizzazione

• Migra il resto dei siti a blocchi di 5-10 per settimana.
• Ottimizza: edge cache, image optimization, security headers, monitoring alert.
• Documenta il runbook e forma il team sulle operazioni di base (deploy, rollback, restore da backup).

FAQ: container hosting WordPress nel 2026

Cos'è esattamente un container WordPress?

Un container WordPress è un'unità di esecuzione isolata che include PHP-FPM, Nginx (o Apache) e tutte le dipendenze necessarie per far girare WordPress. A differenza di una VM, il container condivide il kernel del sistema operativo host ma ha il proprio filesystem, process space e network namespace. Su un server con 20 container, ogni sito ha il suo ambiente isolato ma condivide il kernel.

Quando serve davvero un container e quando è over-engineering?

Il container serve quando gestisci 5+ siti sullo stesso server, quando hai workload AI on-edge, o quando la sicurezza cross-site è critica. Sotto i 5 siti, un hosting WP tradizionale è sufficiente. Sopra i 50 siti, Kubernetes o un managed host specializzato diventa necessario per la scalabilità operativa. La regola pratica è: 1-5 siti hosting tradizionale, 5-30 siti managed o Docker Compose, 30+ siti Kubernetes o managed enterprise.

Quanto costa un container hosting self-hosted a 12 mesi?

Per un'agenzia 20 siti, il self-hosted su VPS Hetzner o OVH costa circa 1.000-1.500 €/anno di infrastruttura + 60-80 ore di manutenzione annua. Il break-even con un managed host (Kinsta, Pressable) è a 15-20 siti se il valore orario dello sviluppatore è sopra i 50 €/ora. Sotto quella soglia, self-hosted è economicamente vantaggioso solo se il team ha competenze DevOps.

Kubernetes è davvero necessario per WordPress?

No, non per la maggior parte delle agenzie. Kubernetes diventa necessario sopra i 30-50 siti, o quando servono deployment multi-region, scaling automatico, o workload complessi (AI inference, ML pipeline). Per WordPress puro, un managed host o un setup Docker Compose è sufficiente nel 90% dei casi. Kubernetes è un investimento che si ripaga solo su scala enterprise.

Il container migliora le performance di WordPress?

Dipende dal carico. Su un sito con 50.000 visite/mese, il container dà isolamento e prevedibilità ma non migliora le performance di per sé. Su un sito con 500.000 visite/mese, il container permette di scalare PHP-FPM indipendentemente dal database, e lì il guadagno è misurabile (TTFB -20-30%). Su siti più piccoli, il guadagno è soprattutto operativo (backup, monitoring, isolamento).

Cosa succede se un container si rompe?

Dipende dall'orchestratore. Su Docker Compose, il container si riavvia automaticamente se hai restart: unless-stopped nella configurazione, ma se il problema è nel volume persistente (database corrotto, plugin che sovrascrive file core), il restart non risolve. Su Kubernetes, il pod viene riprogrammato su un nodo sano, ma il volume persistente segue l'errore. In entrambi i casi serve un runbook di incident response e un backup restore testato. Abbiamo trattato il workflow Salesforce+Kinta per un esempio di runbook automatizzato.

Come si integra il container con WP-CLI?

WP-CLI gira dentro il container PHP. Per usarlo da host, si esegue docker exec -it <container> wp <comando>. Su Kubernetes, si usa kubectl exec -it <pod> -- wp <comando>. La nostra guida WP-CLI 2026 copre i pattern operativi con container e automazione AI.

Conclusione operativa

Il container hosting WordPress nel 2026 è lo standard de facto per agenzie 5+ siti, ma non è una soluzione universalmente giusta. La scelta operativa dipende da numero di siti, competenze del team, workload AI, e budget a 12 mesi. La regola pratica è: 1-5 siti hosting tradizionale, 5-30 siti managed o Docker Compose, 30+ siti Kubernetes o managed enterprise. Su mrtux.it il framework si inserisce nel contesto più ampio di Pressable e MCP, Sevalla come alternativa PaaS, workflow Salesforce+Kinsta e WP-CLI 2026. L'adozione è una decisione di architettura, non di prodotto: misura il TCO a 12 mesi, pilota su 3-5 siti, rollout a blocchi, documenta il runbook e forma il team.

Riferimenti utili per approfondire

• Kinsta - Why Kinsta uses container-based hosting (and why it matters) - Architettura container Kinsta spiegata dal team engineering
• Pressable e MCP per WordPress: integrare AI nel hosting managed - Caso studio Pressable container + AI workload
• Sevalla hosting WordPress 2026: alternativa production a K8s - Architettura Sevalla e quando sceglierla su Kubernetes
• WordPress e LLM self-hosted nel 2026: come usare AI locale con Ollama, LM Studio e WP 7.0 - Sidecar pattern per workload AI on-edge
• WordPress e Salesforce: automatizzare il go-live via API Kinsta - Runbook automatizzato per deploy container
• WP-CLI nel 2026: guida completa con AI e automazioni - Pattern WP-CLI su container Docker e Kubernetes
• Docker Compose WordPress official image - Documentazione ufficiale Docker image WordPress
• K3s - Lightweight Kubernetes - Kubernetes lightweight per agenzie senza team DevOps
• LXC containers documentation - Specifica LXC usata da Kinsta
• MariaDB Docker official image - Image database production-ready
• Nginx reverse proxy configuration - Setup reverse proxy per multi-container
• Hetzner Cloud VPS pricing - Costo VPS per self-hosted container

L'approccio "aggiorno e vedo cosa succede" non regge più. Serve una procedura ingegneristica, ripetibile, con rollback misurato. In questa guida ti spiego il metodo che usiamo sui siti in produzione dei nostri clienti, con i punti di attenzione specifici introdotti dal 7.0.

Se vuoi invece una panoramica completa di tutte le novità, puoi leggere la nostra guida completa a WordPress 7.0. Qui ci concentriamo solo sull'operatività dell'aggiornamento.

I tre rischi specifici di WordPress 7.0

Prima di toccare la produzione, mappa i rischi concreti introdotti da questa release. WordPress 7.0 non è un aggiornamento incrementale: cambia abbastanza sotto al cofano da rendere insufficienti le checklist del 6.x.

• Stack non più compatibile — Il core richiede PHP 7.4 minimo e MySQL 8.0+. Hosting datati (PHP 7.2, MariaDB 10.2) vengono tagliati fuori. Verificare prima se il proprio provider ha già aggiornato la versione di PHP disponibile.
• Temi block-based con override profondi — I temi Full Site Editing che facevano largo uso di hook personalizzati su block templates possono rompersi a causa del nuovo Block Locking API. I layout che "forzavano" proprietà ora potrebbero entrare in conflitto.
• Plugin di terze parti non pronti — Molti plugin usano admin_print_footer_scripts, manage_posts_extra_tablenav e altri hook legacy. La nuova interfaccia DataViews può renderli invisibili o non funzionanti. Serve un audit plugin per plugin.

Architettura minima per aggiornare senza downtime

Prima ancora di pensare a "come aggiornare", serve un'architettura che lo permetta. Se il sito è su un singolo server condiviso senza staging, l'obiettivo zero downtime è irrealistico. Ecco cosa serve.

1. Un ambiente di staging vero, non una copia a mano

Lo staging deve essere una replica bit-per-bit della produzione: stesso PHP, stesso MySQL, stessi plugin, stesse versioni, stesso tema child. Se cloni a mano e ti dimentichi il file wp-config.php o il cron di sistema, stai facendo theatre, non devops.

Un setup minimo per iniziare: usa container Docker per PHP localmente e poi replica la configurazione sul server di staging. La parola chiave è parità ambientale: se produzione gira su PHP 8.2 con OPcache attivo, anche lo staging deve girare così.

2. Backup verificati e ripristinabili

Un backup che non hai mai provato a ripristinare non è un backup, è una preghiera. Prima dell'aggiornamento a 7.0:

• Backup completo di file e database, non incrementale
• Ripristino di prova su un terzo ambiente (anche locale) entro 7 giorni
• Conservazione off-site per almeno 30 giorni

3. Accesso SSH e WP-CLI sul server di produzione

Operare da browser con la pagina di aggiornamento del backend significa: timeout, lock parziali, modalità manutenzione che resta attiva se qualcosa va storto. Con WP-CLI puoi gestire tutto da terminale, anche su connessioni instabili. Verifica che wp --info risponda prima di iniziare.

La procedura operativa in 8 step

Una volta che l'architettura è in piedi, l'aggiornamento vero e proprio è una checklist ripetibile. Segui gli step nell'ordine indicato.

Step 1 — Audit plugin e temi

Scarica un export JSON di tutti i plugin e temi installati (wp plugin list --format=json). Per ognuno verifica:

• Data di ultimo aggiornamento: se >12 mesi, rischio alto
• Compatibilità dichiarata con PHP 8.x: se non c'è, rischio altissimo
• Test contro WordPress 7.0 RC4 su staging (WordPress.org rilascia i release candidate proprio per questo)

Step 2 — Clona la produzione sullo staging

Copia file + database. Modifica solo wp-config.php per puntare al nuovo DB e cambia gli URL in siteurl e home con WP-CLI:

# clona database di produzione sullo staging
wp db export /tmp/staging_db.sql --allow-root
scp /tmp/staging_db.sql staging:/tmp/
ssh staging 'wp db import /tmp/staging_db.sql --allow-root'

# aggiorna URL sullo staging
ssh staging "wp option update siteurl 'https://staging.example.com' --allow-root"
ssh staging "wp option update home 'https://staging.example.com' --allow-root"

Step 3 — Aggiorna prima plugin e temi sullo staging

Questo è il punto in cui emergono i conflitti reali. Aggiorna un plugin alla volta, testando dopo ognuno. Su WordPress 7.0 la regola è: se un plugin ha una versione compatibile con 7.0, prendila; se non ce l'ha, congelalo e documenta la deroga. I plugin bloccanti vanno sostituiti, non disattivati: una disattivazione silenziosa di un plugin SEO o di cache può rompere il sito in modi non immediatamente visibili.

Step 4 — Aggiorna il core a 7.0 sullo staging

Solo dopo che plugin e temi sono puliti. Usa WP-CLI con --skip-themes e --skip-plugins per isolare l'aggiornamento del core:

# aggiorna solo il core WordPress, lasciando stare plugin e temi
wp core update --skip-themes --skip-plugins --allow-root

# poi rilancia gli aggiornamenti di plugin e temi separatamente
wp plugin update --all --allow-root
wp theme update --all --allow-root

Step 5 — Test funzionali sullo staging

Non "visito la home e mi sembra ok". Serve un test funzionale:

• Login come editor, autore, amministratore: ogni ruolo vede il backend corretto?
• Crea un articolo di prova con tutti i blocchi che usi (cover, gallery, tabelle, group/columns)
• Effettua un acquisto di test se gestisci WooCommerce
• Controlla i log PHP (/var/log/php-fpm/) e gli errori 5xx su Nginx/Apache
• Verifica l'output dei form di contatto e delle newsletter

Step 6 — Misura i tempi

Sullo staging, cronometra quanto dura ogni fase. L'aggiornamento core su 7.0 su un sito medio è di circa 30-90 secondi, ma il delta arriva dalla cache: invalidazione oggetti, ricostruzione autoload, rigenerazione rewrite rules. Pianifica una finestra di 5-10 minuti per il "passaggio" in produzione.

Step 7 — Esegui l'aggiornamento in produzione

Quando staging è verde, ripeti la stessa sequenza in produzione. Sequenza comandi:

# 1. backup di sicurezza immediato
ssh prod "wp db export /var/backups/wp_pre70_$(date +%Y%m%d).sql --allow-root"

# 2. attiva manutenzione
ssh prod "wp maintenance-mode activate --allow-root"

# 3. aggiorna il core
ssh prod "wp core update --skip-themes --skip-plugins --allow-root"

# 4. aggiorna plugin e temi uno a uno
ssh prod "wp plugin update --all --allow-root"
ssh prod "wp theme update --all --allow-root"

# 5. disattiva manutenzione
ssh prod "wp maintenance-mode deactivate --allow-root"

La finestra in cui il sito mostra la pagina "Sito in manutenzione" è idealmente sotto i 60 secondi: il tempo necessario a scaricare il nuovo core, decomprimerlo, aggiornare il DB e spegnere la modalità. Per ridurla, puoi pre-scaricare il pacchetto del core sul server ed eseguire un aggiornamento "minore" da file system.

Step 8 — Smoke test post-aggiornamento

Subito dopo aver spento la manutenzione, esegui:

• Verifica HTTP 200 su homepage, una pagina interna, il backend (wp post list via WP-CLI)
• Controlla i log delle ultime 5 minuti: nessun errore fatale PHP o MySQL?
• Apri Chrome DevTools, disabilita cache, ricarica: la pagina risponde in <1s?
• Controlla che i cron di sistema siano partiti (wp cron event list)

Strategia di rollback: il piano B

Nonostante tutta la preparazione, può succedere che qualcosa si rompa. Avere un rollback misurato è la differenza tra un'ora di stress e un downgrade in 10 minuti. Le opzioni sono tre, in ordine di robustezza.

Confronto rapido delle tre opzioni di rollback

Prima di scegliere, valuta pro, contro e casi d'uso. La soluzione giusta dipende da quanto tempo hai e da quale rischio devi mitigare.