This is the Next kickstart to reach for when you want Contentstack data fetched on the server for every request instead of updating the page entirely in the browser.

It keeps the same lightweight content model as the base Next kickstart, but changes the preview and rendering flow so request-time data fetching becomes the core pattern. That makes it a useful bridge between a simple demo and a more production-shaped Next.js setup.

This page is a practical developer guide, not a replacement for the official docs. Use it to understand how the project is put together and why you might choose it. Use the docs for the full setup walkthrough.

Watch It First

If you want to see the SSR flow before reading through the code:

What makes this variant different

The base Next kickstart is great for learning the integration with client-side preview updates. The SSR variant changes the mental model:

• the server fetches the page on each request
• preview state comes in through URL query parameters
• Contentstack triggers iframe reloads during editing
• the page is rendered again on the server with preview-aware data

So the interesting part here is not just "Next with Contentstack". It is "Next with Contentstack when the server owns the content fetch."

What you get out of the box

The current contentstack/kickstart-next-ssr repo gives you:

• Next.js App Router
• request-time page fetching
• Contentstack Delivery SDK setup
• Live Preview configured in SSR mode
• Visual Builder editable fields
• the same seeded page content model as the base Next kickstart

That means you can reuse the same seeded stack and still learn a very different rendering pattern.

How this specific kickstart works

1. lib/contentstack.ts creates a fresh stack per request

This is the most important difference in the repo.

Instead of exporting one shared SDK client, the file exposes getStack(), which creates a new Contentstack stack instance whenever the server needs one. That matters because preview configuration can change per request, and sharing one SDK instance across concurrent requests would risk mixing preview state between users.

This file also:

• configures region-aware delivery and preview hosts
• enables Live Preview when NEXT_PUBLIC_CONTENTSTACK_PREVIEW=true
• initializes the client-side Visual Builder bridge with ssr: true
• exposes getPage(url, stackInstance?) so the page can query with a request-specific stack

If you only remember one thing from this kickstart, remember this pattern: SSR preview needs isolated stack instances.

2. app/page.tsx reads the preview query params

The page component reads live_preview, content_type_uid, entry_uid, and preview_timestamp from searchParams.

When those values are present, it calls stack.livePreviewQuery(...) before fetching the homepage entry. That is the server-side handoff point between Contentstack’s preview iframe and your page render.

This is exactly the flow you want to understand if your real project uses server components, request-based rendering, or server-side personalization.

3. components/ContentstackLivePreview.tsx initializes the editing bridge

There is still a small client-side piece in this kickstart. The ContentstackLivePreview component initializes the Live Preview SDK in the browser so the editing UI and Visual Builder integration can attach correctly.

In other words, the server owns the content fetch, but the browser still needs to know how to participate in the preview session.

4. The page renderer stays intentionally simple

Just like the base Next kickstart, the page output is straightforward:

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

That is deliberate. The example is trying to teach the rendering flow, not hide it inside a larger design system.

What you are really learning from this project

This variant teaches a few useful patterns that show up quickly in real projects:

• when to prefer request-time rendering over purely client-side fetching
• how Live Preview works when the CMS refreshes the iframe with query params
• why preview-aware SDK clients should be created per request
• how to keep Visual Builder support while using server rendering

That makes this kickstart a strong reference point when your app needs fresh content on each request.

When to choose this one

Choose the SSR kickstart when:

• the server should fetch the latest content on every request
• you are building pages whose data flow already lives on the server
• you want preview behavior that mirrors server-rendered production patterns
• you want a simpler path toward request-time logic than the base CSR-style kickstart

If you mainly want instant in-browser updates and the simplest learning curve, the base Next kickstart is still the easier entry point.

Fastest way to try it

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

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

The difference shows up when you open the entry in Contentstack. In SSR preview mode, Contentstack appends preview query parameters and refreshes the iframe so the server can render the latest draft content.

A good next step after the first run

After you confirm the homepage works, the best follow-up is to add a second server-rendered route and reuse the same request-scoped stack pattern. That is the point where this kickstart starts turning into a real SSR application instead of just a demo.