If you want a clean Nuxt example that is already connected to Contentstack, this is the best place to start.

The Nuxt kickstart gives you a very small project with the Contentstack Delivery SDK, Live Preview, and Visual Builder support already in place. That means you can skip the first round of setup plumbing and jump straight into understanding the integration.

This page is a practical developer guide, not a replacement for the official docs. Use it to understand the shape of the project and why it works. Use the docs when you want the full step-by-step setup.

Watch It First

If you want to see the flow before reading through the repo:

What a kickstart is

A kickstart is the smallest useful project that connects a frontend framework to Contentstack. It is not trying to be a finished starter theme or a full demo site. It is trying to give you the minimum amount of working code needed to understand the integration clearly.

For developers, that usually means four things are already solved:

• SDK setup
• content fetching
• preview configuration
• Visual Builder field mapping

That is the value here. You are learning from a project that already works, but is still small enough to read in one sitting.

Why start with the Nuxt kickstart

This kickstart is a good fit when you want to:

• learn the core Contentstack flow in a Vue and Nuxt setup
• start from Nuxt 4 instead of assembling the integration yourself
• give editors a better experience immediately with Live Preview and Visual Builder
• build on a simple page model before expanding into a larger Nuxt application

It is especially useful if your team prefers Nuxt conventions like plugins, composables, and runtime config over a more React-shaped setup.

What you get out of the box

The current contentstack/kickstart-nuxt repository includes:

• Nuxt 4
• a contentstack Nuxt plugin
• a useGetPage composable for fetching page content
• runtime config for Contentstack credentials and region-aware endpoints
• Live Preview support with edit buttons
• Visual Builder editable field bindings
• a seeded page content type with a sample homepage

In practice, that means you can seed a stack, add your environment values, run the app, and immediately see a page rendered from Contentstack content.

How this specific kickstart works

1. app/plugins/contentstack.ts sets up the SDK once

This plugin is the main integration point.

It reads the Contentstack values from Nuxt runtime config, creates the Delivery SDK stack instance, and initializes the Live Preview utility on the client. It also provides the stack and preview helpers to the rest of the app through Nuxt’s plugin system.

That makes the project very readable:

• config lives in nuxt.config.ts
• SDK setup lives in the plugin
• page fetching lives in a composable
• rendering lives in app.vue

If you are used to Nuxt architecture, this feels exactly where that code should live.

2. nuxt.config.ts keeps the environment wiring tidy

The config file maps the Contentstack API key, delivery token, preview token, environment, region, and endpoint hosts into public runtime config.

That is an important detail because it keeps the Contentstack setup framework-native. You are not sprinkling environment lookups across the app. Nuxt owns the config shape, and the plugin consumes it.

3. app/composables/useGetPage.ts handles page fetching

The useGetPage("/") composable does the main content query.

It uses useAsyncData() together with the injected $stack instance, filters by the page url field, and returns the first matching page entry. When preview mode is active, it also checks the route query and applies livePreviewQuery(...) before fetching the entry.

That means this composable is doing two useful jobs:

• fetching the page content
• making the same query preview-aware

4. app/app.vue renders the entry and listens for changes

The main app component fetches the homepage with useGetPage("/"), then renders:

• a title
• a description
• a hero image
• rich text
• modular blocks with alternating layouts

On mount, it registers ContentstackLivePreview.onEntryChange(refresh), so content edits in Contentstack trigger a re-fetch and refresh the UI.

That is the key preview behavior in this version: the editing loop is client-driven and feels immediate.

The important preview nuance

One thing worth calling out: in this base Nuxt kickstart, Live Preview is initialized with ssr: false.

That setting is about how preview updates are delivered, not just whether Nuxt itself can render on the server. In this kickstart, preview updates happen through the client-side event flow:

• Contentstack sends a change event
• the Live Preview SDK receives it
• the app calls refresh()
• the page updates without a full iframe reload

That is why this version feels especially smooth while you are editing.

What you are really learning from this project

Even though the app is small, it teaches a few useful Nuxt patterns:

• how to put Contentstack setup into a Nuxt plugin
• how to keep content fetching in a composable
• how to make useAsyncData() preview-aware
• how to bind editable tags directly in Vue templates
• how to keep the project simple while still supporting editors well

That is why this kickstart works nicely as both a learning project and a baseline for a real app.

When to choose this one

Choose the base Nuxt kickstart when:

• you want the clearest Nuxt-first Contentstack example
• you want a lightweight project you can read quickly
• you prefer instant preview updates without full page refreshes
• you want to grow a real Nuxt app from a minimal but correct starting point

If you specifically want the preview flow to be driven by full server-side reloads, the Nuxt SSR variant is the better comparison point.

Fastest way to try it

The shortest path is:

1. Clone the repo or bootstrap it from 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.

Once it is running, open the homepage locally and then open the matching entry in Contentstack. That is where the kickstart becomes useful immediately: edit content in the CMS and watch the Nuxt app update in place.

A good next step after the first run

After the homepage works, the best next move is adding a second composable or route and repeating the same pattern. Keep the plugin as your SDK boundary, keep the query logic in composables, and keep the rendered fields editable. That turns the kickstart into a real Nuxt project without losing its clarity.