Headless CMS for Vue and Nuxt: What Actually Works

A Vue headless CMS is any content platform you connect to a Vue or Nuxt app over its API, since Vue itself ships no content layer. Most vendors build for React first. Vue support usually means a community wrapper, not an official SDK. That gap is real. It changes how you should evaluate a candidate.

Nuxt closes some of that gap on its own. The framework ships useAsyncData and useFetch. Any CMS with a plain HTTP API works with them, no vendor-specific package needed (Nuxt docs). Draftbase leans into that: a REST and GraphQL delivery API, no Vue SDK to install or version-match. See the frameworks pillar for how this same question plays out across other JavaScript frameworks.

Does a Headless CMS Need an Official Vue SDK?

No. A CMS with a documented REST or GraphQL API works with any frontend, Vue included. An SDK saves you writing a thin wrapper. It does not unlock capability a plain fetch call lacks.

The vendors that do ship Vue tooling mostly ship a Nuxt module, not a Vue SDK. Strapi and Sanity are both like this. No first-party Vue package, but a Nuxt-maintained module (@nuxtjs/strapi, @nuxtjs/sanity) that wraps their API in composables.

Which Headless CMS Platforms Actually Support Vue?

Here's the honest state of Vue support across the CMS market, current as of this writing.

CMS	Official Vue SDK	Nuxt module	Live preview in Vue
Storyblok	Yes	Yes	Yes
Prismic	Yes	Yes	Yes
Payload	No	No	useLivePreview composable only
Strapi	No	Yes (community/Nuxt-team)	Via module
Sanity	No	Yes (community/Nuxt-team)	Via module
Draftbase	Framework-agnostic REST/GraphQL	Works via useFetch, no dedicated module	Draft mode via management API

Storyblok and Prismic are the two vendors that treat Vue as a first-class target, with dedicated packages and visual editing built for it. Everyone else routes through a generic API or a community module.

Why so few vendors invest in Vue

React dominates the CMS integration guides you'll find, including how to choose a CMS for a Next.js project, and vendor engineering time follows the bigger install base. That's not a knock on Vue. A Vue project should weight one question above all: does this CMS have a documented, stable REST or GraphQL API? The SDK is a convenience layer most vendors skip.

How Do You Fetch CMS Content in Nuxt?

Wrap the CMS client in a composable, then call it from useAsyncData. That's the whole pattern, and it works the same regardless of which CMS sits behind the fetch.

// composables/useCms.ts
export function useCms() {
  const config = useRuntimeConfig();

  async function getEntries(templateId: string) {
    return $fetch(`https://api.draftbase.co/delivery/entries`, {
      query: { templateId },
      headers: { Authorization: `Bearer ${config.draftbaseKey}` },
    });
  }

  return { getEntries };
}

<script setup lang="ts">
const { getEntries } = useCms();
const { data: posts } = await useAsyncData('blog-posts', () =>
  getEntries('blogPost'),
);
</script>

useAsyncData runs on the server during SSR and serializes the result into the payload, so the client doesn't refetch on hydration (Nuxt docs). useFetch is shorthand for the same pattern when you're calling a URL directly, without a wrapper function.

Where this breaks

Two mistakes show up constantly in Nuxt + CMS setups. First, a missing or duplicate key argument to useAsyncData causes Nuxt to dedupe requests incorrectly, so two different fetches silently share one cached result. Second, calling the CMS SDK inside onMounted instead of useAsyncData skips SSR entirely. The content only appears after client-side hydration, which tanks both first paint and any crawler that doesn't execute JavaScript.

How Do You Handle Preview and Draft Content in Vue?

Separately from your normal fetch. A preview route needs its own composable that hits a management or preview API, not the cached delivery endpoint.

Draftbase splits this by design. The delivery API returns published content only. An entry edited after publishing still returns its last published revision from that endpoint, not the pending edit. Preview has to go through a separate, token-gated call, which keeps an unfinished draft from leaking onto the live site through a caching bug.

// composables/usePreview.ts
export function usePreview(entryId: string) {
  const config = useRuntimeConfig();
  return useAsyncData(`preview-${entryId}`, () =>
    $fetch(`https://api.draftbase.co/management/entries/${entryId}`, {
      headers: { Authorization: `Bearer ${config.draftbaseManagementKey}` },
    }),
  );
}

Gate the route behind a shared secret, the same way you would in any framework. Nothing about draft mode is Vue-specific; the risk is identical to the Next.js version of this problem, just with a different composable name.

Rich Text and MDX in a Vue App

This is where the framework gap gets real, not theoretical. MDX compiles to JSX. Vue doesn't run JSX by default. A CMS that stores rich text as MDX and only ships a React renderer leaves Vue developers stuck re-parsing raw MDX strings by hand.

Draftbase's rich-text fields store plain MDX strings, the same schema-driven content model that powers every template, and the renderer package (@draftbase/renderer) targets React Server Components specifically. A Vue app can still read the raw string over the API. It just can't drop in the same one-line renderer a Next.js app gets. Interactive MDX components and a Vue frontend don't mix well out of the box. Budget for writing your own compile step, or pick a CMS whose rich-text format is plain HTML or Markdown instead.

What Should You Actually Score a CMS On, for a Vue Project?

Four things, and an official SDK isn't one of them.

1. API shape. REST, GraphQL, or both. A documented, versioned API beats an SDK that lags behind the platform's own releases.
2. SSR-safe fetch pattern. Confirm the API works cleanly from useAsyncData with no client-only quirks (auth headers that only work in a browser context, for instance).
3. Draft/preview support. A separate, tokened endpoint for unpublished content, not a query param on the public API.
4. Rich text format. Plain HTML/Markdown ports to Vue with a standard renderer. MDX needs its own compile step outside React.

Price and entry limits matter too, same as any framework. They just aren't the axis where Vue projects get burned. The same four axes apply if you're evaluating a CMS for the React ecosystem instead, minus the SDK-scarcity problem.

The Underused Angle: a Missing SDK Isn't a Missing Feature

Most "best CMS for Vue" roundups treat an official Vue SDK as a checkbox. A missing one gets marked as a strike against the vendor. That framing rewards marketing investment, not API quality.

A REST or GraphQL endpoint with stable, typed responses is more portable than a framework-specific SDK. It works in Vue. It works in a serverless function, a mobile app, or a plain curl command for debugging. An SDK is a convenience wrapper around that same API, and writing your own thin composable, as shown above, takes under twenty lines. Weight the API's actual shape over whether a vendor bothered to publish a Vue package.

Is Nuxt Content a Headless CMS Alternative for Vue?

Not quite. Nuxt Content reads Markdown files from your own repo and turns them into a queryable data layer inside a Nuxt app. It's fast, it's free, and it needs zero API setup.

The tradeoff shows up the moment a non-developer needs to edit copy. A Markdown file in a repo means every content change is a pull request. There's no draft state and no scheduled publish. Revision history means Git log, and a marketer can't fix a typo without a code review.

Nuxt Content is the right call for docs sites and small projects a single developer maintains alone. It's the wrong call the day a second person who doesn't write Git commits needs to touch the copy. That's the exact point where a hosted headless CMS starts to pay for itself, Draftbase included. A web admin, a draft/publish flow, and an API your Nuxt app already knows how to call.

Conclusion

A Vue project doesn't need a CMS with an official Vue SDK. It needs a documented API that fetches cleanly through useAsyncData. It needs a real draft/preview split, and a rich-text format that doesn't lock content to one framework's renderer. Draftbase's REST and GraphQL delivery API, typed schemas, and plain-string rich text fit that bar without asking you to wait on a vendor's Vue roadmap. Start on the free Hobby tier and wire the composable above against your own content model before you commit to anything bigger.