Cosa ho imparato usando EmDash in produzione

Ho raccontato perché ho scelto EmDash per costruire fnbit.net: un CMS nativo per Astro, integrato con Cloudflare, pensato per chi non vuole portarsi dietro il peso di WordPress solo per pubblicare articoli. Questo è il seguito naturale, dopo averlo usato davvero: cosa ha tenuto e cosa no, un mese dopo il lancio.

Cosa mi ha risparmiato

La differenza più immediata rispetto a WordPress o Strapi è il setup: zero server da gestire, zero database da mettere in piedi separatamente, zero plugin da configurare per far parlare CMS e frontend. EmDash gira nativamente sull'infrastruttura Cloudflare, quindi il deploy del blog e il deploy dei contenuti condividono la stessa piattaforma — niente webhook custom per sincronizzare due mondi separati come capita con WordPress headless.

La developer experience con Astro è quella pensata da zero per questo caso, non adattata: i content type mappano in modo diretto sui componenti Astro, senza il livello di traduzione che serve invece con un CMS generico come Strapi. Scrivere un nuovo tipo di contenuto e vederlo renderizzato è un ciclo molto più corto.

Anche i costi, finora, si sono comportati bene: essendo nativo Cloudflare, il pricing segue lo stesso modello a consumo del resto dello stack, senza un servizio extra da pagare a parte per il CMS.

Dove ho trovato i limiti

Il rovescio della medaglia è la maturità dell'ecosistema. EmDash è giovane: non esiste ancora la profondità di plugin che trovi in WordPress o la community di terze parti che trovi attorno a Strapi. Alcune cose che in un CMS più maturo prenderei "gratis" — un plugin SEO completo, un form builder visuale — qui le ho dovute costruire a mano dentro Astro.

Aggiornamento del 22 ottobre 2026: oggi parte di questo vuoto è coperto. La guida SEO di EmDash descrive funzioni integrate: pannello SEO per ogni voce (titolo, descrizione, immagine, canonical, noindex), meta Open Graph e Twitter Card, JSON-LD, sitemap, robots.txt e redirect. Per i moduli esiste il plugin @emdash-cms/plugin-forms (crea form, raccoglie le risposte, invia notifiche). Prima di scrivere codice su misura conviene controllare la pagina sui plugin.

Anche la documentazione, essendo un progetto recente, ha ancora dei buchi: per un paio di configurazioni ho dovuto leggere il codice sorgente invece di trovare la risposta pronta. Non è un problema bloccante, ma va messo in conto se il tempo per sperimentare è limitato.

Infine, essendo legato all'ecosistema Cloudflare, la portabilità è un tema aperto: se in futuro volessi spostare il blog altrove, il lock-in (seppur leggero) va considerato fin da ora, non scoperto dopo.

Va precisato che Cloudflare non è l'unico runtime supportato: la documentazione descrive anche il deploy su Node.js con SQLite, e per più istanze PostgreSQL o libSQL, con lo storage dei media su disco locale o su un servizio compatibile S3. La via d'uscita quindi esiste; il lavoro di migrazione riguarda soprattutto database e media.

Una nota su performance e costi

Non ho ancora numeri di lungo periodo da condividere con sicurezza, ma nel primo mese il sito è rimasto leggero: build veloci, nessun rallentamento percepibile lato editor, e la fattura Cloudflare non ha avuto sorprese rispetto alle stime iniziali.

Lo rifarei?

Sì, per questo tipo di progetto — un blog personale, contenuto testuale, un solo editor (io). Non lo consiglierei ancora a un cliente che ha bisogno di funzionalità enterprise mature oggi stesso, o a un team che non può permettersi di scrivere codice extra quando manca un plugin. Per chi invece costruisce su Astro ed è disposto a scambiare un po' di ecosistema in cambio di una DX molto più diretta, è la scelta più solida che ho provato finora. Se stai ancora decidendo, il confronto tra Strapi, EmDash e WordPress parte dalla domanda che conta: chi edita i contenuti.