EmDash and Vinext Shipped Hours Apart: The Portability Budget We Use Before Adopting a Vendor Stack

On September 28, 2026, Cloudflare released two products within two hours of each other: EmDash 1.0, an open-source CMS that puts your content layer on Cloudflare's runtime, and Vinext 1.0, a tool that detaches Next.js from any single host. One deepens the stack, the other buys you the exit. The right response to both is the same — not "which one is better," but a portability budget: decide in advance how much of your stack must be exportable, and prove it with an exit test before you adopt, not after you need to leave.

That is not a fence-sitting answer. It is the only position that survives what happened next: within days of the launch, WordPress founder Matt Mullenweg published a rebuttal calling EmDash a vehicle for selling Cloudflare services, while The Verge's coverage flagged that nobody could show a clean way to export a production EmDash site off Cloudflare. Both critiques land on the same blind spot every agency has: teams evaluate what a stack does on day one and never price what it costs to undo.

What shipped on September 28, and why the pairing matters

EmDash 1.0 went out at 13:00 UTC. It is a full-stack TypeScript CMS built on Astro, MIT-licensed, with three ideas doing the heavy lifting:

• Sandboxed plugins. Every plugin runs in an isolated runtime — a Dynamic Worker on Cloudflare, a workerd child process on Node.js — with no access to the site's content, media, secrets or network unless a manifest declares a capability and the site administrator approves it. The pitch is architectural: Cloudflare cites Patchstack's data that 96% of WordPress security issues originate in plugins, and that 2025 alone produced more high-severity vulnerabilities in the WordPress ecosystem than the previous two years combined.
• A registry that Cloudflare says it doesn't own. Plugin packages are published on the AT Protocol with publisher-signed records, so the catalog is a signed ledger rather than a private app store. The aggregator and moderation services are themselves open source.
• An agent-native surface. A built-in MCP server, Agent Skills, and an AI site builder called EmDash Build — the part aimed squarely at agencies shipping client sites with AI in the loop.

Vinext 1.0 followed at 14:51 UTC: a tool that runs any Next.js app — Pages Router or App Router — on Vite, so the same build deploys to Cloudflare Workers, Netlify or AWS Lambda. npx vinext check tells you if your project qualifies; npx vinext init converts it.

Same company, same day, opposite vectors. One product makes your content layer assume Cloudflare. The other exists specifically so a framework stops assuming a platform. A vendor shipping both is telling you exactly where its leverage and its fear live — and it is the cleanest possible setup for the question we actually care about: how deep should any single vendor's stack go?

The lock-in argument, with the evidence on both sides

Mullenweg's April 2 response to the original EmDash announcement is worth reading past the headlines: "I think EmDash was created to sell more Cloudflare services," he wrote, and, more sharply, "If you want to adopt a CMS that will work seamlessly with Cloudflare and make it hard for you to ever switch vendors, EmDash is an incredible choice." On plugin security, he argues the unrestricted power of WordPress plugins is a feature, not a bug — a position Joost de Valk countered with an analogy about arguing that because one phone app needs camera access, every app should get root.

Cloudflare's counter-evidence is not marketing: the code is MIT-licensed, the plugin sandbox demonstrably runs outside Cloudflare (same manifests, same capability APIs, workerd as a subprocess), and the registry protocol is not Cloudflare's to revoke. But The Verge's coverage raised the layer that open-sourcing does not solve: there is still no supported path to export a whole live site — content, media bindings, cache configuration, routing — and land it somewhere else unchanged.

Both sides are right about different layers, and that is the whole lesson:

License tells you about layer one. Lock-in lives in layers two and three. Almost every "it's open source, there's no lock-in" argument — from any vendor — quietly stops counting at layer one.

The portability budget: three layers, one exit test

We price stack decisions in three layers before recommending anything to a client. Each layer gets an explicit budget — how much of it we are allowed to bind to the vendor — and each layer has a test, not a promise.

1. Content portability. Can I get every entry out as structured files or JSON today, with the schema intact, without asking permission? Content is the layer with no replacement: templates can be rewritten, plugins can be swapped, but content modeling done wrong multiplies every future exit.
2. Code portability. Do the templates and components live in a repository I control, and do they build with the vendor's account logged out? If the answer requires the vendor's build pipeline, you do not have code portability; you have a backup.
3. Runtime portability. Does the thing actually run — same behavior, plugins included — on a runtime the vendor does not control? EmDash's Node.js path is the strongest answer any CMS has given to this question, but "runs" and "runs the same at scale" are different claims, and Cloudflare's own migration is the proof: their blog needed Workers Cache and a KV-backed object cache to feel right.

The exit test is four written questions we require before a stack is approved:

• What is the export command, and how long does it take on a full dataset?
• Which services in this stack have a paid equivalent only at this vendor?
• What breaks first if this vendor disappears tomorrow?
• Who on this team has actually run it somewhere else?

Teams that cannot answer question two in writing have already answered it: nobody priced the exit.

How we apply it to our own stack — and when we would pick EmDash anyway

mintec.co is a static Astro build: content lives as Markdoc files in a Git repository, edited through a Keystatic admin, deployed to Cloudflare Pages, with no runtime database. Content and code portability pass trivially, and the runtime layer is static files that any CDN can serve. That is not moral superiority — it is a budget choice. Our audience is content-driven, and we have watched what exits actually cost: our WordPress-to-Astro migration covered 2,500+ pages in three languages, and content migration alone took 8 business days against a 3-day budget (TTFB went from 680ms to 98ms, Lighthouse from 38 to 97 — the win was real, the ejection seat was expensive). Content portability is the layer we budget first precisely because it is the slowest one to unwind.

That is also why we do not reflexively agree with the anti-EmDash framing. If you are running a client site with multiple editors, a plugin ecosystem, scheduled publishing and agents pushing updates through an MCP server, EmDash's convergence buys you real things: no PHP plugin running with database root, no per-seat CMS bill, no separate hosting for the admin layer. That is the exact profile where we would choose a CMS with agentic capabilities over a file-based one — and where the composable-vs-headless over-buying problem we have written about before points the other way: buy the platform, accept the coupling, but sign the exit test at contract time.

For content-driven sites that never need a plugin marketplace, the local-first pattern still wins on cost and exit — that is the layer we default to, and it is what we run ourselves. And when the question is narrower — should this app stay on Cloudflare at all — we already published the framework we used to decide whether to move mintec.co off Pages, where the platform's direction mattered more than its price.

The bottom line

EmDash is the most credible attempt at a WordPress replacement anyone has shipped, and its plugin sandbox fixes a real, data-backed security architecture problem. It is also optimized for a vendor whose business is selling you the runtime, and today it has no turnkey exit. Those two sentences do not contradict each other — that is the entire point of a portability budget. Decide which layers you are willing to bind, write the exit test before the contract, and treat any vendor — Cloudflare, Sanity, Vercel, us — that argues lock-in only lives in the license layer as having answered a different question than the one you asked.