Same honest starting point as evaluating any non-Astro frontend for EmDash: its own documentation states plainly that EmDash is "not a headless CMS — tightly integrated with Astro and runs in the same deployment, rather than as a separate service you call over an API." Running EmDash behind a separate Nuxt application is technically possible via its REST API, but it's working against the platform's actual design, not with it.

The REST API Path

EmDash's REST API at `/_emdash/api/` is authenticated via Bearer token and supports CORS for browser requests, with allowed origins configurable in your deployment. A Nuxt app can call it the same way it would call any third-party content API:

GET /_emdash/api/content/posts?status=published
Authorization: Bearer YOUR_API_TOKEN

A minimal fetch inside a Nuxt server route or `useAsyncData` call:

// server/api/posts.get.ts
export default defineEventHandler(async () => {
  const res = await $fetch("https://your-emdash-site.com/_emdash/api/content/posts", {
    query: { status: "published" },
    headers: { Authorization: `Bearer ${process.env.EMDASH_API_TOKEN}` },
  });
  return res.data.items;
});

<script setup>
const { data: posts } = await useFetch("/api/posts");
</script>

<template>
  <ul>
    <li v-for="post in posts" :key="post.id">{{ post.data.title }}</li>
  </ul>
</template>

What You Give Up

Headless CMS: Frontend — bring your own. Deployment — CMS + frontend, separately. Content updates — webhook/rebuild. EmDash: Frontend — Astro components. Deployment — single deployment. Content updates — immediate (SSR).

A separate Nuxt frontend puts you in that "headless CMS" row of EmDash's own comparison table, not its integrated one:

• No live content updates by default — Nuxt needs its own revalidation strategy (ISR-style caching, ISG, ondemand webhook revalidation) since it won't know EmDash content changed until it re-fetches.
• No generated TypeScript types from your content model — you're working against EmDash's generic REST JSON shape rather than typed query results.
• Two separate deployments to run and keep synchronized instead of EmDash's single-deployment model.
• You still run EmDash's own Astro-based admin panel somewhere — a separate Nuxt frontend adds a second application, it doesn't replace the first.

The Alternative Worth Considering First

If Vue components specifically — not Nuxt's routing or server engine — are the actual requirement, Astro officially supports Vue components as islands inside an Astro-native site via `@astrojs/vue`, the same pattern this project uses for React via `@astrojs/react`:

import vue from "@astrojs/vue";

export default defineConfig({
  integrations: [
    vue(),
    emdash({ /* ... */ }),
  ],
});

With that in place, `.vue` single-file components render as islands inside `.astro` pages — genuine Vue where you need it, while EmDash's live content queries and generated types keep working as documented, no separate deployment or revalidation strategy required.

If You Still Want Nuxt Specifically

1. Deploy EmDash as its own Astro application — this remains your content backend and admin panel regardless of what consumes it.
2. Generate an API token from the EmDash admin panel for your Nuxt app's server-side requests.
3. Configure CORS in your EmDash deployment to allow your Nuxt app's origin, if you're fetching client-side rather than through a Nuxt server route.
4. Proxy requests through a Nuxt server route (`server/api/`) to keep your API token off the client rather than exposing it in browser-side code.
5. Pick a freshness strategy: short-TTL caching is simplest; a `content:afterSave` plugin hook calling a Nuxt revalidation endpoint is more precise.

Frequently Asked Questions

Is there an official EmDash Nuxt module?

No — EmDash's deep integration (query functions, generated types, live SSR updates) is Astro-specific. A Nuxt app talks to EmDash purely over its general-purpose REST API, the same way it would to any other CMS.

Will published content appear in Nuxt instantly like it does in an Astro-native EmDash site?

No, not without extra work — that immediacy is a property of Astro's Live Content Collections running in the same process. A separate Nuxt app needs to explicitly re-fetch or be told to revalidate.

Is switching from Nuxt to Astro worth it just for EmDash?

Depends on how deep your Nuxt-specific dependencies go. If your interactive components could work as Vue islands and you don't rely on Nuxt-only modules, Astro plus `@astrojs/vue` gets you EmDash's actual advantages without a decoupled-backend workaround. If you're deeply invested in Nuxt-specific tooling, that migration cost is real.

Does EmDash offer server-side rendering hooks Nuxt could plug into directly?

No — EmDash's SSR model is internal to its own Astro integration. A separate Nuxt app renders independently and simply fetches EmDash's data over HTTP like any external API.

The Bottom Line

EmDash's documentation is explicit that it isn't designed as a decoupled backend for a separate frontend framework — the REST API makes a Nuxt integration technically possible, but at the cost of live updates, generated types, and single-deployment simplicity. If Vue components are the real requirement, `@astrojs/vue` inside a native EmDash site is the better-aligned path for most teams. See our guide to connecting EmDash with Astro natively for the fully supported route.