EmDash - Astro-Native CMS and WordPress Successor

No.

Astro can build static sites, but EmDash’s current templates use server output and live database queries. Published content does not become plain .md files by default, and content changes do not follow the normal static-site flow of:

edit Markdown -> git commit -> Astro build -> deploy static HTML

EmDash is better understood as a CMS layer for Astro.

In the default EmDash templates: nothing triggers a static rebuild, because there is no static rebuild in the publishing loop.

This is the important distinction:

Git-backed static Astro:
edit .md -> git commit -> CI/CD -> astro build -> static HTML deploy

Default EmDash:
edit in CMS -> save to database -> next request reads fresh content from DB

EmDash’s current templates use:

output: "server"

That means Astro is running as a server-rendered app. The route queries the EmDash database at request time through the live collection/query layer. When you publish a post in the CMS, the database changes; the next visitor request can see that published content without rebuilding the whole Astro site.

So EmDash is not replacing Git commits with “CMS publish triggers CI/CD.” It is replacing the static build publishing model with a live CMS database model.

The tradeoff is clear:

Could you build the hybrid version? Yes, but it is not the default. You would deliberately treat EmDash as a build-time data source, add static route generation, and trigger a deploy hook after content changes.

That hybrid path starts looking like:

EmDash admin -> database update -> webhook/deploy hook -> Astro static build -> Cloudflare Pages

But if the goal is fully Git-backed content history, that still does not replace:

Markdown file -> Git commit -> CI/CD

It only replaces the editor with a CMS and uses the database as the content source.

Yes. In the default templates, EmDash uses Astro server output:

output: "server"

That is Astro SSR in practical terms. The Astro route runs on the configured server runtime, queries the EmDash database, and renders the response. On Cloudflare, that server runtime is the Workers/Cloudflare adapter path. On the local Docker/Node path, it is Astro’s Node standalone server.

Monolith is server-rendered/dynamic too, but through a different architecture:

Monolith frontend = React + Vite app on Cloudflare Pages
Monolith API      = Hono backend on Cloudflare Workers
Monolith data     = D1/R2 by default

So both projects move away from “static files only”, but they do it differently.

The shortest version:

EmDash = Astro SSR CMS
Monolith = Cloudflare app with React frontend + Hono Worker backend
Git Astro = static build from committed content files

That is why publishing in EmDash does not naturally mean “trigger an Astro rebuild.” The running Astro server can read the updated database directly.

These are three different publishing models, not just three UI choices.

My practical take:

Pick EmDash if the site is Astro and the missing piece is a real CMS.
Pick Monolith if the goal is a ready-made Cloudflare blog platform.
Pick Git-backed Astro if durability, portability, and static output matter more than live CMS features.

For my own “offline PWA + R2 media + Git commit + Astro static build” idea, the Git-backed Astro model is still the cleanest publishing target. EmDash is interesting because it has many CMS building blocks that could inspire the editor/auth/media side, but I would still keep Git as the final content ledger if static output and rollback are the priority.

Not by default.

EmDash stores rich text as Portable Text JSON in the configured database. The CLI and client API include conversion paths that can accept or return Markdown, but the source of truth is not a folder of Markdown files.

That means:

Astro content collections = file-based Markdown/MDX
EmDash collections        = database-backed CMS content

They can coexist in one Astro project, but they are different content systems.

Not in the Git-backed static-site sense.

EmDash can be added to an Astro project and can render CMS-managed content through Astro routes. But it does not currently work as:

browser editor -> write .md files -> commit to Git -> Cloudflare Pages static rebuild

If that is the exact workflow, you still need a Git-backed CMS, custom GitHub/GitLab commit integration, or an export/sync layer around EmDash.

Conceptually close in CMS ambition, but architecturally different today.

The target workflow would be:

offline PWA editor -> IndexedDB drafts -> authenticated sync API
                  -> R2 media uploads
                  -> Markdown files committed to Git
                  -> Astro static build
                  -> Cloudflare Pages deploy

EmDash already has useful pieces for that direction:

• Astro integration;
• admin UI;
• media handling;
• auth and roles;
• content APIs;
• CLI;
• MCP automation;
• Cloudflare D1/R2 deployment;
• WordPress migration.

But the missing pieces are important:

• offline-first editor state;
• conflict resolution;
• Git commit/PR workflow;
• Markdown files as canonical content;
• static build trigger as the publishing boundary.

So EmDash is a strong reference and possible foundation, but not a turnkey version of that static publishing system yet.

I did not find evidence that PWA/offline editing is a core feature.

Treat EmDash as a web CMS admin, not as a local-first offline editor. To make it offline-capable, I would expect IndexedDB draft storage, an explicit sync queue, media upload retries, conflict handling, and clear separation between “saved locally” and “published”.

No. EmDash has its own @emdash-cms/auth package.

That package covers CMS auth needs such as passkeys/WebAuthn, OAuth, magic links, sessions, roles, and scoped access. Better Auth is a general-purpose auth framework we saw in projects such as FeedLog, Seeder, and CloudflareBase; EmDash is taking a first-party CMS-auth approach instead.

Hono is not the main abstraction in EmDash.

Hono is a lightweight web framework often used for Workers APIs, like we saw in Monolith. EmDash is centered on Astro integration and Astro-compatible server routes. So the comparison is:

Hono       = request router/framework
EmDash     = CMS layer for Astro
Better Auth = auth framework

They solve different problems and can appear together in other projects, but EmDash itself is not primarily a Hono app.

The Cloudflare template uses:

The Node/Docker path replaces those with SQLite and local filesystem storage.

For the basic Cloudflare deployment, EmDash does not need a third-party SaaS API key.

It needs Cloudflare account access and these resources:

For local/manual deployment, the easiest auth path is:

npx wrangler login

For CI/CD, use:

CLOUDFLARE_API_TOKEN
CLOUDFLARE_ACCOUNT_ID

The API token should be allowed to deploy Workers and manage the bindings used by the app.

Practical permissions:

If you pre-create the D1 database and R2 bucket manually, the CI token can usually be narrower. For first deployment/provisioning, keep D1 and R2 edit permissions available.

The Cloudflare template config looked like this in the repository:

{
  "name": "my-emdash-site",
  "main": "./src/worker.ts",
  "d1_databases": [{ "binding": "DB", "database_name": "my-emdash-site" }],
  "r2_buckets": [{ "binding": "MEDIA", "bucket_name": "my-emdash-media" }],
  "triggers": { "crons": ["* * * * *"] }
}

Sandboxed plugins are the extra paid-plan caveat:

"worker_loaders": [{ "binding": "LOADER" }]

You can leave that disabled if you do not need sandboxed plugin execution at the beginning.

The blocker was the local build path, not missing Cloudflare credentials.

This machine has:

Node 18.19.1
npm 9.2.0

EmDash expects a modern Node 22+ workflow. I used temporary Node 22 and pnpm 11 through npx, which was enough for dependency installation and some package builds, but not enough to get the whole workspace/template build into a clean running state.

What worked:

dependency install                     passed
docker compose config                  passed
emdash core package build              passed
@emdash-cms/auth package build         passed

What did not complete:

full workspace/template build -> stopped around the admin package build

The visible failure was that @tailwindcss/cli was not found in that local install/build state.

So the honest result is:

compose shape: verified
package-level builds: partially verified
running browser UI: not verified in this pass

If I were retrying locally, I would avoid the temporary npx Node shim and use a clean native Node 22/Corepack setup:

nvm use 22
corepack enable
pnpm install --frozen-lockfile
pnpm build
pnpm --filter emdash-demo seed
pnpm --filter emdash-demo dev

Then the expected admin URL is:

http://localhost:4321/_emdash/admin

Partly, but not exactly.

They share the modern Cloudflare-era publishing philosophy:

• no PHP/MySQL WordPress runtime;
• edge/serverless-friendly deployment;
• database-backed content;
• object storage for media;
• browser admin instead of Git-only editing.

But the center of gravity is different.

My short version:

EmDash   = WordPress concepts rebuilt for Astro and TypeScript
Monolith = complete Cloudflare blog/CMS product

If your starting point is “I have an Astro site and want a serious CMS layer”, EmDash is the more relevant project.

If your starting point is “I want a Cloudflare-native blog app ready to operate”, Monolith is more direct.

Your proposed workflow was:

offline PWA editor
-> local drafts
-> upload photos to R2
-> commit .md files to Git
-> Astro static build
-> Cloudflare Pages deploy

EmDash today is closer to:

Astro site
-> EmDash admin
-> SQL database content
-> Portable Text
-> server-rendered Astro routes
-> media in local storage or R2

So it has several useful pieces for that idea:

• Astro integration;
• admin UI;
• auth and roles;
• media handling;
• Cloudflare D1/R2 support;
• CLI;
• MCP endpoint;
• WordPress import tooling;
• plugin architecture.

But it does not provide the exact Git-centered publishing loop out of the box.

The missing pieces are:

So the verdict is:

EmDash is a strong CMS/admin foundation and reference,
but it is still meaningfully far from an offline PWA + Git-backed Astro static publishing system.

To make it match that setup, I would add a separate sync layer:

EmDash-like editor/auth/media UI
-> write images to R2
-> convert Portable Text or editor state to Markdown
-> commit Markdown/frontmatter to Git
-> trigger Cloudflare Pages static build

At that point, Git becomes the durable content history and the final site remains static, while the CMS is only the editing and publishing control plane.

It is enough to understand and test the local Node/SQLite deployment shape, but I would treat it as an advanced source-build compose.

For production, decide first:

For any production path, backups matter more than the container command. Preserve the database and uploaded media together.

EmDash exposes an MCP endpoint at:

/_emdash/api/mcp

It is meant for agent-assisted CMS work: reading and writing content, managing media, inspecting schema, handling taxonomies and menus, working with revisions, and managing transfer/import/export flows.

Access is token/scoped. Browser session cookies are not the MCP auth mechanism, which is the right separation for automation.