# nuxt-shadcn-dashboard is an admin template you fork, not a framework

> nuxt-shadcn-dashboard packages Nuxt 4, shadcn-vue and TailwindCSS 4 into a runnable admin template with a configurable sidebar, theme switcher and a component set. It suits teams that want to start from a working layout, and it suits them less if they expected a reusable dashboard abstraction.

**dianprata/nuxt-shadcn-dashboard** — Template Dashboard with Nuxt 4 + Shadcn + TailwindCSS 4 

- Repository: https://github.com/dianprata/nuxt-shadcn-dashboard
- Website: https://dianprata.github.io/nuxt-shadcn-dashboard/
- Stars: 680 · Forks: 148
- Language: Vue
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dianprata-nuxt-shadcn-dashboard

## A template project, which is a different thing from a component library

nuxt-shadcn-dashboard is described as a dashboard template built with Nuxt 4, shadcn and TailwindCSS 4, and the distinction between a template and a library is the first thing to settle. The package.json files field lists the shipped directories, and they are application directories: app.vue, components, composables, constants, layouts, lib, nuxt.config.ts, pages and types. The main entry point is declared as ./nuxt.config.ts, not as a component export. So what you get is one working admin interface that you copy and modify, not a package you install and configure. The consequence for a reader deciding whether to adopt it is straightforward. If the plan is to build an internal back office, a client demo, or the front half of a product whose admin area will look like the reference design, the repository saves you the boring work. If the plan is to publish a reusable component set, the structure does not support it, because the reusable pieces live inside one app rather than inside a documented public API.

## Starting from a template rather than cloning a repository

The quick start path is the interesting bit, because it does not tell you to clone and install. The documented command scaffolds a new project from the template with the Nuxt CLI, then moves into it and installs dependencies:

```bash
npx nuxi@latest init -t github:dianprata/nuxt-shadcn-dashboard my-dashboard-app
cd my-dashboard-app
pnpm i # If you don't have pnpm installed, run: npm install -g pnpm
```

That approach has a real benefit. A clone carries the template's git history, its release tags and its contributor configuration, and a scaffold does not. What you get is a project directory with the template's code and a fresh history, which is exactly what you want when the template is a starting point rather than a dependency. The package manager is pnpm, and the note in the command matters for anyone arriving from npm, since the lockfile in the repository is a pnpm-lock.yaml. The runtime requirements are declared in the package.json, and they are strict:

```json
  "engines": {
    "node": "22.x",
    "pnpm": ">=9"
  },
```

The packageManager field pins pnpm@10.10.0. The contributing path for working on the template itself is a plain pnpm install followed by pnpm run dev, and the dev script maps to nuxt dev.

## app.config.ts holds the settings, but a cookie caches them

The template's central configuration point is app.config.ts, and the mechanism deserves attention because it explains a behaviour that otherwise looks like a bug. The config object exposes a sidebar group and a theme group. Sidebar controls the collapse mode, offcanvas, icon or none, the side, left or right, and the variant, sidebar, floating or inset. Theme controls the color, from default through blue, green, orange, purple, red, teal, yellow and rose, and the type, default, mono or scaled. The values are not free form, the comments in the file enumerate the permitted options, so a wrong value is a config mistake rather than a rendering accident. The important detail comes next: to change app settings you have to clear the app_settings cookie first. The settings are therefore persisted in the browser, and editing the file alone changes nothing for anyone whose cookie is already set. That is a sensible choice for a template, since it lets a user personalise the layout, but it is also the first thing to trip over when the configuration appears to be ignored. The file is written with defineAppConfig, which is the Nuxt convention for runtime configuration.

```ts
export default defineAppConfig({
  appSettings: {
    sidebar: {
      collapsible: 'offcanvas', // 'offcanvas' | 'icon' | 'none'
      side: 'left', // 'left' | 'right'
      variant: 'inset', // 'sidebar' | 'floating' | 'inset'
    },
    theme: {
      color: 'default', // 'default' | 'blue' | 'green' | 'orange' | 'purple' | 'red' | 'teal' | 'yellow' | 'rose'
      type: 'scaled', // 'default' | 'mono' | 'scaled'
    }
  },
})
```

## What the dependency list reveals about the built interface

The dependency list is the best available description of what the dashboard actually contains, and it is longer than a pure shadcn-vue setup would be. For interface primitives the template uses reka-ui, which is the Vue implementation behind shadcn-vue components, and it pulls two Iconify icon sets, lucide and radix-icons. For data display, @tanstack/vue-table handles tables, and @unovis/ts with @unovis/vue provides the charting layer, with @number-flow/vue for animated numbers and @internationalized/date for date handling. For interaction there is embla-carousel with its Vue wrapper, and vuedraggable for drag and drop lists, which is what a settings or ordering page would use. Styling comes from tailwindcss and @tailwindcss/vite at version 4, with tw-animate-css for animation utilities, and nanoid is present for identifier generation. The result is a dashboard that already has tables, charts, date pickers, carousels and reorderable lists wired up, and that is the real argument for using the template. You are buying working composition, not just styling.

## Repository plumbing that tells you how releases are handled

Several top level files exist purely for release engineering, and they say more about the project's maturity than a screenshot would. There is a .release-it.json, and the package.json scripts include a release entry that maps to release-it, so version bumps and publishing run through that tool rather than by hand. The version field currently reads 1.0.2, while the tagged releases go to v1.1.0, which means the file is not always the newest truth and the tags are the better reference point. A renovate.json is present, so dependency updates arrive as automated pull requests, which is the mechanism that keeps a template aligned with a fast moving dependency tree. There is a .nvmrc for the Node version, an .npmrc, an eslint.config.js, and a components.json, which is the shadcn-vue configuration file that tells the CLI where components live and how they are generated, so adding a shadcn-vue component later follows the normal CLI path. The devDependencies pull in @nuxt/eslint, @nuxt/fonts and @nuxt/icon, and the lint script runs eslint while format runs eslint --fix. A typecheck script runs vue-tsc --noEmit, so type errors are caught without emitting anything.

## Server directory and the gap between demo and product

The repository includes a server directory and the scripts include both nuxt build and nuxt generate, with nuxt preview for serving the output locally. That pairing tells you the template can be deployed in two ways: as a Nitro server with a running server layer, or as a static generation. The presence of a server directory means the template anticipates server routes, but the readme does not document what they do, and it does not describe a data layer, an API surface, authentication, or how user roles are handled. That omission is the honest boundary of the project. The readme documents the quick start, the app settings and the contributing flow, and points to a live demo plus the shadcn-vue component documentation for everything else. So the template gives you a front end with a layout, a settings system, a table stack and a chart stack, and leaves the part that turns that into a working admin product to whoever adopts it. A team that expects a data fetching layer, a query cache, or sign-in wiring will be writing that layer from scratch.

## Where this template is the wrong choice

There are clear cases where picking this repository wastes time. If the target is a multi-tenant SaaS admin with role based navigation, the sidebar configuration here offers a single layout with a collapse mode and a side, and nothing in the readme suggests per-role variation is supported, so you would extend the config system yourself. If the team has already standardised on a different component library or a different framework, the value drops to the visual reference, because the shadcn-vue components are copied into the components directory rather than consumed as a package, and the file list in package.json shows the components travelling with the template. A copied component set also means upstream fixes do not arrive by bumping a dependency; renovate.json will open pull requests for dependencies, not for the vendored component source. Another mismatch is the runtime floor. Node 22.x and pnpm 9 or newer are not incidental, they are declared engine requirements, so a platform that pins an older Node or uses yarn or npm will need a deliberate change to the project setup before anything runs.

## Conclusion

nuxt-shadcn-dashboard is a good starting point for an internal admin panel or a client demo where someone has already chosen Nuxt, shadcn-vue and TailwindCSS 4 and wants the layout done. It is the wrong starting point if you need a multi-tenant product, a data layer, or a component library you intend to publish, because what the repository ships is a single application with a fixed page structure, not a product. Verify three things before you commit: that Node 22.x and pnpm 9 or newer match your environment, that the app.config.ts settings you want to change actually take effect after you clear the app_settings cookie, and that the version of shadcn-vue components you need is present in components.json. The last push was on 2026-04-21 and the newest tagged release is v1.1.0 from 2025-11-08.

## FAQ

### How do I start a project from nuxt-shadcn-dashboard?

Run npx nuxi@latest init -t github:dianprata/nuxt-shadcn-dashboard my-dashboard-app, then cd into the new directory and run pnpm i. The template is scaffolded as a new project rather than cloned.

### Why do my nuxt-shadcn-dashboard app.config.ts changes not show up?

Settings are cached in a cookie named app_settings, so you have to clear that cookie before changes to app.config.ts take effect.

### What are the runtime requirements for nuxt-shadcn-dashboard?

The package.json declares Node 22.x and pnpm 9 or newer as engines, and pins pnpm 10.10.0 as the package manager. A .nvmrc file is included for the Node version.

### Does nuxt-shadcn-dashboard include authentication and a data layer?

The readme does not document either. The repository ships a front end template with a server directory and both nuxt build and nuxt generate scripts, but sign-in, roles and data fetching are not described and would be your work.

### Which charting and table libraries does the template use?

Tables come from @tanstack/vue-table and charts from @unovis/ts with @unovis/vue. The components themselves are built on reka-ui, with lucide and radix-icons supplied through Iconify.

## Sources

- [dianprata/nuxt-shadcn-dashboard on GitHub](https://github.com/dianprata/nuxt-shadcn-dashboard)
- [License: MIT](https://github.com/dianprata/nuxt-shadcn-dashboard/blob/main/LICENSE)
- [Project website](https://dianprata.github.io/nuxt-shadcn-dashboard/)
- [README](https://github.com/dianprata/nuxt-shadcn-dashboard/blob/main/README.md)
- [Releases](https://github.com/dianprata/nuxt-shadcn-dashboard/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dianprata-nuxt-shadcn-dashboard