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

#Dé onde vem o nome EmDash?

O nome EmDash deriva do caractere tipografico “em dash” ( - ) - o travéssao que, em tipografia, marca uma quebra, uma mudanca ou uma continuacao. E um nomé adequado para um projeto que pretende marcar um ponto de viragem na historia dos CMS.

Para compreender o contexto temporal: o WordPress nasceu em 2003 como um fork do b2/cafelog e evoluiu ao longo de duas decadas. O EmDash, segundo a Cloudflare, foi desenvolvido em cerca de dois meses em 2026. Ainda mais notavel: a Cloudflaré admité abertamente qué agentes de IA escreveram uma parte significativa do código.

Um ponto técnicamente importante: o EmDash não contem uma única linha de código do WordPress. E 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 útilizada pelo WordPress. A licença MIT e 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 oferecé aquilo que se espera dé um CMS moderno: um painel dé 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 qué a equipa tomou.

O WordPress foi criado em 2003 em PHP, numa era em qué o modelo servidor-base de dados dominava 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 qué obras derivadas mantenham a mesma licença - a MIT permite útilizaçã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 dé objetos), D1 (base de dados SQLite na edge) e KV (armazenamento chave-valor). Não existé um servidor centralizado no sentido tradicional. O CMS é executado em funções distribuídas globalmente, mais perto do útilizador final.

Está 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 fácilita 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 dé uma base de dados centralizada. Para a biblioteca de média, o R2 oferecé armazenamento dé objetos compatível com S3, eliminando a necessidade de serviços dé alojamento de ficheiros separados.

#Painel dé administração e REST API

O painel dé administração do EmDash é uma aplicação web moderna, construída em componentes reútilizáveis. Embora funcional, está longe da maturidade do painel WordPress - que beneficia de duas décadas de iteração e feedback de milhões de útilizadores.

A REST API segue padrões modernos e suporta autenticação baseada em tokens. Cada tipo de conteúdo gera automáticamente 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 qué o EmDash introduz uma melhoria arquitetural genuína, é na segurança dos plugins. E está é, possívelmente, 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 dé 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 nessé 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 - essencialmenté 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 concedé apenas essas permissões.

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

Este modelo é conceptualmente semelhanté 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 dé 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: "editors@example.com",
        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 dé um ficheiro de manifesto que declaré as suas dependências e permissões. Para útilizadores, 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 destá abordagem dependerá da granularidade das permissões e da fácilidade com qué os útilizadores as compreendem. Sé o sistema apresentar avisos excessivamente técnicos, muitos útilizadores vão simplesmenté aprovar tudo - repetindo o padrão que sé 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 útiliza passkeys em vez de palavras-passe como padrão. Isto elimina completamenté ataques de forca bruta e credential stuffing - dois dos vetores dé 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 qué 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 desdé o inicio, não montada posteriormenté através de campos meta.

Independencia 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 desdé 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 definé 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 automáticamenté 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 conformé 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 dé agentes de IA

A arquitetura do EmDash suporta fluxos de trabalho em qué agentes de IA operam como útilizadores 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 qué a revisão humana é o passo final dé um processo largamenté automatizado.

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

#Caminho de migração a partir do WordPress

A equipa do EmDash reconhece que qualquer CMS qué aspire competir com o WordPress precisa dé 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 dé 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 qué 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 discussao: “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 útilizadores apontaram qué 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 dé o anúncio ter sido feito a 1 dé 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 qué um produto útilizável em produção.
• Fragmentação do ecossistema open-source: Alguns membros da comunidade WordPress argumentaram qué 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 cautelosamenté otimista, reconhecendo a credibilidade da Cloudflare enquanto sublinharam o longo caminho até à viabilidade como alternativa real ao WordPress.

#A perspetiva dé 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 qué 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 criticas arquiteturais teoricas.

A reflexao mais marcante do thread diz respeito ao problema de edicao e confianca. Mesmo qué 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é qué o dono dé um restaurante precise de verificar sé o bot atualizou o horario correto na página correta. Um botao de guardar num CMS requer mais passos do qué um prompt, mas esses passos são verificaveis. Essa verificabilidade importa para as pessoas que gerem negocios 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 qué a geração fez a coisa certa está longe disso.” Peatling questionou até esse “quase resolvida”: “Acho que ha um problema serio dos ultimos 10%, e na realidade e mais como 30% quando sé aumenta a complexidade é os requisitos.”

@AlxAndrws respondeu com resultados reais, afirmando ter construido multiplos sites AI-first em vez de WordPress desde janeiro, com “todas as metricas melhores.” A resposta de Peatling foi caracteristicamente pragmatica: “Conta-me mais sobré as ferramentas que usas… Estes sites acabam por ser usados e geridos por útilizadores finais ou por programadores? E essé o meu ponto.” Está questao vai ao cerne de todo o debate — demos técnicas e sites geridos por programadores não são o mesmo que produtos que proprietarios de negocios não técnicos operam diariamente.

@XanderSeb, programador WordPress dé atribuicao de marketing, expressou a frustracao dos mais técnicos: “O WordPress está a ficar muito para tras. Gostava que não fossé 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 discussao WordPress contra qualquer coisa: “O modelo de dados do WordPress e imperfeito. Mas da para trabalhar com ele, faco-o todos os dias. Nem tudo o que e imperfeito precisa dé um refactoring imediato e completo. Comeca pelo qué os útilizadores precisam. Retrocedé até a arquitetura.”

Este thread importa porque redireciona a conversa sobré 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 sé as pessoas que gerem sites diariamente — proprietarios de pequenos negocios, editores de conteúdo, equipas de marketing — não conseguem confiar qué 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 destá dimensão investe recursos no desenvolvimento dé um CMS alternativo é o posiciona explicitamente contra o WordPress, isso é um indicador direcional que merecé atenção.

O EmDash válida uma tese que muitos programadores web defendem há anos: qué 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 sé 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 sobré 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 entré a arquitetura do WordPress é aquilo qué 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 qué 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

Crié um projeto de teste com o EmDash. Exploré o painel dé administração, testé a API, construa um tema simples. Compreender as suas capacidades e limitações em primeira mão é mais valioso do que qualquer artigo dé 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á sé 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 é explicitamenté uma versão beta. Não existem garantias de estabilidade da API, não há plugins essenciais é 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 útilize.

#Manter a experiência em WordPress

O WordPress continuará a ser o CMS dominante duranté 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 porqué aborda problemas reais qué a comunidade WordPress conhece intimamente: segurança de plugins deficiente, performance que requer otimização constante, é uma stack tecnológica que mostra a 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 técnicamente superiores porque tem algo que nenhum projeto novo pode replicar rápidamente: um ecossistema de milhões de útilizadores, 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 porqué uma pessoa queria um blog mais simples. O EmDash foi criado porqué o maior CDN do mundo disse: E se construissemos o WordPress do zero em 2026?

Uma comparacao detalhada de funcionalidades entré 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