Primeiros passos

Entenda o que é o EmDash CMS, em qual stack ele foi construído e a melhor forma de lançar hoje um site oficial de conteúdo EmDash.

O que é o EmDash CMS

O EmDash CMS é apresentado publicamente como um CMS full-stack em TypeScript, construído sobre Astro e projetado para funcionar especialmente bem na Cloudflare. O produto mantém vários conceitos já conhecidos por quem vem do WordPress, incluindo:

  • coleções e tipos de conteúdo
  • taxonomias, menus e widgets
  • uma interface administrativa para editores
  • um modelo de plugins para estender o comportamento do site

A diferença é que o EmDash é construído em torno de ferramentas modernas de frontend, conteúdo tipado e opções de deploy nativas da Cloudflare, em vez de hospedagem PHP.

O que o diferencia de um CMS típico

Na documentação pública oficial e nos materiais do repositório, alguns pontos são consistentes:

  • o EmDash é nativo de Astro, não um SaaS separado chamado por API
  • usa TypeScript em toda a stack
  • foi projetado para ser portável entre nuvens
  • seu modelo de plugins é baseado em execução em sandbox nos isolates do Cloudflare Workers
  • usa conteúdo estruturado em vez de prender tudo a armazenamento HTML no estilo WordPress

Essa combinação é o que o torna interessante para um site de ecossistema público como emdashcmseverything.com.

Primeira versão recomendada para este site

Embora o EmDash suporte uma arquitetura de CMS em runtime, a melhor primeira versão deste site ainda é um site de conteúdo estático em Astro.

Para este projeto, a stack recomendada é:

  • Astro como framework do site
  • MDX para conteúdo longo e páginas de recursos
  • Cloudflare Pages para hospedagem de baixo custo
  • Git + edição com IA para publicação contínua

Esse é o ponto de partida certo porque seu site é principalmente:

  • documentação
  • FAQ e guias de migração
  • conteúdo de diretórios de plugins e templates
  • atualizações, tutoriais e educação de produto

Essas necessidades não exigem edição com banco de dados no dia um.

Por que não implantar o runtime completo do EmDash imediatamente

O EmDash pode rodar em Cloudflare Workers com D1 e R2, e isso é parte importante da proposta do produto. Mas, para este site, começar direto no runtime completo aumentaria custo de infraestrutura e complexidade de setup antes de trazer muito benefício.

A abordagem static-first oferece:

  • deploy rápido na Cloudflare Pages
  • revisão em Git mais simples e colaboração com IA mais fácil
  • sem necessidade de configurar auth admin ou storage no lançamento
  • caminho mais limpo para iterar em posicionamento e arquitetura da informação

Depois, se você precisar de fluxos editoriais no navegador, envios autenticados ou gestão de mídia mais avançada, pode mover seções específicas para um deploy completo do runtime EmDash.

Desenvolvimento local

O projeto atual está organizado de forma intencional:

  • src/ contém rotas, layouts e componentes reutilizáveis
  • docs/ contém o conteúdo MDX publicado

Isso mantém trabalho de conteúdo e trabalho de frontend claramente separados.

Execute localmente com:

npm install
npm run dev

Gere o build estático com:

npm run build

Deploy na Cloudflare Pages

Para o site estático atual, a Cloudflare Pages deve usar:

  • Comando de build: npm run build
  • Diretório de saída: dist

Isso entrega um site público com operação quase zero.

Quando migrar para Workers, D1 e R2

Os materiais oficiais do EmDash deixam claro que a stack de runtime é mais forte quando você precisa de comportamento real de CMS, especialmente:

  • atualizações de conteúdo em tempo real sem rebuild
  • coleções com banco de dados
  • edição administrativa no navegador
  • autenticação com passkey ou Cloudflare Access
  • armazenamento de mídia no R2
  • plugins em sandbox no Workers

Esse é o momento certo de evoluir de Pages-only para a plataforma completa do EmDash.

Próximos passos recomendados

Se você está lançando um site oficial do ecossistema EmDash, a ordem prática é:

  1. Publicar o site público com Astro e Cloudflare Pages
  2. Expandir docs, FAQ, guias de migração, páginas de plugins e templates
  3. Usar o site para validar posicionamento e fluxo de publicação
  4. Introduzir os recursos completos de runtime apenas quando os fluxos editoriais/ecossistema realmente exigirem