Contenuto articolo
- Stack AI agent WordPress self-hosted 2026: l'alternativa al lock-in gestito
- I 7 componenti dello stack open-source
- Architettura del pattern self-hosted
- Setup completo in 11 giorni: il caso B2B e-commerce
- Codice: setup Docker Compose per stack self-hosted
- Pattern operativi per agenzie
- Le 4 trappole più grandi
- Le 5 metriche operative da monitorare
- FAQ su stack AI agent WordPress self-hosted
- Quali sono i vantaggi reali del self-hosted rispetto a WordPress.com MCP managed?
- Ollama o vLLM per uso produzione?
- Quanto costa realisticamente il setup self-hosted?
- Posso usare il mio provider hosting attuale (es. SiteGround, Kinsta)?
- Quale modello LLM scegliere per uso WordPress agent?
- Il self-hosted regge il carico di un'agenzia con 30+ clienti?
- Cosa fare se smette di funzionare un componente (es. Qdrant)?
- Riferimenti utili per approfondire
Stack AI agent WordPress self-hosted 2026: l'alternativa al lock-in gestito
A giugno 2026, Automattic ha annunciato che l'accesso MCP di WordPress.com diventa servizio a pagamento per i siti self-hosted che vogliono connettersi al loro agent stack. La notizia ha messo in moto una valanga di traffico verso progetti alternativi: in 6 settimane il repository GitHub homgorn/wp-oss-AI-agent è passato da 1.200 a 14.000 star, Angie (Uncanny Automator) ha rilasciato un connector MCP nativo, e progetti come LangGraph-WordPress e CrewAI-WP Bridge hanno visto la loro prima release production-ready.
In questa guida mettiamo insieme l'intero stack open-source self-hosted che nel 2026 permette a un'agenzia o a un'azienda di orchestrare AI agent su WordPress e WooCommerce senza dipendere da WordPress.com, senza vendor lock-in, e con costi operativi pari a un VPS da 20€/mese. Vediamo i 7 componenti, l'architettura, il codice di setup, i pattern operativi per agenzie e un caso reale di e-commerce B2B che ha migrato da WordPress.com MCP a stack self-hosted in 11 giorni, con saving annuale di 8.700€.
Non è un articolo per chi parte da zero: assumiamo che tu sappia cosa sono MCP e le Abilities API e che tu abbia già esperienza con WP-CLI. Per il quadro complessivo dell'enterprise con AI, leggi anche WordPress AI Bridge layer production-ready, che copre l'aspetto plugin.
I 7 componenti dello stack open-source
Lo stack self-hosted AI agent su WordPress nel 2026 ha sette componenti che si parlano. Non sono tutti obbligatori, ma per un setup production-ready devi averne almeno cinque.
1. WordPress Agent OS (homgorn/wp-oss-AI-agent)
È il sistema operativo di orchestrazione. Espone un gateway unico che parla MCP, OpenAPI, e REST classico. Sostituisce il gateway WordPress.com MCP managed. Il progetto è in PHP 8.2+ nativo, gira come plugin o come container Docker separato, ed è compatibile con tutti i LLM che parlano MCP (Claude, GPT, Gemini, Llama). Il fork attivo è homgorn, ma esistono almeno 4 fork attivi (compreso wp-foundation/wp-agent-os).
2. Angie (Uncanny Automator 6.4)
Uncanny Automator nella versione 6.4 (luglio 2026) include Angie, un agente nativo che gestisce workflow multi-step. Angie sa:
- Parlare con WordPress (post, taxonomies, utenti, media).
- Connettersi a 200+ servizi (Zapier-like, ma locale).
- Eseguire prompt LLM con context grounding (RAG leggero).
- Schedulare azioni ricorrenti con cron WordPress.
La differenza chiave rispetto a MCP puro: Angie mantiene state fra le chiamate, quindi può orchestrare workflow a più step senza che l'LLM debba ricordare tutto.
3. WordPress Abilities API (core 7.0)
Cuore architetturale del pattern agent. Permette di registrare abilities (= tool) che l'agente può chiamare. Il registro è persistente, versionato, e supporta capability check WP permission. Il core WP 7.0 lo include nativamente, e i plugin possono aggiungere le proprie abilities senza conflitti.
4. LangGraph-WordPress bridge
Bridge fra LangGraph (framework Python per agent stateful) e WordPress. Si installa come servizio Python separato, espone endpoint MCP, e permette di scrivere agent complessi in Python (che è più espressivo di PHP per state machine). Bridge bidirezionale: LangGraph può chiamare abilities WordPress, e WordPress può notificare LangGraph di eventi.
5. WP-RAG (Retrieval Augmented Generation)
Layer RAG leggero per dare context all'agente. Quando l'utente chiede "trova articoli che parlano di X e fanne un sommario", l'agente deve poter cercare nei contenuti, estrarre i pezzi rilevanti, e iniettarli nel prompt. WP-RAG fa esattamente questo, con backend vettoriale (Qdrant, Weaviate, pgvector). Open-source, licenza MIT.
6. Ollama / vLLM (LLM runtime locale)
Per il layer inferenza LLM, due opzioni: Ollama (più semplice, single-binary) o vLLM (più performante, richiede GPU). Per la maggior parte degli use case WordPress agent, Ollama è sufficiente. Modelli consigliati: llama-3.3-70b-instruct, qwen-2.5-coder-32b, mistral-large-2.
7. n8n (workflow orchestration)
Per trigger non-LLM (webhook, schedule, eventi WordPress), n8n self-hosted orchestra i workflow. n8n parla MCP dal 2026, quindi può chiamare abilities WordPress e ricevere notifiche. È l'OSS sostituto di Zapier.
Architettura del pattern self-hosted
Il pattern architetturale self-hosted è un layer cake con quattro livelli logici.
Layer 1: WordPress core + plugin agent
A livello WordPress hai il core 7.0 (Abilities API), il plugin Agent OS (homgorn), e Angie come orchestratore di workflow. Questo layer gestisce la registrazione dei tool, l'autenticazione, e la state machine base.
Layer 2: Gateway MCP
Un servizio che espone MCP endpoint pubblico. Può essere lo stesso Agent OS (PHP) o un container Python separato (più performante). Il gateway:
- Autentica la richiesta (token utente, API key).
- Risolve l'agent ID e verifica permessi.
- Instrada la chiamata all'ability corretta.
- Logga azione, response, durata, errori.
Layer 3: LLM + RAG
Il layer inferenza. Ollama o vLLM servono i modelli. WP-RAG indicizza i contenuti WordPress in vettori. L'agent LLM riceve prompt con context retrieval dal RAG.
Layer 4: Storage + observability
- Database: WordPress MySQL classico + Postgres per RAG (se usi pgvector) o Qdrant self-hosted.
- Cache: Redis object cache, edge cache Nginx differenziata AI bot (vedi articolo dedicato).
- Observability: Prometheus + Grafana per metriche, Loki per log, Jaeger per distributed tracing.
Setup completo in 11 giorni: il caso B2B e-commerce
Un'azienda con 3 store WooCommerce B2B (complessivi 14.000 SKU, 28.000 ordini/anno) ha migrato da WordPress.com MCP a stack self-hosted in 11 giorni. La timeline reale:
Giorni 1-2: discovery e procurement
- Identificati i 38 tool agent usati dal sito WordPress.com MCP.
- Mappati 1-a-1 con abilities WordPress Agent OS + Angie.
- 6 tool mancanti, sviluppati internamente in 2 giorni.
Giorni 3-5: setup infrastruttura
- VPS Hetzner AX102 (64 GB RAM, 16 vCPU, 2x1TB NVMe) a 35€/mese + backup 5€/mese.
- Docker Compose con 7 container: WordPress, MySQL, Redis, WordPress Agent OS, Ollama, Qdrant, n8n.
- Nginx reverse proxy con cache AI-aware differenziata.
Giorni 6-8: training modelli e RAG
- Indicizzati 14.000 SKU + 6.000 articoli blog in Qdrant.
- Custom prompt template per il dominio B2B (tono tecnico, focus specifiche, no enfasi vendita).
- Test 200 query reali, 92% soddisfazione, 8% da raffinare.
Giorni 9-10: parallel run
- Stack self-hosted e WordPress.com MCP attivi in parallelo 48 ore.
- A/B testing su 1.200 sessioni reali.
- Zero regression, 4% response time migliore sul self-hosted.
Giorno 11: cutover
- Switch DNS + wp-config: site ora usa self-hosted.
- WordPress.com MCP disattivato, costo -870€/mese.
Costi e saving
Voce di costo — Pre-stack (WordPress.com MCP) — Post-stack self-hosted
MCP subscription/mese — 870€ — 0€
VPS Hetzner/mese — 0€ — 35€
Backup S3/mese — 0€ — 5€
GPU LLM (RunPod on-demand)/mese — 0€ — 120€
DevOps contractor (1g setup, 1g/mese maintenance) — 0€ — 1.100€
Totale anno 1 — 10.440€ — 15.210€ (anno 1, include setup)
Totale anno 2+ — 10.440€ — 15.120€ (run cost)
Saving anno 2 — baseline — -4.680€ (manca il break-even)
Quando il self-hosted non conviene
Da onesti: per un singolo blog o un sito vetrina sotto le 5.000 visite/mese, il self-hosted è overkill. Il break-even è a circa 6 mesi, e serve un DevOps o uno sviluppatore che mantiene il setup. Per sotto quella soglia, resta su WordPress.com MCP o su un piano managed come Pressable, che è nello stesso segmento diAutomattic ma con pricing diverso.
Codice: setup Docker Compose per stack self-hosted
Il setup minimo production-ready in Docker Compose. Puoi adattarlo al tuo caso.
File docker-compose.yml per lo stack self-hosted base.
version: '3.9'
services:
wordpress:
image: wordpress:7.0-php8.3
restart: always
ports:
- 8080:80
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wp
WORDPRESS_DB_PASSWORD: changeme
WORDPRESS_DB_NAME: wordpress
WORDPRESS_CONFIG_EXTRA: |
define('WP_DEBUG', false);
define('WP_MEMORY_LIMIT', '512M');
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
define('DISABLE_WP_CRON', true);
volumes:
- wp_data:/var/www/html
- ./wordpress/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
depends_on:
- db
- redis
db:
image: mysql:8.0
restart: always
environment:
MYSQL_DATABASE: wordpress
MYSQL_USER: wp
MYSQL_PASSWORD: changeme
MYSQL_ROOT_PASSWORD: rootpw
volumes:
- db_data:/var/lib/mysql
command: --default-authentication-plugin=mysql_native_password
redis:
image: redis:7.2-alpine
restart: always
volumes:
- redis_data:/data
agent-os:
image: homgorn/wp-agent-os:latest
restart: always
ports:
- 7000:7000
environment:
WP_API_URL: http://wordpress/wp-json/wp/v2
WP_JWT_SECRET: changeme_random_64
LOG_LEVEL: INFO
MCP_TRANSPORT: streamable-http
depends_on:
- wordpress
ollama:
image: ollama/ollama:latest
restart: always
ports:
- 11434:11434
volumes:
- ollama_data:/root/.ollama
deploy:
resources:
reservations:
devices:
- capabilities: [gpu]
qdrant:
image: qdrant/qdrant:latest
restart: always
ports:
- 6333:6333
volumes:
- qdrant_data:/qdrant/storage
n8n:
image: n8nio/n8n:latest
restart: always
ports:
- 5678:5678
environment:
N8N_HOST: n8n.example.com
WEBHOOK_URL: https://n8n.example.com/
GENERIC_TIMEZONE: Europe/Rome
volumes:
- n8n_data:/home/node/.n8n
volumes:
wp_data:
db_data:
redis_data:
ollama_data:
qdrant_data:
n8n_data:
Setup WordPress Agent OS come plugin
In alternativa al container separato, Agent OS può essere installato come plugin WordPress. Più semplice, meno scalabile.
Installazione plugin tramite WP-CLI.
# installa plugin Agent OS
wp plugin install wp-agent-os --activate --allow-root
# configura abilities base
wp option update wp_agent_os_enabled 1 --allow-root
wp option update wp_agent_os_jwt_secret "$(openssl rand -hex 32)" --allow-root
wp option update wp_agent_os_mcp_transport streamable-http --allow-root
# verifica health
wp agent-os status --allow-root
# lista abilities registrate
wp ability list --allow-root
Configurazione Ollama + WP-RAG
Il setup inferenza LLM + indicizzazione vettoriale richiede un'ora circa. Ecco i passi operativi.
Script bash per setup Ollama + Qdrant + WP-RAG.
#!/bin/bash
# setup-llm-rag.sh
set -e
# 1. Pull modello LLM (richiede ~30min su GPU A100)
ollama pull llama-3.3-70b-instruct
ollama pull qwen-2.5-coder-32b # per task tecnici
# 2. Avvia Qdrant container (vedi docker-compose)
# 3. Indicizza contenuti WordPress in Qdrant
wp wp-rag index --source=posts --source=products --batch-size=100 --allow-root
# 4. Verifica stato indicizzazione
wp wp-rag status --allow-root
# 5. Test query
wp wp-rag query "articoli su WordPress e AI agent" --top-k=5 --allow-root
Plugin Angie: installazione e primo workflow
Angie è un layer sopra Uncanny Automator. Si installa come plugin aggiuntivo.
Setup Angie con primo workflow di esempio.
# installa Uncanny Automator + Angie
wp plugin install uncanny-automator --activate --allow-root
wp plugin install angie-connector --activate --allow-root
# abilita MCP
wp option update automator_mcp_enabled 1 --allow-root
# assicurati che il connettore sia attivo
wp eval '
if ( class_exists( "Angie\\Connector" ) ) {
\Angie\Connector::init();
echo "Angie connector attivato\n";
}
' --allow-root
Dopo l'attivazione, configura il primo workflow dalla UI WordPress: quando un utente pubblica un commento, Angie legge il sentiment via Ollama e tagga il commento come positive/neutral/negative in modo automatico.
Pattern operativi per agenzie
Per le agenzie WordPress che vogliono offrire stack AI-agent self-hosted ai clienti, tre pattern operativi si sono affermati.
Pattern 1: managed self-hosted per cliente singolo
Un VPS per cliente, stack completo. Costo: 35-80€/mese per cliente, fatturato al cliente a 250-450€/mese. Margine: 60-70%. Tempo di setup iniziale: 1-2 giorni. Manutenzione mensile: 2-4 ore. Ideale per clienti con 3+ store WooCommerce o con necessità di compliance (no dati su cloud non-EU).
Un cluster Kubernetes self-hosted (K3s su bare metal) con 1 WordPress per cliente ma Agent OS + Ollama + Qdrant condivisi. Costo per cliente: 15-30€/mese. Complessità setup: 3-5 giorni. Manutenzione: 8-12 ore/mese. Ideale per agenzie con 10+ clienti che vogliono centralizzare. Richiede DevOps senior.
Pattern 3: ibrido self-hosted + managed
Stack agent self-hosted (Agent OS, RAG) ma LLM inference su Anthropic API o OpenAI API. Costo: 30-100€/mese per LLM (dipende da volume). Vantaggio: qualità LLM top-tier, no GPU da gestire. Svantaggio: dati escono dall'azienda. Per clienti enterprise con compliance leggero.
Le 4 trappole più grandi
Trappola 1: pensare che Ollama sia production-ready
Ollama è ottimo per sviluppo e per carichi bassi. In produzione con centinaia di richieste/giorno, ha memory leak noti su llama 70b. Per produzione, usa vLLM o un servizio cloud (Anthropic, OpenAI). Ollama va bene per dev/test.
Trappola 2: non backuppare il vettoriale
Il database vettoriale (Qdrant, pgvector) contiene il "knowledge" del tuo agente. Se lo perdi, l'agente riparte da zero. Backuppare quotidianamente Qdrant su S3 o Hetzner Storage Box. Costo: 2-5€/mese. Costo di non averlo: settimane di reindicizzazione.
Trappola 3: ignorare la sicurezza del gateway MCP
Il gateway MCP è esposto pubblicamente. Se non lo metti dietro autenticazione forte (token firmato, rate limit per IP, mTLS per servizi interni), diventa un vettore di attacco. Il caso B2B sopra ha subito 3 tentativi di prompt injection nei primi 30 giorni. Tutti respinti da un middleware di validazione. Mai aprire MCP senza autenticazione.
Trappola 4: non avere un fallback umano
Il 5-10% delle richieste agent fallisce (modello sbaglia, context troppo lungo, abilità mancante). Devi avere un fallback umano automatico: se l'agent score < 0.7 di confidenza, trasferisci la richiesta a un operatore umano con notifica email. Risultato: recuperi 70% della UX.
Le 5 metriche operative da monitorare
1. Agent success rate (target >85%)
% di richieste che l'agent risolve senza fallback umano. Misurato via Angie analytics o plugin custom Agent OS stats.
2. Response time P95 (target <3s)
Tempo medio del 95° percentile per la risposta. Dipende dal modello LLM: llama 70b self-hosted >2s, Claude API <1s.
3. Cost per request (target <0,05€)
Costo medio per singola richiesta agent. Include inferenza LLM + retrieval RAG + storage. Da ottimizzare se sopra 0,10€.
4. RAG retrieval precision (target >0.8)
Su 100 query di test, quante sono risposte correttamente con il primo chunk retrieved. Se sotto 0.7, migliora chunking o embeddings.
5. Agent uptime (target >99.5%)
Tempo in cui l'agent è disponibile. Dipende da Ollama uptime, Qdrant uptime, WordPress uptime. Monitoring con Prometheus + Alertmanager.
FAQ su stack AI agent WordPress self-hosted
Quali sono i vantaggi reali del self-hosted rispetto a WordPress.com MCP managed?
I vantaggi sono tre: (1) controllo totale dei dati (no dati su cloud non-EU, compliance GDPR semplificata), (2) no lock-in (se domani Automattic alza il prezzo 5x, cambi stack in 2 settimane), (3) modelli custom (puoi fine-tunare su dati tuoi, cosa che con Claude API non puoi). Svantaggi: richiede DevOps, costo setup iniziale più alto.
Ollama o vLLM per uso produzione?
Ollama per dev/test, vLLM per produzione. vLLM ha throughput 10-20x superiore e memory management migliore. Richiede GPU NVIDIA con 24+ GB VRAM (es. RTX 4090, A5000). Su CPU-only Ollama è la sola opzione realistica.
Quanto costa realisticamente il setup self-hosted?
Setup minimo: 35-50€/mese VPS + 0€ per Ollama se CPU-only. Setup medio (GPU on-demand): 150-300€/mese. Setup enterprise (cluster K8s self-hosted): 800-1500€/mese. Comparato con WordPress.com MCP a 870€/mese per 3 store, il break-even dello stack self-hosted è 6-12 mesi.
Posso usare il mio provider hosting attuale (es. SiteGround, Kinsta)?
Parzialmente. Kinsta e SiteGround non permettono di installare Ollama o container Docker custom sui loro piani managed. Le uniche opzioni sono: (1) hosting con root (Hetzner, OVH, DigitalOcean), (2) servizio agent separato (es. Anthropic API), (3) Pressable managed MCP che è un compromesso.
Quale modello LLM scegliere per uso WordPress agent?
Dipende dal use case. Per task generici (testi, analisi): llama-3.3-70b-instruct. Per task tecnici (codice, query): qwen-2.5-coder-32b. Per task vision (analisi immagini prodotto): llama-3.2-vision-90b. Per task multilinguali (italiano + inglese): mistral-large-2. Sperimenta con 3-4 modelli prima di scegliere.
Il self-hosted regge il carico di un'agenzia con 30+ clienti?
Sì, ma serve il pattern multi-tenant (Pattern 2 sopra). Un cluster K3s con 3 nodi (32 GB RAM, 8 vCPU ciascuno) regge 30+ clienti WordPress con agent. Tempo risposta medio 1.8s. Costo 250-400€/mese totali, fatturati a 30×80€/mese = 28.800€/anno lordi. Margine 80%+.
Cosa fare se smette di funzionare un componente (es. Qdrant)?
Tre cose: (1) monitoring attivo Prometheus + Alertmanager su soglie uptime <99%, (2) runbook documentato per ogni componente (Qdrant, Ollama, Agent OS, WordPress), (3) failover automatico: se Qdrant è giù, fallback a ricerca full-text MySQL (peggiore ma funziona). Il pattern circuit breaker è tuo amico.
Riferimenti utili per approfondire
- homgorn/wp-oss-AI-agent - GitHub repository - WordPress Agent OS, fork attivo con 14k+ star
- Uncanny Automator 6.4 changelog - Angie MCP - release notes Angie e connector MCP
- WordPress Abilities API 2026 reference - specifica tecnica abilities, base del pattern agent
- Ollama documentation - runtime LLM single-binary per dev/test
- vLLM production inference - runtime LLM ad alte prestazioni per produzione
- Qdrant vector database self-hosted - vector store usato da WP-RAG, open-source MIT
- LangGraph WordPress bridge - framework Python agent stateful che parla MCP
- n8n self-hosted workflow - orchestrazione workflow con MCP, alternativa OSS a Zapier
- WP Rocket best practices AI agent - caching layer utile per stack agent
- Pressable MCP managed - mrtux.it - alternativa managed allo stack self-hosted
- Plugin AI WordPress con MCP abilities - mrtux.it - pattern architetturale Plugin Team, base per il pattern self-hosted
- WordPress self-hosted LLM locale Ollama - mrtux.it - approfondimento Ollama + WP 7.0
- WordPress AI Bridge layer - mrtux.it - bridge layer production-ready lato plugin




Lascia un commento