This is the Nuxt kickstart to reach for when you want the preview flow to behave like a server-rendered application instead of relying on client-side refresh callbacks.

It uses the same lightweight Contentstack content model as the base Nuxt kickstart, but the preview mechanics are different. That difference matters more than it first appears, because it changes how draft updates reach the page while editors are working in Contentstack.

This page is a practical developer guide, not a replacement for the official docs. Use it to understand how the SSR variant is wired and what problem it is trying to solve.

Watch It First

If you want to see the SSR version before reading through the repo:

What makes this variant different

The easiest way to understand this kickstart is to compare it to the base Nuxt version.

The base version uses ssr: false for Live Preview and listens for content changes in the browser. This variant switches Live Preview to ssr: true, which changes the preview behavior to:

• Contentstack appends preview query parameters to the URL
• the iframe reloads
• the app reads those query parameters again
• the content is fetched again with preview state applied

So the main lesson in this kickstart is not "Nuxt can SSR". It is "this is how Contentstack preview behaves when the preview loop is driven by server-aware reloads."

What you get out of the box

The current contentstack/kickstart-nuxt-ssr repository includes:

• Nuxt 4
• the same Contentstack plugin and composable structure as the base version
• Live Preview initialized in SSR mode
• Visual Builder editable field bindings
• the same seeded homepage content model as the base Nuxt kickstart

That is useful because it keeps the example easy to compare. Most of the repo stays familiar, so the preview difference stands out clearly.

How this specific kickstart works

1. app/plugins/contentstack.ts changes the preview mode to ssr: true

This is the most important difference in the repo.

The plugin still creates the Delivery SDK stack and still exposes the same values through Nuxt, but when it initializes the Live Preview utility on the client it sets:

• ssr: true
• mode: "builder"
• the same stack details and edit button config as the base version

That one setting changes how the CMS and the app coordinate preview updates.

2. app/composables/useGetPage.ts applies preview query data during fetches

Just like the base version, the composable reads the current route query, checks for live_preview, and applies livePreviewQuery(...) to the SDK before querying the page entry by URL.

That means the content fetch itself stays very understandable. The composable still owns the query. The important difference is that the route query is now central to how preview updates arrive.

3. app/app.vue becomes simpler because it does not need the change listener

In the base Nuxt kickstart, app.vue registers onEntryChange(refresh) so edits can trigger an in-place client refresh.

In the SSR variant, that listener is gone. The page simply reads the result of useGetPage("/") and renders it.

That absence is actually the clue. The app does not need to subscribe to content changes because Contentstack refreshes the iframe and sends the preview parameters again.

4. The rendered output stays intentionally similar

The page still renders the same kinds of content:

• title
• description
• hero image
• rich text
• modular blocks

That is helpful because it keeps the comparison focused on behavior rather than UI. You are looking at the same content model, but a different preview strategy.

The important preview nuance

This variant is a good place to remember one key rule:

The ssr flag in the Live Preview SDK is about preview update mechanics, not just whether your framework can render on the server.

With ssr: true, preview changes are not pushed into the page through a client callback. Instead, Contentstack reloads the preview iframe with query params, and the app uses those params to fetch the latest draft content again.

That makes this version more useful when you want preview behavior that mirrors server-driven rendering patterns.

What you are really learning from this project

This variant teaches a few patterns that matter in more dynamic sites:

• how preview works when the URL carries the draft context
• how to keep page queries preview-aware in a server-shaped flow
• why you do not always need an onEntryChange() listener
• how to keep Visual Builder support while changing preview mechanics

That makes it a useful reference once your Nuxt site starts leaning more on request-time behavior.

When to choose this one

Choose the Nuxt SSR variant when:

• you want preview updates to happen through full reloads instead of client-side refresh hooks
• you want a pattern that aligns more closely with server-driven page rendering
• your team is comfortable with preview context arriving through the URL
• you want to understand Contentstack’s ssr: true preview mode in a Nuxt app

If you mainly want the smoothest editing loop and the easiest learning path, the base Nuxt kickstart is still the better starting point.

Fastest way to try it

The setup is almost the same as the base Nuxt kickstart:

1. Clone the SSR repo or use the official kickstart flow.
2. Seed or reuse the kickstart stack.
3. Create a delivery token with preview enabled.
4. Add the Contentstack values to .env.
5. Enable Live Preview for the same environment.
6. Run npm install and npm run dev.

The difference becomes obvious when you edit content from inside Contentstack. Instead of an in-place refresh callback, the preview iframe reloads and the app fetches the draft content again using the preview query data.

A good next step after the first run

After the homepage works, the best next step is adding another route and keeping the same pattern of reading preview-aware query state through the composable. That is where this kickstart becomes a practical reference for a larger Nuxt app.