Nuxt starter templates: choosing the right starting point for a Nuxt project

What the repository is: a catalogue of starting points, not a framework

The nuxt/starter repository is described as the place to create a new Nuxt project, module or layer, or to start from a theme using the collection of starters. Its own README is short: quickly get started with a minimal Nuxt starter template.

That framing matters. This is not a component library, a build tool or a framework. It is a set of templates, and the value of the repository is the choice between them plus the maintenance of the baseline configuration in each.

The quick start points at nuxt.new, which is the hosted way to generate a project, and the homepage of the repository is that same address. The command line route is the create-nuxt CLI, which clones the latest template into an empty directory:

$ npm create nuxt@latest [<dir>] -- [-t,--template=<template>]

The bracket notation in that line is the template selection. The example given clones v4 into a my-app directory:

$ npm create nuxt@latest my-app -- -t v4

The project is MIT licensed, the last push was on 2026-10-19, and there are no GitHub releases, which is consistent with a repository whose units of change are branches rather than versions. The topic list names nuxt, vue, ssr and ssg, and the primary language is recorded as JavaScript.

One structural detail that will confuse you if you do not know it: the default branch of the repository is templates, not any of the individual starter branches. The README's contribution section explains why. Each template is maintained in a branch, and the list of all branches is linked. So the branch you clone with the -t flag is a different branch from the one you land on when you open the repository.

The template list, and what each one is actually for

The README lists the templates in a table with a name, a description, the local command to clone them and, where one exists, a browser playground.

The v4 template is the current Nuxt 4 baseline, and it is the one the create-nuxt CLI uses by default since the local command for v3 is listed simply as npm create nuxt@latest with no template flag. The v4-compat template is Nuxt 3 with v4 compatibility, and the description links to the Nuxt 3 upgrade documentation on testing Nuxt 4. That distinction is the important one: v4-compat is a bridge for a project that is on Nuxt 3 and wants to try the newer version, not a target to live on.

The v3 template is the Nuxt 3 baseline, with its own documentation link to the Nuxt 3 getting started introduction.

The two module templates are for people building a Nuxt module rather than an application. The module template is a Nuxt module with the Module Builder, and module-devtools adds Nuxt DevTools integration on top of it. Neither of these has an online playground listed, which makes sense, since a module is a library rather than a running site.

Then there are two templates that add a specific product. The content template is Nuxt Content, and the ui template is Nuxt UI, which lives in a separate repository, the nuxt-ui-templates/starter, even though it is listed in the same table and reachable with the same -t ui flag.

The playground column is where the table earns its keep. Most templates are available on StackBlitz and CodeSandbox, which means you can open the template in a browser, look at what it contains, and only clone it once you have decided. The two module templates and the v4-compat entry have no playground linked, and the v3 entry points at slightly different playground URLs, with a stackblitz branch named v3-stackblitz and a codesandbox path ending in v3-codesandbox, rather than the plain v3 path the others use. Small inconsistencies like that are a hint to check the branch yourself rather than trust the table blindly.

Contributing: a pull request per branch, and no lock files

The contribution guidance is short and specific, and it explains the branch-per-template model directly.

Each template is maintained in a branch, with a link to the all branches list, and for improvements you are asked to open a pull request to each individual branch. That is a meaningful instruction, because a change to a shared piece of the project does not exist here. There is no common source directory that all templates are generated from, so a change to the Nuxt 4 baseline is a change to the v4 branch and a change to the Nuxt 3 baseline is a change to the v3 branch, and they are two separate pull requests.

That has an obvious consequence for a maintainer, which is that the branches drift and someone has to keep them in sync. It is also the reason the table lists separate documentation links per template version, since the v3 and v4 configurations point at different documentation.

The second instruction is a warning about lock files. The README asks contributors to avoid committing lock files such as yarn.lock and package-lock.json to template branches.

The reasoning is standard but worth stating, since it is the kind of thing a new contributor gets wrong once. A template is a starting point that people will install into their own project and then take ownership of. A committed lock file pins dependency versions that were resolved on one machine at one moment, and every new user inherits that pin and then has to undo it. The template is supposed to hand you a package manifest and let your own package manager decide the versions, and a lock file in the template makes that impossible without an extra cleanup step.

The repository root also holds a scripts directory, a template.schema.json, a renovate.json and a CODEOWNERS file. The schema file at the root is the only hint about how the templates are described in a machine-readable way, which suggests the tooling in scripts reads it. The renovate configuration is what keeps the dependencies inside the templates current, and CODEOWNERS records who is responsible for which part of the tree.

The online playgrounds, and the one template that lives elsewhere

The playground column in the template table is a shortlist of what you can open without cloning anything, and it is where the table's oddities become visible.

Every application-shaped template has a StackBlitz and a CodeSandbox link, and both point at the corresponding branch of the repository rather than at a separate sandbox repository. For the v4 template the links are to the v4 branch, for content to the content branch, and for ui to the nuxt-ui-templates/starter repository, which is the one entry that resolves to a different project entirely.

That last case is worth understanding. The ui template is hosted in the nuxt-ui-templates organisation, not in nuxt/starter, and yet the create-nuxt CLI reaches it with the same -t ui flag. So the template flag is not a branch lookup inside one repository. It is a name that the CLI resolves somewhere, and the resolution can point at a different repository entirely. That is how a third party template stays inside the same command without the starter repository having to own its content.

The module and module-devtools templates have no playground at all, which is the right outcome: a module is a package, not a running site, so there is nothing to show in a browser sandbox. The v4-compat template also has no playground listed, which is consistent with it being a transitional configuration rather than a demo-worthy project.

The v3 entry uses different playground paths from the rest, a StackBlitz branch named v3-stackblitz and a CodeSandbox path ending in v3-codesandbox, rather than the plain branch names the other entries use. Small inconsistency, but a reminder that the links in the table are maintained by hand and are worth clicking before you rely on them.

The licence is MIT, and the README credits it with a green heart, which is the extent of the attribution in this repository.

Choosing between the templates, and the question a starter cannot answer

Putting the list together, the choice is a function of three things: which Nuxt major version you are targeting, whether you are building an application or a module, and whether you want a specific product like Nuxt Content or Nuxt UI included from the start.

If you are starting fresh and following current Nuxt, v4 is the answer and you do not need to pass a template flag at all, since the default create-nuxt command gives it to you. If you are on Nuxt 3 and want to test what Nuxt 4 would mean for your codebase, v4-compat exists for that, and the upgrade documentation is linked from its description. If you are on Nuxt 3 and staying there, the v3 template is what you want, and the CLI's default command in the v3 era is the same one with the v3 template implicitly selected.

If you are writing a Nuxt module, the module template gives you the Module Builder wiring, and module-devtools gives you the same plus devtools integration, which is the difference between a module you can develop and one you can debug.

What none of the templates can decide for you is the parts of a Nuxt project that are specific to your product: the data layer, the deployment target, the styling approach, the testing setup. A starter template deliberately stops at a working baseline, and everything above that is your decision. The v4-compat template is the clearest illustration of the principle, because it exists for a transitional moment rather than a permanent state, and a permanent state is exactly what a starter template is not designed to provide.

If you are still undecided, the playgrounds are the efficient path. Open the StackBlitz or CodeSandbox link for the two or three candidates, look at the files, and clone only the one that matches. That is faster than reading the branch diffs, and it is why the table carries those links at all.

Editorial conclusion

Use the nuxt starter templates when you are starting a Nuxt project and want the official baseline rather than a hand-assembled nuxt.config, and pick the branch that matches the Nuxt major version you are committing to. Do not use the v4-compat template as a long term home, since its purpose is testing a Nuxt 4 upgrade path, and do not expect the module templates to be application templates. Before you clone, read the template list in the README and check the branch you are on, because each template lives on its own branch and the default branch of the repository is templates, not any of the individual starters.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nuxt/starter on GitHub
4. Project website
5. README