WordPress in locale: Local, DevKinsta o DDEV nel 2026

Il riflesso più frequente di chi decide di realizzare il proprio sito WordPress è anche quello che fa perdere più tempo e denaro: comprare immediatamente un piano hosting e iniziare a costruire direttamente in produzione, con il rischio concreto di pagare mesi di server mentre il sito è ancora un cantiere. Esiste un'alternativa più economica, più veloce e tecnicamente migliore: sviluppare WordPress in locale, sulla propria macchina, senza vincoli e senza canoni mensili. Questo articolo confronta i tre strumenti che oggi rappresentano lo stato dell'arte per farlo (Local, DevKinsta e DDEV), con un taglio pratico che tiene insieme la prospettiva del neofita e quella dello sviluppatore professionista.

Perché sviluppare WordPress in locale conviene davvero

L'idea di partire subito con un hosting nasce dalla convinzione (sbagliata) che lavorare in locale sia complicato. In realtà gli strumenti maturati negli ultimi anni hanno reso l'esperienza alla portata di chiunque sappia usare un computer, e i benefici sono concreti: niente costi finché il sito non va online, possibilità di sbagliare e ripartire da zero in pochi minuti, velocità di test molto superiore rispetto a un server condiviso, e soprattutto la libertà di provare temi, plugin e configurazioni senza il timore di rompere qualcosa di pubblicamente visibile.

• Risparmio reale: zero euro di hosting durante tutta la fase di sviluppo, che spesso dura settimane o mesi.
• Velocità: una pagina di amministrazione WordPress in locale risponde in millisecondi, non in secondi.
• Sicurezza: gli errori non sono pubblici e i dati sensibili non viaggiano in rete durante i test.
• Sperimentazione: si possono testare PHP 8.4, MariaDB, Redis e plugin sperimentali senza conseguenze.
• Backup banali: tutto il sito sta in una cartella, basta zipparla per archiviare uno stato.

Local, DevKinsta e DDEV: le tre soluzioni a confronto

Esistono molti modi per eseguire WordPress in locale, dai vecchi stack manuali (XAMPP, MAMP, WAMP) fino agli strumenti moderni che automatizzano tutto. In questa analisi ho selezionato le tre opzioni che oggi rappresentano effettivamente lo stato dell'arte: Local (di proprietà di WP Engine), DevKinsta (di proprietà di Kinsta) e DDEV (open source, governato dalla DDEV Foundation). Coprono tre filosofie diverse e ciascuno ha un pubblico ideale ben definito.

Local by Flywheel: la scelta più semplice per chi parte

Local è probabilmente lo strumento più installato per eseguire WordPress in locale al mondo. WP Engine, che lo possiede dal 2018, ha reso interamente gratuite tutte le funzioni un tempo a pagamento (a partire dalla versione 6.0 del 2021), incluse Live Links, MagicSync, Link Checker e i backup verso Google Drive e Dropbox. La filosofia è quella della semplicità assoluta: si scarica un installer, si clicca "Add Site", si scelgono versione PHP e tipo di server, e in circa sessanta secondi il sito è operativo con tanto di utente amministratore.

Quando Local è la scelta giusta

• Setup tra i più rapidi sul mercato: dall'installazione al primo sito WordPress funzionante in pochi minuti.
• Nessun terminale richiesto: l'interfaccia grafica copre tutto, dal cambio versione PHP alla gestione SSL.
• Architettura leggera: usa servizi nativi (Lightning Services), niente Docker, consumo RAM minimo.
• Strumenti integrati: WP-CLI via Site Shell, Adminer per il database, Mailpit per testare le email.
• Live Links: funzione di tunneling integrata per condividere il sito locale con clienti o colleghi.

I limiti reali quando si cresce

• Nessun file di configurazione versionabile: due sviluppatori sullo stesso sito hanno in pratica due progetti diversi.
• Estendibilità limitata: aggiungere Redis, Solr o container custom richiede di uscire da Local.
• Push verso hosting solo Flywheel e WP Engine: chi usa altri provider deve esportare manualmente.
• Multisite supportato ma di seconda classe: i percorsi sottocartella richiedono ritocchi a wp-config.
• Bug ricorrenti su Apple Silicon recenti (M3 e M4) durante la creazione di nuovi siti.

DevKinsta: l'integrazione con l'ecosistema Kinsta

DevKinsta è gratuito, ben curato esteticamente, e ha una sola ragione strategica per esistere: integrarsi con l'hosting di Kinsta. Tecnicamente è un'interfaccia grafica costruita sopra Docker Desktop, con immagini preconfigurate per Nginx, PHP-FPM, MariaDB, Adminer e MailHog. La differenza rispetto a Local è che richiede obbligatoriamente Docker Desktop, e quindi eredita tutto il suo costo in termini di RAM e CPU.

Quando DevKinsta ha senso

• Si è già clienti Kinsta: il push verso lo staging è la funzione che giustifica la scelta.
• Interfaccia pulita e moderna, simile per stile al pannello MyKinsta.
• Tre flussi di creazione: nuovo sito, importazione da Kinsta (live o staging) e sito personalizzato.
• Email testing con MailHog dedicato per ogni sito, accessibile dall'interfaccia.
• Database manager via Adminer, raggiungibile con un clic.

I limiti che pesano nella pratica

• Docker Desktop obbligatorio: 3-4 GB di RAM solo per il motore, prima ancora di avviare un sito.
• Solo WordPress: chi sviluppa anche Drupal, Laravel o siti PHP custom deve usare un secondo strumento.
• Push diretto in produzione non disponibile: si può solo inviare allo staging Kinsta, da promuovere poi manualmente.
• Multisite non gestito da wizard: serve abilitarlo manualmente in wp-config.
• Su Apple Silicon con DevKinsta 2.13.x esistono ancora bug ricorrenti di tipo DK0066 in inizializzazione di MariaDB.

DDEV: il miglior compromesso per chi non teme il terminale

DDEV è l'unico strumento dei tre che sia veramente open source (licenza Apache 2.0) e non controllato da una società di hosting. È governato dalla DDEV Foundation, ha una community attiva di circa 20.000 sviluppatori settimanali e nel 2025 il progetto contava 376 contributori e 147 add-on community. La versione stabile attuale è la 1.25.1, rilasciata il 23 febbraio 2026. È lo standard de facto delle community Drupal e TYPO3, e funziona altrettanto bene con WordPress.

Quello che cambia rispetto a Local e DevKinsta è la filosofia: DDEV non è un'applicazione con interfaccia grafica, è un binario da terminale che orchestra container Docker secondo una configurazione descritta in un file YAML. Quel file (.ddev/config.yaml) si committa nel repository del progetto, e qualsiasi collaboratore lo cloni avrà un ambiente di sviluppo identico al tuo, sia che lavori su macOS, Windows o Linux. Per un'agenzia o un team distribuito questa è una funzione che da sola giustifica il passaggio.

Configurazione di un progetto WordPress in pochi comandi

Una volta installato il binario ddev (via Homebrew, apt, o l'installer Windows ufficiale), creare un sito WordPress da zero richiede pochi comandi:

1# Crea la cartella del progetto
2mkdir miosito-wp && cd miosito-wp
3 
4# Inizializza la configurazione DDEV per WordPress
5ddev config --project-type=wordpress
6 
7# Avvia i container (la prima volta scarica le immagini)
8ddev start
9 
10# Scarica WordPress e completa l'installazione via WP-CLI
11ddev wp core download
12ddev wp core install \
13  --url='$DDEV_PRIMARY_URL' \
14  --title='Il mio sito' \
15  --admin_user=admin \
16  --admin_password=admin \
17  --admin_email=admin@esempio.com
18 
19# Apre direttamente il pannello di amministrazione
20ddev launch wp-admin/

Il file di configurazione che si genera è leggibile e modificabile direttamente. Un esempio tipico per un progetto WordPress con PHP 8.3 e MariaDB 10.11:

1name: miosito-wp
2type: wordpress
3docroot: ""
4php_version: "8.3"
5webserver_type: nginx-fpm
6database:
7  type: mariadb
8  version: "10.11"
9performance_mode: mutagen
10additional_hostnames:
11  - dev
12  - staging-locale

Performance reali su macOS, Windows e Linux

Sui sistemi macOS e Windows il vero collo di bottiglia di qualsiasi soluzione basata su Docker è la sincronizzazione dei file tra host e container. DDEV risolve il problema con Mutagen, una cache asincrona che migliora le operazioni di lettura e scrittura di un fattore tra 10x e 50x. I benchmark ufficiali pubblicati dal team DDEV mostrano che un'installazione completa di Drupal 10 (un test molto pesante perché tocca filesystem e database in modo intensivo) si completa in 25-40 secondi con Mutagen attivo, contro i 60-80 secondi senza. Su un sito Magento 2 con dati di esempio, la sincronizzazione iniziale richiede 48 secondi, mentre gli avvii successivi scendono a 12 secondi su Apple M1. Su Linux e WSL2 i bind mount nativi sono già abbastanza veloci, quindi Mutagen è disattivato di default.

Su macOS la variabile più importante non è DDEV ma il provider Docker scelto. Confronto sintetico tra le due opzioni più rilevanti:

Setup su Windows con WSL2: la configurazione consigliata

Su Windows la combinazione che offre le prestazioni migliori è installare DDEV all'interno di una distribuzione WSL2 (Ubuntu è la scelta più collaudata). C'è un dettaglio cruciale che fa la differenza tra un'esperienza fluida e una frustrante: la posizione del progetto sul filesystem. I file devono stare in /home/utente/progetti, non in /mnt/c. Il motivo è semplice: il filesystem WSL2 nativo è veloce, mentre l'attraversamento del confine verso il filesystem Windows attraverso /mnt/c è lentissimo, al punto che un comando come ddev composer install può durare oltre mezz'ora invece dei normali quaranta secondi.

• Abilitare WSL2 e installare Ubuntu come distribuzione predefinita.
• Installare Docker Desktop con backend WSL2 (oppure Docker-CE direttamente dentro Ubuntu per uno stack 100% open source).
• Lanciare l'installer ufficiale ddev per WSL2 (script PowerShell), che configura mkcert e CAROOT in modo coerente.
• Spostare o creare i progetti dentro /home/utente/progetti dentro WSL2.
• Aprire la cartella del progetto da VS Code con l'estensione "Remote - WSL" attiva, per editing nativo.

1# Dentro Ubuntu (WSL2), in una shell pulita
2 
3# Aggiornare il sistema
4sudo apt update && sudo apt upgrade -y
5 
6# Installare le dipendenze necessarie
7sudo apt install -y curl wget git
8 
9# Aggiungere il repository ufficiale di DDEV
10curl -fsSL https://pkg.ddev.com/apt/gpg.key.public | \
11  sudo gpg --dearmor -o /etc/apt/keyrings/ddev.gpg
12echo "deb [signed-by=/etc/apt/keyrings/ddev.gpg] \
13https://pkg.ddev.com/apt/ * *" | \
14  sudo tee /etc/apt/sources.list.d/ddev.list >/dev/null
15 
16# Installare DDEV
17sudo apt update
18sudo apt install -y ddev
19 
20# Verificare l'installazione
21ddev --version
22 
23# Posizionarsi nella propria cartella di lavoro WSL2
24cd ~ && mkdir -p progetti && cd progetti

HTTPS locale con mkcert su WSL2

Per ottenere certificati SSL fidati anche dal browser di Windows, la procedura corretta installa mkcert sia sul lato Windows sia dentro WSL2, e propaga il percorso CAROOT attraverso la variabile WSLENV. È la parte più delicata del setup, e una volta configurata funziona per ogni progetto futuro senza ulteriori interventi:

1# Su Windows, in PowerShell come amministratore
2choco install mkcert
3mkcert -install
4 
5# Esportare CAROOT verso WSL2
6$env:CAROOT = mkcert -CAROOT
7setx CAROOT $env:CAROOT
8setx WSLENV "CAROOT/up:$env:WSLENV"
9 
10# Riavviare il terminale, poi dentro Ubuntu (WSL2):
11sudo apt install -y libnss3-tools
12mkcert -install
13 
14# Da questo momento ogni "ddev start" produce un sito
15# con HTTPS valido sia nel browser Linux che in quello Windows.

Come scegliere lo strumento giusto: tre profili tipici

L'evoluzione tipica di un team di sviluppo WordPress

Negli ultimi anni il percorso che ho osservato in molti studi e agenzie è abbastanza ripetitivo, ed è utile per capire dove ci si trova oggi rispetto a dove probabilmente si arriverà in futuro:

L'altra strada: affidarsi a uno sviluppatore WordPress

Tutto quello che ho descritto sopra è alla portata di chiunque abbia voglia di studiare. Se però l'obiettivo non è imparare ma avere un sito che funziona bene, il calcolo cambia: il tempo che si spende a configurare un ambiente locale, debuggare un container che non si avvia o capire perché HTTPS non funziona è tempo che non si dedica al proprio lavoro vero (vendere, scrivere, produrre, gestire clienti). Per molti professionisti il bilancio economico tra fare da soli e affidarsi a uno sviluppatore WordPress è meno scontato di quanto sembri, e la differenza si misura in settimane di tempo recuperato.

Nessuno strumento, per quanto ben fatto, sostituisce le decisioni di architettura che fanno la differenza tra un sito veloce e un sito che si trascina. La parte tecnica è automatizzabile, quella strategica no.

Se stai valutando se realizzare il tuo sito WordPress da solo o affidarti a chi lo fa di mestiere, posso darti una valutazione onesta basata sul tuo caso specifico, senza obbligo di proseguire. In molti casi il modo più veloce per evitare errori costosi è una conversazione di mezz'ora con qualcuno che li ha già visti tutti.