EmDash is the open-source CMS released by Cloudflare — written in TypeScript, built on Astro, and running on Cloudflare's edge infrastructure. It launched this year and immediately sparked the question: can it really compete with WordPress? We decided not to argue in theory, but to build something with it — and this article is what came out of that.
In two days we shipped: a full blog with hierarchical categories, tags, author profiles and series; a shop with products, add-ons and orders; a PWA with an offline mode; and a bilingual (Georgian/English) site with a Georgian admin panel. Everything you see in this article was created by an AI agent through EmDash's built-in MCP server.
Why EmDash and not WordPress
WordPress powers a huge part of the internet today, and that is impressive. But for us as an agency the real question is different: what does owning a site cost — not building it, but running it every day?
WordPress needs a PHP server, a database, a caching layer, security patching, backups and updates for the dozens of plugins that nobody really checks. EmDash needs none of that: content lives in D1, files in R2, and pages are served from more than 300 Cloudflare data centres. You no longer think about server upgrades, traffic spikes or DDoS — that is Cloudflare's problem, not yours.
We compared the two systems in detail in a separate article. Here we focus on what we actually saw while working.
What we built — with real numbers
The blog
- 12 themed articles in two languages — 24 entries in total, each with its own revisions
- 7 categories with hierarchy — for example “Cloudflare” nested inside “Engineering”
- 14 tags, 3 author profiles (bylines) with avatar and bio
- Series — articles grouped into thematic cycles with automatic part navigation
- Search, category/tag/series archives, pagination, RSS, previous/next article
- Related articles by tag — automatic, no manual curation
The shop — no payments, but real logic
- 12 products: t-shirts, hoodies, a cap, bags, stickers, mugs, magnets
- Nested categories: clothing → t-shirts / hoodies; accessories → caps / bags / stickers
- Per-product add-ons — engraving, gift wrapping, a sticker pack (the “I want the sauce too” principle)
- Cart in the browser (localStorage), quantity changes, free delivery over 100 GEL
- An order form that drops the order straight into the admin panel — into the Orders collection
- Stock handling, old price and discount badge, “out of stock” state
The PWA and the technical bits
- A full favicon set, app icons, a manifest and a service worker
- An offline page — the site opens without a connection
- A Georgian admin panel (our contribution to EmDash — the Georgian locale is already merged in their repo)
MCP — the quiet hero that makes EmDash different
MCP (Model Context Protocol) is the protocol AI agents use to talk to external systems. EmDash ships with a built-in MCP server — a rarity in the CMS world. The site exposes its own MCP endpoint, and authorisation happens with an API token you create in the panel (prefix ec_pat_).
On our instance 59 tools are active, grouped like this: content (create/edit/publish/schedule/translations), schema (collections and fields), taxonomies and terms, the media library, menus, authors, revisions, search and settings.
What did we do with it in practice? The agent created the whole blog schema — collections, fields, hierarchical taxonomies, authors — through MCP. Then 24 articles, 12 products, 4 add-ons, categories and tags, media images, menu items — all through MCP calls, without a single click in the panel. That is the difference between “a CMS” and “an automatable CMS”.
What does that mean for a business? Three things: (1) migration from another CMS can be fully automated; (2) bulk content updates — price changes, translations, badge updates — become a script instead of manual work; (3) an AI agent can manage the site like a human editor, only much faster.
For us MCP turned out to be not “another feature” but the main reason we chose EmDash for our projects.
Architecture: how all of this is put together
EmDash runs on Astro — a modern framework that renders pages on the server and ships minimal JavaScript to the browser. That is why the site is fast: our pages score 100/100 on Lighthouse.
- Collections — any content type (articles, products, orders) with your own fields: text, number, date, file, list, relation to another collection
- Portable Text — content stored as structured blocks; you can add custom block types (we added statistics, showcase and CTA blocks)
- Taxonomies — categories, tags, any other classification; hierarchy supported
- Locales — every entry has a locale and a “translation group” that links the Georgian and English versions; hreflang and the language switcher work automatically
- Drafts and revisions — every save stays in the history; you can roll back to an older version
- Roles — admin, editor, author; who sees what is managed from the panel
- Media — images in R2, automatic optimisation, blurhash placeholders (a blurred sketch appears before the image loads)
- API — a REST API for everything the panel does; MCP is built on top of it
The main architectural bonus is that the site and the panel are one project. There is no separate “backend” — code and content live together, and deploying is a single command.
The free plan in reality — where it breaks
This is the most practical part, and it needs numbers. Cloudflare's free plan looks like this:
- 100,000 requests per day — we use about 10,000 (10% of the limit), so no problem here
- 10 milliseconds of CPU time per invocation — and this is where things get interesting
- D1 database: 5 million reads and 100,000 writes per day, 5 GB of storage
- R2 storage: 10 GB of files, egress is free
Here is the catch: for an ordinary visitor the site works beautifully — pages load in milliseconds. But the admin API is much “heavier” — a single call performs many database operations, and 10 milliseconds is right at the edge for that.
While we were creating 24 articles, 12 products and dozens of images — hundreds of parallel requests, with cold starts after every deploy — the panel API and MCP sometimes returned 503 errors: “Exceeded CPU Limit” (code 1102). The site kept working; the panel did not.
What did we do? We wrote the data directly into the database, in exactly the shape EmDash writes it (entry + revision + taxonomy links). It worked, but it is not a normal way to work — content should be managed from the panel, not with SQL.
Conclusion: for a blog, a small site and its visitors the free plan is more than enough. But if you work in the panel actively (or run an agent, like we do), the $5 Workers Paid plan is practically mandatory — the CPU limit jumps from 10 milliseconds to 30 seconds and the problem disappears for good.
Strengths — what we genuinely liked
- Zero maintenance — no server, no PHP, no plugin updates, no security patching
- MCP + a complete API — automation and AI-agent management out of the box
- Speed — Cloudflare's edge, 100/100 Lighthouse, DDoS protection and SSL for free
- Built-in multilingual support — not a plugin but part of the system (two languages for us, more if needed)
- Structured content — collections and taxonomies give you what WordPress needs ten plugins to assemble (and still does not fully)
- Revisions, drafts, roles — an editorial workflow inside the panel
- Open source (MIT) — you can run it on your own server with Postgres, without Cloudflare at all
- Price — our site runs for 0 GEL
Weaknesses — where we struggled
- It is a young project. Version 1.0 has not shipped yet; the docs lag behind in places, you will not find answers on Stack Overflow, and examples are scarce. A lot has to be learned by trial and error.
- The admin API's CPU usage sits right at the free plan's limit (detailed above).
- The ecosystem is small. It cannot match WordPress's 60,000 plugins and thousands of themes — many things you build yourself (our shop, for example).
- There is no page builder. Content is written as structured blocks, not dragged and dropped. For a marketing team used to Elementor, that is a change.
- There is no shop out of the box. No WooCommerce equivalent — orders, cart and products are something you assemble yourself (as we did).
- Small traps: some field names are reserved (
status), a schema change has to be recorded in two places (the seed file and the live database), and the Georgian locale has not landed in the official npm release yet (our PR is merged — we are waiting for the release). - Plugin sandboxing only works on the paid plan — on free you cannot run third-party plugins.
Who it fits — and who it does not
A good fit: companies with a developer (or an agent, as in our case); multilingual content sites; blogs, documentation, catalogues; anyone already on Cloudflare; and anyone interested in automation and AI-agent management.
A poor fit: a marketing team that needs a drag-and-drop builder; a site that depends on 20 WordPress plugins; a full shop with ready-made payments and delivery logic (that needs separate work).
In our view EmDash is today the best choice for those who want speed, zero technical maintenance and modern automation at the same time — and who are not afraid of being an early adopter of a young project.
What we are doing next
For us those two days were not a “test” — they were building our own service. We offer three things: migration from WordPress to EmDash (keeping content, media and SEO), managed hosting (domain, SSL, backups, monitoring), and an AI content autopilot — when the site fills itself with content and you only review it.
The site you are reading right now is built on exactly this technology — and it is our live demo. If you are interested, write to us — you will get a concrete offer within one working day.
