Nuxt SaaS Template: a landing page, pricing, docs and blog on Nuxt UI

Four pages, one repository, and a live demo to copy

The template is described in the README as a fully built SaaS application to launch your next project with a landing page, a pricing page, a documentation and a blog powered by Nuxt UI components. That is the whole scope, and it is worth being clear about it up front: there is no user account system, no payment integration, no database layer and no server API in this repository. What there is, is the front end of a SaaS product.

The live demo is at saas-template.nuxt.dev, and the README links it next to the Nuxt UI documentation. The screenshots in the README are shown in both dark and light variants, which is the visual cue that the template ships with a theme that follows the user's system preference rather than a fixed palette.

The repository belongs to the nuxt-ui-templates organisation, its topics are nuxt, nuxt-ui, saas and vue, the primary language is Vue, and the licence is MIT. The last push to the repository was on 2026-10-20, two days before the current date, and there are no GitHub releases, which is normal for a template: you take the code from the default branch rather than from a tagged artefact.

The top level of the repository shows the shape of a Nuxt 4 application. There is an app/ directory for the application code, a content/ directory for the documentation and blog, a content.config.ts at the root, nuxt.config.ts, a public/ directory, pnpm-lock.yaml and pnpm-workspace.yaml, an eslint.config.mjs, a tsconfig.json, a renovate.json, a .env.example and an .editorconfig.

Getting the template, and the difference between the two commands

There are two ways in, and they are not equivalent, which is worth understanding before you start.

The first is the create command, which pulls the template into a new project directory.

npm create nuxt@latest -- -t ui/saas

The second is the setup path for a checkout you already have. Dependencies install with pnpm.

pnpm install

The distinction is not cosmetic. The create command produces a fresh project scaffolded from the template, while pnpm install is the step you run inside a clone of this repository. The repository is a pnpm workspace, with pnpm-workspace.yaml at the root and a lockfile of pnpm-lock.yaml, and the package.json pins the package manager at [email protected]. The README's quick start uses npm create because the Nuxt scaffetcher runs on npm, while every subsequent command in the README is pnpm.

One script makes the split explicit. The package.json has a postinstall hook that runs nuxt prepare, which is what generates the .nuxt types directory that the TypeScript tooling depends on. That runs automatically after pnpm install, and it is the reason a fresh install can fail with type errors if the hook is skipped with an ignore-scripts flag.

Development, build and preview

The three commands in the README cover the whole local loop, and they map one to one onto the package.json scripts.

The development server runs on the standard Nuxt port.

pnpm dev

The production build is a separate command, and the README points to the Nuxt deployment documentation for what to do with the output.

pnpm build

And the local preview serves the built application so you can check it before deploying.

pnpm preview

The scripts in package.json are the Nuxt commands themselves rather than wrappers: nuxt dev, nuxt build and nuxt preview. Two more scripts are there for quality gates, eslint for the lint task and nuxt typecheck for the type check, and both are listed in the same file.

  "scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev",
    "preview": "nuxt preview",
    "postinstall": "nuxt prepare",
    "lint": "eslint .",
    "typecheck": "nuxt typecheck"
  },

The devDependencies support those two gates: @nuxt/eslint alongside eslint itself, a plugin named eslint-plugin-better-tailwindcss for the class ordering rules, typescript at version 6, and vue-tsc as the Vue-aware type checker.

The dependency list is the real specification

A template's package.json is the part you inherit, so it is worth reading line by line rather than treating as boilerplate.

The framework stack is nuxt at version 4.6, with nuxt-ui at 4.12 providing the component set, @nuxt/content at 3.16 running the documentation and blog, @nuxt/image for asset handling, and @vueuse/nuxt for the composition utilities. The styling is Tailwind CSS at version 4.3, and there is a ufo package for URL handling.

Two dependencies stand out because they are not obvious from the page list. nuxt-og-image at 6.10 generates the Open Graph images for each page, and it is the reason the .env.example exists, since the OG image needs to know the public URL of the site. The second is @takumi-rs/core, the rendering engine the OG image module uses, which is a native dependency rather than a small JavaScript library.

The rest of the runtime list is icon and schema support. @iconify-json/lucide and @iconify-json/simple-icons are the two icon sets bundled, @standard-schema/spec and zod at 4.6 provide the validation layer that Nuxt Content uses for its collections, and the standard-schema spec is what lets content schemas and form validation share one definition.

The zod dependency deserves a note, because it is the mechanism behind the content/ directory. Nuxt Content validates every markdown file against a schema, and zod is what does the validating. A malformed frontmatter block in a content file is a build error, not a runtime surprise, which is a good property but means the content directory is coupled to the schema definitions in content.config.ts.

Content, the OG image URL, and the one environment variable

The .env.example file in the repository is three lines, and it documents exactly one variable.

# Public URL, used for OG Image when running nuxt generate
NUXT_PUBLIC_SITE_URL=

The comment is the documentation. The variable is needed when running nuxt generate, that is, for a static build, because the Open Graph images are rendered at build time and they need an absolute URL to point at. Leave it empty and the OG image generation has nothing to reference.

The prefix is the important part. NUXT_PUBLIC_ means the value is exposed to the client bundle, which is correct for a public site URL and wrong for anything secret. There is no server key in this template because there is no server, and the .env.example is the entire environment surface.

The content side is the content/ directory paired with content.config.ts at the root. The README describes the outcome as a documentation and a blog powered by Nuxt UI components, and the schema in content.config.ts is what defines the collection structure both of them share. Since the two pages are driven by the same content pipeline, adding a new documentation page is a markdown file rather than a Vue component, which is the main reason to adopt Nuxt Content here instead of hardcoding pages.

Renovate, deployment, and what nobody has published

The README's last section is about dependency upkeep. It tells you to install the Renovate GitHub app on your repository and that you are good to go, and the repository carries a renovate.json at the root to hold its configuration. The effect is that once the template is your repository, dependency updates arrive as pull requests rather than as something you remember to do.

Deployment has a one-click path. The README embeds a Deploy with Vercel badge whose link clones the template repository into a new Vercel project, with the demo image, the demo URL and the project title and description pre-filled. The reference deployment documentation at nuxt.com is linked for anything beyond that.

One thing to be honest about: the repository has no GitHub releases, so there is no version history to pin to and no changelog to read. The versioning that exists is the dependency set itself, where everything is held at a caret range so a fresh install picks up the latest minor within that major. That is a deliberate choice for a template, and it also means the template you adopt is the template as of the moment you cloned it, and the drift between your copy and the upstream repository is invisible from inside your project.

The MIT licence at the root is the permissive end, so there is no constraint on commercial use or modification beyond keeping the licence notice.

Where this template is the wrong starting point

Three cases point elsewhere. The first is a product that needs accounts, billing or a database. None of that is in the repository, and the pages are static marketing and content pages with no data layer behind them. A team that has already chosen a backend and a payment provider can still use this for the marketing site, but a team hoping the template contains the plumbing of a SaaS will find it does not.

The second is a team on npm. The repository is a pnpm workspace with a pnpm lockfile, the package manager field pins [email protected], and every command in the README is pnpm. A project that has standardised on npm and npm workspaces will spend its first hour either installing pnpm or regenerating a lockfile, and the packageManager field in package.json will keep fighting that choice.

The third is a team that does not want Vue. Nuxt UI is a Vue component library and the primary language of the repository is Vue, so the template is a Vue application. A React shop looking for a Nuxt alternative will not find one here.

The alternative worth weighing is building the same four pages on Nuxt UI from an empty project rather than adopting the template, and the difference in approach is the dependency set rather than the components. The template hands you eleven runtime dependencies, and two of them, nuxt-og-image with its native rendering core and the image module, add build-time work and a native binary to a pipeline that a marketing site might not otherwise need. Starting from a bare Nuxt project and adding Nuxt UI, Content and Tailwind yourself gets the same component library and the same content pipeline with a shorter dependency list, at the cost of assembling the layout, the pricing table and the blog index yourself. For a team that wants a finished first commit, this template is the faster route; for a team that cares about the dependency budget, the shorter list wins.

Editorial conclusion

Nuxt SaaS Template fits a team shipping a marketing-led product on Vue who wants the four pages every SaaS site needs, with the component set and content pipeline already configured, and who is willing to own the dependencies afterwards. It does not fit a team that needs authentication, billing, a database or an API, because none of that is in the repository, and it does not fit a team on npm rather than pnpm, since the lockfile is pnpm-lock.yaml and the package manager is pinned to [email protected]. Before you build on it, read package.json and decide which of the eleven runtime dependencies you actually need, because the Open Graph image generation and the image module in particular carry real cost at deploy time.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nuxt-ui-templates/saas on GitHub
4. Project website
5. README