Container hosting WordPress 2026: isolamento AI e TCO reale

Il container-based hosting per WordPress è diventato lo standard de facto per chi gestisce più di dieci siti, ma la maggior parte delle agenzie lo tratta ancora come una scelta "troppo enterprise". È un errore di valutazione. I container risolvono tre problemi reali che il modello shared hosting o VPS tradizionale non risolve: isolamento delle risorse tra siti dello stesso account, sicurezza cross-site quando un cliente viene compromesso, e la possibilità di far girare workload AI on-edge senza saturare il PHP-FPM del sito principale. Capire quando serve un container e quando è over-engineering è la differenza tra un'agenzia che scala senza bruciare margini e una che paga 5.000 €/mese di infrastruttura per 30 siti che ne generano 3.000.

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