EmDash, o CMS de código aberto da Cloudflare que quer substituir o WordPress

#De onde vem o nome EmDash?

O nome EmDash deriva do carácter tipográfico “em dash” ( - ), o travessão que, em tipografia, marca uma quebra, uma mudança ou uma continuação. É um nome adequado para um projeto que pretende marcar um ponto de viragem na história dos CMS.

Para perceber o contexto: o WordPress nasceu em 2003 como fork do b2/cafelog e foi amadurecendo durante mais de vinte anos. O EmDash, segundo a Cloudflare, foi desenvolvido em cerca de dois meses em 2026. O ponto mais marcante é outro: a própria Cloudflare admite abertamente que agentes de IA escreveram uma parte significativa do código.

Um ponto tecnicamente importante: o EmDash não contém uma única linha de código do WordPress. É um desenvolvimento inteiramente novo em TypeScript, sem qualquer base em PHP. Por isso, o EmDash está licenciado sob a licença MIT em vez da GPL utilizada pelo WordPress. A licença MIT é comercialmente muito mais permissiva - obras derivadas não precisam de ser publicadas sob a mesma licença, o que constitui uma vantagem significativa para empresas e produtos comerciais.

#O que é o EmDash

O EmDash é um sistema de gestão de conteúdos (CMS) full-stack, licenciado sob MIT, escrito em TypeScript e construído sobre o Astro. O projeto foi desenvolvido internamente pela Cloudflare e disponibilizado publicamente no GitHub na versão 0.1.0 - uma fase beta inicial.

Criar um novo projeto com o EmDash requer apenas um comando no terminal - sem descarregar ficheiros ZIP, sem configurar bases de dados manualmente:

npm create emdash@latest

A configuração principal faz-se no ficheiro astro.config.mjs, de forma análoga ao wp-config.php do WordPress, mas com tipagem é autocompletar do TypeScript:

// astro.config.mjs
import emdash from "emdash/astro";
import { d1 } from "emdash/db";

export default defineConfig({
  integrations: [emdash({ database: d1() })],
});

Na prática, o EmDash oferece aquilo que se espera de um CMS moderno: um painel de administração, uma REST API, uma biblioteca de média, um sistema de plugins e suporte para temas. A diferença fundamental em relação ao WordPress reside na sua stack tecnológica e nas decisões arquiteturais que a equipa tomou.

O WordPress foi criado em 2003 em PHP, numa era em que o modelo servidor-base de dados dominavá a web. O EmDash nasce num contexto completamente diferente: computação na edge, funções serverless, TypeScript como lingua franca do desenvolvimento web e frameworks modernos como o Astro que priorizam performance por defeito.

A licença MIT é outro ponto relevante. Ao contrário da GPL v2 do WordPress - que impõe que obras derivadas mantenham a mesma licença - a MIT permite utilização, modificação e distribuição praticamente sem restrições. Para empresas e programadores, está é uma diferença significativa em termos de flexibilidade comercial.

#Arquitetura e stack tecnológica

#Astro como fundação

O EmDash não é apenas “construído com Astro” - é distribuído como uma integração Astro. Isto significa que se instala num projeto Astro existente, beneficiando de todo o ecossistema: componentes em React, Vué ou Svelte no mesmo projeto, renderização estática por defeito, e island architecture para interatividade seletiva.

O Astro envia zero JavaScript ao cliente por defeito. Quando combinado com um CMS, isto traduz-se em páginas de conteúdo que carregam de forma quase instantânea, com pontuações de PageSpeed consistentemente entre 95 e 100.

#Implementação serverless e edge

O EmDash foi desenhado para funcionar na infraestrutura da Cloudflare - Workers, R2 (armazenamento de objetos), D1 (base de dados SQLite na edge) e KV (armazenamento chave-valor). Não existe um servidor centralizado no sentido tradicional. O CMS é executado em funções distribuídas globalmente, mais perto do utilizador final.

Esta abordagem elimina a necessidade de gerir servidores, configurar NGINX ou Apache, ou preocupar-se com escalabilidade vertical. A escalabilidade é horizontal é automática. Para quem já configurou ambientes WordPress em produção - com plugins de cache, CDN, otimização de PHP workers e gestão de base de dados - está simplificação é notável.

#Armazenamento de conteúdo

O conteúdo no EmDash é armazenado em formato JSON, não em tabelas relacionais como no WordPress. Cada entrada de conteúdo é um documento JSON com um esquema tipado. Isto facilita a integração com frontends JavaScript, pipelines de dados e sistemas de IA que consomem dados estruturados.

A base de dados D1 da Cloudflare funciona como SQLite na edge, o que proporciona consultas rápidas sem a latência típica de uma base de dados centralizada. Para a biblioteca de média, o R2 oferece armazenamento de objetos compatível com S3, eliminando a necessidade de serviços de alojamento de ficheiros separados.

#Painel de administração e REST API

O painel de administração do EmDash é uma aplicação web moderna, construída com componentes reutilizáveis. Embora seja funcional, ainda está longe da maturidade do painel WordPress, que beneficia de anos de iteração e feedback de milhões de utilizadores.

A REST API segue padrões modernos e suporta autenticação baseada em tokens. Cada tipo de conteúdo gera automaticamente endpoints CRUD, o que simplifica a integração com aplicações externas, frontends separados ou fluxos de trabalho automatizados.

#Segurança de plugins: a mudança mais significativa

Se há uma área em que o EmDash introduz uma melhoria arquitetural genuína, é na segurança dos plugins. E está é, possivelmente, a razão mais convincente para prestar atenção a este projeto.

#O problema do WordPress

No WordPress, um plugin tem acesso total ao sistema. Quando se instala um plugin, esse código pode ler e escrever na base de dados, aceder ao sistema de ficheiros, fazer chamadas de rede externas e executar código PHP arbitrário. Não existe isolamento. Um plugin malicioso ou comprometido pode, literalmente, tomar controlo total do site.

Está é a razão pela qual os plugins WordPress são o vetor de ataque mais frequente. Segundo dados de segurança da Wordfence e da Patchstack, mais de 90% das vulnerabilidades de segurança no ecossistema WordPress provem de plugins e temas de terceiros. Mais concretamente, o relatorio de segurança da Patchstack de 2025 revelou que 96% de todas as vulnerabilidades do WordPress nesse ano tiveram origem em plugins. O modelo de segurança do WordPress confia implicitamente em todo o código que e instalado.

#A abordagem do EmDash

O EmDash executa cada plugin num Dynamic Worker isolado - essencialmente um ambiente sandbox com permissões explícitas. Quando um plugin é instalado, declara as permissões de que necessita: acesso à base de dados, chamadas de rede, acesso a ficheiros específicos. O sistema concede apenas essas permissões.

Se um plugin de formulários de contacto solicitar acesso à base de dados de utilizadores sem razão aparente, o administrador é alertado. Se um plugin de galeria de imagens tentar fazer chamadas de rede para servidores externos, o pedido é bloqueado a menos que explicitamente autorizado.

Este modelo é conceptualmente semelhante ao sistema de permissões das aplicações móveis - quando se instala uma aplicação no telemóvel, é necessário aprovar cada permissão individualmente. O WordPress nunca implementou nada comparável.

#Implicações práticas

Eis um exemplo prático de um plugin EmDash. Repare na propriedade capabilities - o plugin declara explicitamente que precisa de ler conteúdo e enviar e-mails, e nada mais. No WordPress, um plugin equivalente teria acesso total ao sistema de ficheiros, à base de dados e à rede:

import { definePlugin } from "emdash";

export default () => definePlugin({
  id: "notify-on-publish",
  version: "1.0.0",
  capabilities: ["read:content", "email:send"],
  hooks: {
    "content:afterSave": async (event, ctx) => {
      if (event.collection !== "posts" || event.content.status !== "published")
        return;
      await ctx.email!.send({
        to: "[email protected]",
        subject: `New post published: ${event.content.title}`,
        text: `"${event.content.title}" is now live.`,
      });
      ctx.log.info(`Notified editors about ${event.content.id}`);
    },
  },
});

Para programadores de plugins, isto implica uma mudança de mentalidade. Cada plugin precisa de um ficheiro de manifesto que declaré as suas dependências e permissões. Para utilizadores, significa uma camada de proteção que simplesmente não existe no ecossistema WordPress.

Outro aspeto que falta no WordPress: também os temas são sandboxed no EmDash. No WordPress, os temas podem executar operações de base de dados, correr código PHP arbitrario e intervir profundamente no sistema. No EmDash, os temas são layouts Astro puros, sem acesso a operações de base de dados - um ganho de segurança significativo. Como a Cloudflare formula: “Plugins are securely sandboxed and can run in their own isolate, via Dynamic Workers.”

Dito isto, a eficácia real desta abordagem dependerá da granularidade das permissões e da facilidade com que os utilizadores as compreendem. Se o sistema apresentar avisos excessivamente técnicos, muitos utilizadores vão simplesmente aprovar tudo - repetindo o padrão que se observa nas permissões de cookies e políticas de privacidade.

#Detalhes que fazem a diferenca

Para além das grandes decisoes arquiteturais, o EmDash apresenta varias funcionalidades menores que demonstram a coerencia do projeto.

Autenticação por passkeys como padrão: O EmDash utiliza passkeys em vez de palavras-passe como padrão. Isto elimina completamente ataques de forca bruta e credential stuffing - dois dos vetores de ataque mais comuns contra instalacoes WordPress.

Conteúdo pay-per-use integrado: O EmDash suporta o cabecalho x402, um protocolo para conteúdo baseado em microtransacoes. Com isto, e possível vender artigos ou conteúdos individuais diretamente, sem necessidade de integrar plugins externos de paywall ou soluções de comercio eletronico.

Collections tipadas em vez de Custom Post Types: O que o WordPress conhece como Custom Post Types chama-se no EmDash “Collections” - colecoes de conteúdo tipadas e definidas por esquema, com suporte completo de TypeScript. A estrutura e claramente definida desde o inicio, não montada posteriormente através de campos meta.

Independência de plataforma: Embora o EmDash funcione melhor na infraestrutura da Cloudflare, não está limitado a ela. O projeto suporta plataformas de implementação alternativas e pode ser executado em qualquer infraestrutura que suporte funções serverless.

#Design nativo de IA

O EmDash foi desenhado desde o início com a integração de IA em mente. Isto não é um add-on ou um plugin posterior - está incorporado na arquitetura base.

#Esquemas tipados para consumo por IA

Cada tipo de conteúdo no EmDash possui um esquema TypeScript que define a sua estrutura de forma precisa. Quando um agente de IA ou um modelo de linguagem precisa de interagir com o conteúdo, pode consultar o esquema para compreender exatamente que campos existem, que tipos de dados são esperados e que relações existem entre entidades.

Ao contrário do get_post_meta() do WordPress - que devolve valores sem tipo e sem válidação - o EmDash permite consultar coleções de conteúdo com tipagem completa:

---
import { getEmDashCollection } from "emdash";
const { entries: posts } = await getEmDashCollection("posts");
---

{posts.map((post) => <article>{post.data.title}</article>)}

Para gerar automaticamente os tipos TypeScript a partir dos esquemas de conteúdo, basta executar:

npx emdash types

No WordPress, um agente de IA que queira criar um artigo precisa de navegar a REST API, interpretar os campos disponíveis (que variam conforme os plugins instalados) e lidar com inconsistências nos tipos de dados. No EmDash, o esquema é a fonte de verdade, e é tipado de forma rigorosa.

#Servidor MCP integrado

O EmDash inclui suporte nativo para o protocolo Model Context Protocol (MCP), que permite que ferramentas de IA - como o Claude, o Cursor ou outros ambientes de desenvolvimento assistido por IA - interajam diretamente com o CMS. Na prática, isto significa que se pode pedir a um assistente de IA para criar, editar ou publicar conteúdo diretamente no EmDash, sem necessidade de ferramentas intermediárias.

#Fluxos de trabalho de agentes de IA

A arquitetura do EmDash suporta fluxos de trabalho em que agentes de IA operam como utilizadores do sistema - com permissões definidas, acesso controlado e registo de todas as ações. Isto abre possibilidades para automatização de conteúdo, curadoria assistida por IA e fluxos editoriais em que a revisão humana é o passo final de um processo largamente automatizado.

Para quem já trabalha com WordPress e ferramentas de IA, sabe que a integração atual é frágil: plugins específicos, APIs não padronizadas e soluções ad hoc. O EmDash propõe uma abordagem estrutural a este problema.

#Caminho de migração a partir do WordPress

A equipa do EmDash reconhece que qualquer CMS que aspire competir com o WordPress precisa de oferecer um caminho de migração claro. O projeto inclui:

• Ferramentas de importação de conteúdo: Exportação de posts, páginas, categorias, etiquetas e média do WordPress para o formato de conteúdo do EmDash.
• Guias de portabilidade de temas: Documentação sobre como converter temas WordPress (PHP/HTML) para componentes Astro.
• Guias de portabilidade de plugins: Orientações para reescrever a funcionalidade de plugins WordPress comuns como plugins EmDash com o novo modelo de permissões.

O assistente de importação do WordPress funciona em três passos - Ligar, Rever e Importar - permitindo verificar o conteúdo antes de confirmar a migração:

Na prática, a migração de um site WordPress complexo para o EmDash é, neste momento, um exercício substancial. Temas precisam de ser reescritos. Plugins precisam de ser substituídos ou recriados. Funcionalidades específicas do ecossistema WordPress - como WooCommerce, ACF, Yoast SEO - não têm equivalentes no EmDash.

Para sites simples - blogs, páginas corporativas com poucas funcionalidades - a migração é viável. Para sites com plugins especializados, integrações complexas ou personalização profunda, a migração prematura seria um risco significativo.

#Reações da comunidade

O anúncio do EmDash gerou discussões intensas em várias plataformas. As opiniões dividem-se de forma previsível.

#Reações positivas

O thread no Hacker News atingiu mais de 650 pontos e mais de 480 comentarios nas primeiras 24 horas - um envolvimento invulgarmente elevado para um tema de CMS.

No Hacker News, vários programadores elogiaram a abordagem de plugins em sandbox como “o que o WordPress deveria ter feito há 15 anos”. A escolha do TypeScript e do Astro foi recebida com entusiasmo pela comunidade JavaScript, que há anos expressa frustração com a stack PHP do WordPress.

Joost de Valk, criador do Yoast SEO e figura influente no ecossistema WordPress, escreveu no seu blog uma análise equilibrada, reconhecendo que o modelo de segurança de plugins do EmDash representa um avanço genuíno, enquanto alertou que o ecossistema é tudo - e o WordPress tem um ecossistema de 20 anos. De forma notavel, de Valk escreveu no LinkedIn expressamente “Not an April Fools joke” e anunciou planos para construir sobre o EmDash.

Um programador recriou o classico tema WordPress Kubrick no EmDash como homenagem - completamente sem PHP. No Reddit, foi formulada uma observacao certeira que marçou a discussão: “WordPress won not because it was technically best, but because it had the biggest social moat.”

No Reddit, a discussão centrou-se na viabilidade de competir com o WordPress a longo prazo. Vários utilizadores apontaram que a história da web está repleta de “WordPress killers” que nunca conseguiram alcançar massa crítica.

#Reações críticas

As críticas mais comuns incluem:

• Dependência da Cloudflare: Embora o EmDash seja open-source, a sua arquitetura otimizada para Cloudflare Workers, D1 e R2 levanta questões sobre vendor lock-in. Pode ser executado noutras plataformas, mas a experiência será inevitavelmente inferior.
• Data do anúncio: O facto de o anúncio ter sido feito a 1 de abril gerou confusão inicial sobre se seria uma piada. Não era - mas a escolha da data foi, no mínimo, infeliz para um projeto que quer ser levado a sério.
• Maturidade do ecossistema: Com zero plugins de terceiros, zero temas da comunidade é uma base de código em v0.1.0, o EmDash é, neste momento, mais uma demonstração arquitetural do que um produto útilizável em produção.
• Fragmentação do ecossistema open-source: Alguns membros da comunidade WordPress argumentaram que os recursos investidos no EmDash seriam mais úteis se canalizados para melhorar o próprio WordPress.

O TechRadar é o Cybernews cobriram o anúncio com um tom cautelosamente otimista, reconhecendo a credibilidade da Cloudflare enquanto sublinharam o longo caminho até à viabilidade como alternativa real ao WordPress.

#A perspetiva de um profissional: o thread de Andy Peatling

A 4 de abril, Andy Peatling (@apeatling) — um programador profundamente envolvido no ecossistema de produtos WordPress — publicou um thread equilibrado no X que rapidamente se tornou a opiniao mais fundamentada de todo o discurso sobre o EmDash. Partilhado por Brad Williams e outros membros da comunidade WordPress, acumulou 96 gostos, 37 marcadores e 7.000 visualizacoes em dois dias.

O argumento central de Peatling e que o enquadramento “o WordPress está morto” não acerta no alvo. Escreve: “As ferramentas de IA da geração atual conseguem gerar um site tipo brochura. Não conseguem construir de forma fiavel um site complexo que funcione como um negocio real precisa.” A sua experiência diaria a construir neste espaco da a está afirmacao um peso que falta as críticas arquiteturais teoricas.

A reflexao mais marcante do thread diz respeito ao problema de edicao e confianca. Mesmo que a geração de sites por IA estivesse completamente resolvida, o problema de edicao permanece em aberto. “Basta usar um chatbot para fazer alterações” soa convincenté até que o dono de um restaurante precise de verificar se o bot atualizou o horario correto na página correta. Um botao de guardar num CMS requer mais passos do que um prompt, mas esses passos são verificaveis. Essa verificabilidade importa para as pessoas que gerem negócios nestas plataformas.

As respostas dividiram-se em campos previsiveis. @hedgecast concordou que “o problema de edicao é o verdadeiro. A geração está quase resolvida. Confiar que a geração fez a coisa certa está longe disso.” Peatling questionou até esse “quase resolvida”: “Acho que ha um problema sério dos ultimos 10%, e na realidade e mais como 30% quando se aumenta a complexidade é os requisitos.”

@AlxAndrws respondeu com resultados reais, afirmando ter construído múltiplos sites AI-first em vez de WordPress desde janeiro, com “todas as métricas melhores.” A resposta de Peatling foi caracteristicamente pragmática: “Conta-me mais sobre as ferramentas que usas… Estes sites acabam por ser usados e geridos por utilizadores finais ou por programadores? E esse o meu ponto.” Esta questão vai ao cerne de todo o debate — demos técnicas e sites geridos por programadores não são o mesmo que produtos que proprietários de negócios não técnicos operam diariamente.

@XanderSeb, programador WordPress de atribuicao de marketing, expressou a frustracao dos mais técnicos: “O WordPress está a ficar muito para tras. Gostava que não fosse assim, mas e… as pessoas técnicas estão a sair.” Mas @missamychan ofereceu a contra-narrativa que muitos leais ao WordPress partilham: “Tenho 5 dos meus sites em WordPress. Já experimentei outros, mas acabo sempre por fecha-los e voltar a fazer crescer os meus sites atuais.”

Peatling encerrou com uma frase que deveria ser o ponto de partida de toda a discussão WordPress contra qualquer coisa: “O modelo de dados do WordPress e imperfeito. Mas dá para trabalhar com ele, faço-o todos os dias. Nem tudo o que e imperfeito precisa de um refactoring imediato e completo. Começa pelo que os utilizadores precisam. Retrocede até a arquitetura.”

Este thread importa porque redireciona a conversa sobre o EmDash, afastando-a da arquitetura é aproximando-a da usabilidade. O EmDash pode ter melhor sandboxing de plugins, melhores esquemas de conteúdo e melhor integração com IA. Mas nada disso importa se as pessoas que gerem sites diariamente — proprietários de pequenos negócios, editores de conteúdo, equipas de marketing — não conseguem confiar que a ferramenta faz o que precisam de forma fiavel e verificavel.

#O que isto significa para o WordPress

Falémos com franqueza: o EmDash não vai substituir o WordPress a curto ou médio prazo. E há razões estruturais para isso.

#A escala do WordPress

O WordPress alimenta mais de 40% da web. Tem mais de 60.000 plugins no repositório oficial. Milhões de programadores sabem trabalhar com ele. Dezenas de milhares de empresas construíram negócios inteiros em torno do seu ecossistema. Está inércia - no sentido físico do termo - não se ultrapassa com uma arquitetura melhor.

#A relevância do sinal

Mas o EmDash é relevante não pelo que é hoje, mas pelo que sinaliza. A Cloudflare é uma empresa com 4.000 milhões de dólares em receita anual e infraestrutura em mais de 300 cidades. Quando uma empresa desta dimensão investe recursos no desenvolvimento de um CMS alternativo é o posiciona explicitamente contra o WordPress, isso é um indicador direcional que merece atenção.

O EmDash válida uma tese que muitos programadores web defendem há anos: que o modelo de CMS monolítico em PHP, com plugins que têm acesso total ao sistema, está arquiteturalmente ultrapassado. A questão nunca foi se alternativas iriam surgir, mas quando e por quem.

#Pressão competitiva saudável

Independentemente do sucesso do EmDash, a sua existência coloca pressão sobre a comunidade WordPress para resolver problemas estruturais que têm sido adiados: segurança de plugins, performance por defeito, integração com ferramentas de IA e modernização da stack tecnológica.

O WordPress 6.x já mostrou sinais de resposta com o Full Site Editing, o editor de blocos e melhorias na REST API. Mas a distância entre a arquitetura do WordPress é aquilo que o EmDash propõe é substancial. Colmatar essa distância sem quebrar a retrocompatibilidade - que é uma das maiores forças do WordPress - é um desafio técnico e político enorme.

#O que as agências e programadores devem fazer

Na wppoland.com, trabalhamos com WordPress diariamente e acompanhamos de perto a evolução do ecossistema de CMS. A nossa recomendação é pragmática:

#Experimentar, não migrar

Crie um projeto de teste com o EmDash. Exploré o painel de administração, teste a API, construa um tema simples. Compreender as suas capacidades e limitações em primeira mão é mais valioso do que qualquer artigo de opinião.

#Acompanhar o repositório

Adicioné o repositório GitHub do EmDash à sua lista de projetos observados. Acompanhé os releases, os pull requests é as discussões. O ritmo de desenvolvimento nos próximos 6-12 meses indicará se o projeto tem tração real ou se é mais uma iniciativa que perde fôlego.

#Não migrar sites de produção

Nenhum site de produção deve ser migrado para o EmDash neste momento. A v0.1.0 é explicitamente uma versão beta. Não existem garantias de estabilidade da API, não há plugins essenciais e a documentação está incompleta. Migrar produção para o EmDash hoje seria uma decisão arriscada e prematura.

#Investir em competências transferíveis

Independentemente do futuro do EmDash, as competências que este CMS valoriza - TypeScript, Astro, arquitetura serverless, APIs REST, esquemas tipados - são competências transferíveis que beneficiam qualquer programador web. Investir nestas áreas é uma aposta segura, independentemente do CMS que se utilize.

#Manter a experiência em WordPress

O WordPress continuará a ser o CMS dominante durante anos. Manter é aprofundar a experiência em WordPress - especialmente em áreas como performance, segurança e Gutenberg - é a decisão correta a curto e médio prazo. O EmDash pode ser o futuro, mas o WordPress é o presente.

#Conclusão

O EmDash é o projeto CMS mais interessanté a surgir nos últimos anos. Não porque esteja pronto para produção - não está. Mas porque aborda problemas reais que a comunidade WordPress conhece intimamente: segurança de plugins deficiente, performance que requer otimização constante, é uma stack tecnológica que mostra sua idade.

A Cloudflare tem os recursos, a infraestrutura é a credibilidade técnica para fazer deste projeto algo significativo. Mas recursos e credibilidade não são suficientes. O WordPress sobreviveu a dezenas de concorrentes tecnicamente superiores porque tem algo que nenhum projeto novo pode replicar rapidamente: um ecossistema de milhões de utilizadores, programadores e empresas.

A abordagem correta é observar com atenção, experimentar com curiosidade e decidir com prudência. O EmDash pode não substituir o WordPress, mas as ideias que propõe - plugins em sandbox, arquitetura serverless, design nativo de IA - vão inevitavelmente influenciar o futuro dos CMS. E isso, por si só, já é uma contribuição valiosa.

O WordPress foi criado porque uma pessoa queria um blog mais simples. O EmDash foi criado porque o maior CDN do mundo disse: E se construissemos o WordPress do zero em 2026?

Uma comparacao detalhada de funcionalidades entre o EmDash é o WordPress pode ser encontrada no nosso artigo complementar: EmDash vs. WordPress - comparacao de funcionalidades 2026.

Quer construir com Astro hoje? Saiba mais sobre os meus serviços de desenvolvimento Astro.

Fontes: Cloudflare Blog, GitHub EmDash, Phoronix, TechRadar, Joost de Valk, Cybernews